squeak-vmdev — CVS-related Virtual Machine Development Issues

Re: [Squeak-VMdev] Versiojn 4 changes

[Andreas R. <and...@gm...>]

Hi Dan,

> There are a couple of cleanups like the size of the numbered
> primitive field and the layout of the format field in classes.
> I am assuming we'll just do those, and that they'll take a day
> or two each.  Any problems with Tim's suggestion to drop the
> limit to 511?

Fine with me. One thing to keep in mind here: When the "split primitive
index" was introduced we lost one bit in the method header which would have
allowed us to use up to 31 args for methods. The bytecodes to support it are
actually there but the method header doesn't have that extra bit. I'm not
saying that we should necessarily use it but we should be Really Careful
before assigning it for something else and later realize that we might need
it.

> Compact classes
> I put these in way back, and they do save almost a word per
> object in small kernel images.  They complicate things a bit,
> but the code is already written, and it has been stable for
> nearly a decade now.
>
> On the other hand, the complexity is an inhibition to trying
> out various other cool hacks.  Moreover if we dropped the compact
> class feature, we could pick up 5 more bits of object hash, which
> would definitely be nice.  With regard to compactness, my experience
> is that the savings due to this feature is less than the difference
> between a well-designed kernel and a poor one, so I don't consider
> it a bit issue.  Even PDA's have plenty of space these days (yes,
> there's an upside to the Microsoft world ;-), and for extreme
> compactness issues (like web downloads), there are all sorts of
> other compactness strategies.
>
> I'm inclined to drop them and give the bits back to the hash,
> but it's only a mild inclination.  How do you guys feel?

No strong opinions here. If we agree that the savings in size aren't worth
it, we should go with whatever is best for speed (both, current and future
such as a JIT - it might have a benefit to "tag classes" via their cc
index).

> Immediate objects (tagging)
> We *could* do lots of things here -- enough so I start to get
> worried about doing too much.  For instance, we could have
> immediate Floats of, say, 30 bits, and immediate Characters
> of 30 bits, in addition to our current immediate SmallIntegers.
>
> I'm inclined not to do any of these, but how do you feel?

A very clear "NO" to the idea of taking away a bit from SmallInteger. 30bit
floats are almost useless - if I had understood the trouble I'm getting into
when I first encountered them in VW I would've never used them ;-) Even
32bit floats are almost always useless except in very limited situations
(say 3D stuff where accuracy really doesn't count all that much).

Here is an alternative that I considered a while ago: Instead of using
"another tag" bit we could declare a tag pattern which looks like:

00 - OOP
10 - Immediate
x1 - SmallInteger

With "Immediate" being described by 6 further bits which specify the index
into the "immediate classes array" (precisely the same as compact classes).
This would leave 24 bits which I could (out of my mind) think of 4
situations in which they would be useful:
* Colors (8 bits each)
* Immediate Points (signed 12 bits x/y)
* Wide characters (Unicode is defined as 21 bit; but Yoshiki really needs
24)
* Scaled decimals (16.8 or 12.12)

The only problem with using the 10 tag is that the garbage collector
currently uses that - but I believe this is fixable. In any case, there is a
clear objection from my end against taking away a bit from SmallIntegers.

> Form bits modulus
> I want to change the modulus of Form bitmaps to 64 bits
> in both 32- and 64-bit images.  It will simplify things
> for them to be the same, and I think we can convert old ones
> on the fly for compatibility (ie, when reading in a project,
> or an old '.form' file.  Do you see any problems with this?

A key question is whether the "bits" of a 64bit form would store 32bit
quantities or 64bit. If the latter I'd say this is going to get problematic.
If the first, e.g., we merely extend the form bits to make sure we have
always 64bit aligned pixel rows, that should fine.

> CompiledMethods
> A major question to decode is whether to split up bytecodes
> and literals (and source pointer) as in Tim's NewCompiledMethod
> work. This adds a little space overhead, but it certainly makes
> things simpler.
>
> And what about native methods support?  Is there something simple
> that would suffice, or something better?  This is a time when we
> could open some possibilities.  If we had some idea, then at least
> we could put the right hooks in the image, even if we need to do
> some VM work to use it later.

I don't have a good understanding about the tradeoffs involved (Ian should
comment on this) so I'll just throw in a general thought: I think that if we
can (e.g., not being overly wasteful in terms of space) we should leave some
"unused" slot. Much of the experimentation we saw in the past was only
possible because such "unused" places existed (say, MethodContext's
receiverMap).

> Closures
> I'm just assuming we would load some form of Anthony's work,
> which probably also means using his compiler.  Ian, are you
> happy with the structures he chose, or should we make some
> changes before loading them up?  I'm assuming this is separable
> from the contiguous stack work, but maybe not.  We probably
> want to start with something that doesn't change the existing
> context structures much.

I guess a key issue here is the question whether any changes in V4 could
have a long-term benefit for the closure work. As it stands, Anthony's stuff
works out of the box with a VM that has a few extra primitives so it seems
as if it isn't intrinsically related to image format changes.

> Immutability bit
> This sounds intriguing.  Has anyone here thought seriously
> about what is needed to support it?

Not very much. Obviously you need to put an "immutable object" into some
place where you have a cheap write barrier or at least don't have to check
on every store (so clearly it can't reside in young space). But other than
that, no.

> Monitor bit
> This was a concern of Alan's way back.  Andreas - is this
> needed for any of the Croquet synchronization work?

Uh... what is a monitor bit? This is the first time I hear this term ;-)

Cheers,
  - Andreas

Re: [Squeak-VMdev] Versiojn 4 changes

[<gor...@bl...>]

Hi Dan and all!

I don't have the knowledge to really respond but just a few things:

Dan Ingalls <Da...@Sq...> wrote:
[SNIP]
> Compact classes
> I'm inclined to drop them and give the bits back to the hash, but it's only a mild inclination.
> How do you guys feel?

It sounds like I agree. I love simplicity. :)
 
> And what about native methods support?  Is there something simple that would suffice, or something better?  This is a time when we could open some possibilities.  If we had some idea, then at least we could put the right hooks in the image, even if we need to do some VM work to use it later.

Bryce Kampjes should have some answers, I cced him with this post. Hey
Bryce, if you aren't on this list you should be. :)
  
> Immutability bit
> This sounds intriguing.  Has anyone here thought seriously about what is needed to support it?

I think Stephen Pair is interested in a bit or two, though it was a
while since I heard from Stephen. IIRC a "dirty bit" would be nice for
transactional images like Magma and Stephen's work etc. And I also think
Stephen was playing with some bits for managing an object cache.

regards, Göran

[Squeak-VMdev] Versiojn 4 changes

[Dan I. <Da...@Sq...>]

Hi, folks -

I know many of you are busy, but I'd like some input in the next few days about various possible or desirable changes to be included in the Version 4 image format.  Feel free to mark up the swiki page, and I'll try to pull some consensus out of the discussion toward the end of the week.


Cleanups
There are a couple of cleanups like the size of the numbered primitive field and the layout of the format field in classes.  I am assuming we'll just do those, and that they'll take a day or two each.  Any problems with Tim's suggestion to drop the limit to 511?

More important to me are...


Compact classes
I put these in way back, and they do save almost a word per object in small kernel images.  They complicate things a bit, but the code is already written, and it has been stable for nearly a decade now.

On the other hand, the complexity is an inhibition to trying out various other cool hacks.  Moreover if we dropped the compact class feature, we could pick up 5 more bits of object hash, which would definitely be nice.  With regard to compactness, my experience is that the savings due to this feature is less than the difference between a well-designed kernel and a poor one, so I don't consider it a bit issue.  Even PDA's have plenty of space these days (yes, there's an upside to the Microsoft world ;-), and for extreme compactness issues (like web downloads), there are all sorts of other compactness strategies.

I'm inclined to drop them and give the bits back to the hash, but it's only a mild inclination.  How do you guys feel?


Immediate objects (tagging)
We *could* do lots of things here -- enough so I start to get worried about doing too much.  For instance, we could have immediate Floats of, say, 30 bits, and immediate Characters of 30 bits, in addition to our current immediate SmallIntegers.

I'm inclined not to do any of these, but how do you feel?


The 64-bit format
My inclination is to tie this as closely to the 32-bit format as possible for now, just to simplify the project.  To me that means just extending every oop, and header word with zeroes, and sign-extending every "small" integer.  The trade-off is complex between having a different range of SmallIntegers in the 64- and 32-bit worlds, and sticking with the same 31-bit range in each.  I hope to understand this better in the coming days.  If you do already, please speak up.


Form bits modulus
I want to change the modulus of Form bitmaps to 64 bits in both 32- and 64-bit images.  It will simplify things for them to be the same, and I think we can convert old ones on the fly for compatibility (ie, when reading in a project, or an old '.form' file.  Do you see any problems with this?


CompiledMethods
A major question to decode is whether to split up bytecodes and literals (and source pointer) as in Tim's NewCompiledMethod work. This adds a little space overhead, but it certainly makes things simpler.

And what about native methods support?  Is there something simple that would suffice, or something better?  This is a time when we could open some possibilities.  If we had some idea, then at least we could put the right hooks in the image, even if we need to do some VM work to use it later.


Closures
I'm just assuming we would load some form of Anthony's work, which probably also means using his compiler.  Ian, are you happy with the structures he chose, or should we make some changes before loading them up?  I'm assuming this is separable from the contiguous stack work, but maybe not.  We probably want to start with something that doesn't change the existing context structures much.


Immutability bit
This sounds intriguing.  Has anyone here thought seriously about what is needed to support it?


Monitor bit
This was a concern of Alan's way back.  Andreas - is this needed for any of the Croquet synchronization work?

Re: [Squeak-VMdev] InterpreterSimulator fixes v2 (works!)

[Ned K. <ne...@sq...>]

On Saturday 03 April 2004 11:19 pm, Tim Rowledge wrote:
> In message <200...@sq...>
>
>           Ned Konz <ne...@sq...> wrote:
> > > Ned, if you put a 'self halt'in BitBltSimulation>initialiseModule does
> > > it actually open a debugger for you? All I get is ... stop.
> >
> > I get the same thing. However, I can actually run Morphic, so *most* of
> > the simulator seems to be working.
>
> Well that's a relief - if I were getting different behaviour at that
> level I'd be really pissed off.
>
> Certainly there's some very odd stuff happening with errors.
>
> Good news I can actually get a MVC image up in sim. Who knows
> what tomorrow will bring?

Fun fact: we get a debugger if we use #profileSends: instead of just 
#runForNBytes:

Another fun fact: when you hit the halt the UIProcess gets killed off and 
restarted (this is of course why your loop stops). Try this:

* put your halt in initialiseModule as before
* open a ProcessBrowser, note the ID of the UI process
* do this in a workspace:

	p := Processor activeProcess.
	sim test. "stops without a clue"

* update the ProcessBrowser

You will see the old activeProcess suspended in the list.

Note that you can't debug it.

Apparently the fork of the new UI process happens, but the debugger is not 
opening in it.

Hmmm... try running the simulator from an MVC project. You get the debugger.

Maybe something is referring to the uiProcess, ScheduledController, or some 
other global state and so is fooling the debugger into not opening correctly.

-- 
Ned Konz
http://bike-nomad.com/squeak/

Re: [Squeak-VMdev] InterpreterSimulator fixes v2 (works!)

[Tim R. <ti...@su...>]

In message <200...@sq...>
          Ned Konz <ne...@sq...> wrote:


> > Ned, if you put a 'self halt'in BitBltSimulation>initialiseModule does
> > it actually open a debugger for you? All I get is ... stop.
> 
> I get the same thing. However, I can actually run Morphic, so *most* of the 
> simulator seems to be working.
Well that's a relief - if I were getting different behaviour at that
level I'd be really pissed off.

Certainly there's some very odd stuff happening with errors.

Good news I can actually get a MVC image up in sim. Who knows
what tomorrow will bring?


tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Useful random insult:- His page was intentionally left blank.

Re: [Squeak-VMdev] InterpreterSimulator fixes v2 (works!)

[Ned K. <ne...@sq...>]

On Saturday 03 April 2004 8:10 pm, Tim Rowledge wrote:
> In message <200...@sq...>
>
>           Ned Konz <ne...@sq...> wrote:
> > Oops... No, sorry; I just fixed that and didn't re-post.
> >
> > The problem was that you weren't checking for a nil return in
> > primitiveGetAttribute
>
> Nah - while primitiveGetAttribute might well be wrong, that's not the
> problem that's annoying me right now. I simply don't get notifiers that
> should appear; put a self halt in the simulator and it simply exits, no
> error handling, nothing. I've tried a 3.4 VM and that makes no
> difference, so I doubt that it's a bug caused by the new VM I'm
> running.  The weird thing is that I can interrupt the simulator with no
> problem and get the debugger, proceed, interrupt again and again.
>
> No change in 5424 unfortunately. I'm getting quite annoyed with this.
> Ned, if you put a 'self halt'in BitBltSimulation>initialiseModule does
> it actually open a debugger for you? All I get is ... stop.

Perhaps Anthony could shed some light on this.

-- 
Ned Konz
http://bike-nomad.com/squeak/

Re: [Squeak-VMdev] InterpreterSimulator fixes v2 (works!)

[Ned K. <ne...@sq...>]

On Saturday 03 April 2004 8:10 pm, Tim Rowledge wrote:
> I simply don't get notifiers that
> should appear; put a self halt in the simulator and it simply exits, no
> error handling, nothing. I've tried a 3.4 VM and that makes no
> difference, so I doubt that it's a bug caused by the new VM I'm
> running.  The weird thing is that I can interrupt the simulator with no
> problem and get the debugger, proceed, interrupt again and again.
>
> No change in 5424 unfortunately. I'm getting quite annoyed with this.
> Ned, if you put a 'self halt'in BitBltSimulation>initialiseModule does
> it actually open a debugger for you? All I get is ... stop.

I get the same thing. However, I can actually run Morphic, so *most* of the 
simulator seems to be working.

-- 
Ned Konz
http://bike-nomad.com/squeak/

Re: [Squeak-VMdev] InterpreterSimulator fixes v2 (works!)

[Tim R. <ti...@su...>]

In message <200...@sq...>
          Ned Konz <ne...@sq...> wrote:

> Oops... No, sorry; I just fixed that and didn't re-post.
> 
> The problem was that you weren't checking for a nil return in 
> primitiveGetAttribute
Nah - while primitiveGetAttribute might well be wrong, that's not the
problem that's annoying me right now. I simply don't get notifiers that
should appear; put a self halt in the simulator and it simply exits, no
error handling, nothing. I've tried a 3.4 VM and that makes no
difference, so I doubt that it's a bug caused by the new VM I'm
running.  The weird thing is that I can interrupt the simulator with no
problem and get the debugger, proceed, interrupt again and again.

No change in 5424 unfortunately. I'm getting quite annoyed with this.
Ned, if you put a 'self halt'in BitBltSimulation>initialiseModule does
it actually open a debugger for you? All I get is ... stop. 

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
You depend too much on computers for information.

[Squeak-VMdev] InterpreterSimulator fixes v2 (works!)

[Ned K. <ne...@sq...>]

On Saturday 03 April 2004 4:13 pm, Tim Rowledge wrote:
> > OK. Here's a combined change set that will run Morphic in a stock
> > 3.6Full-5424 image after loading Tim's VMMaker3-7b2.sar package from
> > http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/VMMaker3-
> >7b2.sar
>
> Do you still get the strange "it just plain stops" problem? My lastrun
> before going out for the day "just stopped" at
> primitivePluginBrowserReady. No error, nothing. That really bothers me
> - now I have to try and find out if it is a stupid image problem I can
> berate someone else about or is it an entirely understandable minor
> error that anyone could make when doing VM work :-)

Oops... No, sorry; I just fixed that and didn't re-post.

The problem was that you weren't checking for a nil return in 
primitiveGetAttribute

Here's a better (and somewhat faster) one...

-- 
Ned Konz
http://bike-nomad.com/squeak/

Re: [Squeak-VMdev] Re: InterpreterSimulator

[Tim R. <ti...@su...>]

> OK. Here's a combined change set that will run Morphic in a stock 3.6Full-5424 
> image after loading Tim's VMMaker3-7b2.sar package from 
> http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/VMMaker3-7b2.sar
>
Do you still get the strange "it just plain stops" problem? My lastrun
before going out for the day "just stopped" at
primitivePluginBrowserReady. No error, nothing. That really bothers me
- now I have to try and find out if it is a stupid image problem I can
berate someone else about or is it an entirely understandable minor
error that anyone could make when doing VM work :-)

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Useful random insult:- His access light's on, but the drive isn't spinning .

Re: [Squeak-VMdev] Re: InterpreterSimulator

[Dan I. <Da...@Sq...>]

>OK. Here's a combined change set that will run Morphic in a stock 3.6Full-5424
>image after loading Tim's VMMaker3-7b2.sar package from
>http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/VMMaker3-7b2.sar
>
>I haven't tried it in any later images, nor have I tried to speed it up
>(though the byte and half-word accessors I did are much faster; there's a big
>difference in:
>
>	bitShift: 3
>and
>	* 8
>
>I also sped up the GC a bit (using bitOr: to set header type bits rather than
>the slow LargeInteger addition).

Hey, Ned -

This is GREAT.

Many thanks

	- Dan

Re: [Squeak-VMdev] Re: InterpreterSimulator

[Ned K. <ne...@sq...>]

On Saturday 03 April 2004 8:37 am, Tim Rowledge wrote:
> In message <200...@sq...>
>
>           Ned Konz <ne...@sq...> wrote:
> > Though this may be in the humor category, here's what I was using most
> > recently. I got it to run somewhat (so it may be a start).
>
> [snip]
>
> > I see the Morphic screen from small.image painted, but it doesn't keep
> > running.
> > I don't get any walkbacks; it just completes normally.
>
> Yup. I saw that too. It was 'fixed' by making the module initialisation
> for B2DPlugin not do the wrong thing; that was causing an error in the
> bowels of the simulator >which was not raising a notifier< !
>
> I'm currently convinced there is something seriously screwed in some
> signal/exception code. Note that the unit test for exceptions fails the
> 'outer' related test.  I also had a problem a while ago that I never
> really got to the bottom of in VMMAker - an error would simply 'go by'
> and make it look like the generation was done. We need to fix this PDQ
> in my view.
>
> I've been working with Dan on this and if you use mylatest VMMaker3-7b2
> and the attached sim patch it should go a bit better. And since my
> current bug seems to be to do with halfWordAt: it looks like Ned might
> have fixed that... ta very much.

OK. Here's a combined change set that will run Morphic in a stock 3.6Full-5424 
image after loading Tim's VMMaker3-7b2.sar package from 
http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/VMMaker3-7b2.sar

I haven't tried it in any later images, nor have I tried to speed it up 
(though the byte and half-word accessors I did are much faster; there's a big 
difference in:

	bitShift: 3
and
	* 8

I also sped up the GC a bit (using bitOr: to set header type bits rather than 
the slow LargeInteger addition).

-- 
Ned Konz
http://bike-nomad.com/squeak/

[Squeak-VMdev] Re: SystemTracer2

[Dan I. <Da...@Sq...>]

Hi, Anthony -

>Here is the latest SystemTracer2, a merge of my past changes with
>Stephen Pair's.  SystemTracer2 works successfully on 3.7, but
>RehashingSystemTracer produces a corrupt image (bad hash tables?).  It
>shouldn't be too hard to inspect the code and figure it out (the
>Rehashing code is relatively small), otherwise you will have to run the
>InterpreterSimulator on the corrupt image in the debugger to see where
>it's getting stuck.  Stephen, hopefully you can figure this out.
>
>Dan, I hope you find the SystemTracer2 easy to work with.  Read the
>enclosed Readme and the SystemTracer2 class comment.

Many thanks for this.  It's going to be great to have all the tools up to date.  Right now, I'm hacking what I need to get started, but we will soon need the real tracer, including rehashing ability.

I'll hold off a bit more in hopes that Stephen can get the rehasher working, but I'm not stuck waiting on it yet.

	- Dan

PS:  A bit of history that might interest you .  In the "old days" before we put rehashing into the tracer, we would start up the new image, and "just hope" that enough would run so we could execute #rehashBadSets, which rehashed all sets in the system.  But, of course, this would not work if we changed the hashing of method dictionaries.  What did we do then?  We produced an interim VM that did linear search in all the message dictionaries.  Then we could run that one, fix the image, and save.  After that we could go back to a normal VM and everything worked.

Re: [Squeak-VMdev] Re: InterpreterSimulator

[Tim R. <ti...@su...>]

In message <200...@sq...>
          Ned Konz <ne...@sq...> wrote:


> Though this may be in the humor category, here's what I was using most 
> recently. I got it to run somewhat (so it may be a start).
[snip]
> I see the Morphic screen from small.image painted, but it doesn't keep 
> running.
> I don't get any walkbacks; it just completes normally.
Yup. I saw that too. It was 'fixed' by making the module initialisation
for B2DPlugin not do the wrong thing; that was causing an error in the
bowels of the simulator >which was not raising a notifier< !

I'm currently convinced there is something seriously screwed in some
signal/exception code. Note that the unit test for exceptions fails the
'outer' related test.  I also had a problem a while ago that I never
really got to the bottom of in VMMAker - an error would simply 'go by'
and make it look like the generation was done. We need to fix this PDQ
in my view.

I've been working with Dan on this and if you use mylatest VMMaker3-7b2
and the attached sim patch it should go a bit better. And since my
current bug seems to be to do with halfWordAt: it looks like Ned might
have fixed that... ta very much.


tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
The generation of random numbers is too important to be left to chance.

[Squeak-VMdev] Re: InterpreterSimulator

[Dan I. <Da...@Sq...>]

Hi, Ned -

>Though this may be in the humor category, here's what I was using most
>recently. I got it to run somewhat (so it may be a start).

Well, Smalltalk started with humor ("Hey, wouldn't it be cool to send a message for every operation?..."), so I consider this to be a propitious start.

Seriously, though, Tim and I have both been sneaking up on a successful run.  In fact, last night Tim opined that halfWordAt: was the problem.  The two images I've tried get off in the weeds after loading other plugins such as balloon2D for corner rounding, Zip for decompression, and something else to find out if it's in a plugin (you have the same fix for this).

Anyway, please send me (only, unless someone else wants it) a zip with the small image and changes that you used.  Then I can duplicate your work and set about getting my other images to work as well.

Thanks for your help.  This is great progress.
Once reflection works, the only problem is figuring out where you want to go...

;-)
	- Dan

PS to all:  Tim and I will try to keep VMMaker up to date until we have things well checked out, and we'll send out little progress notes as we do.

PPS:  I dropped  the previous CCs because I think we're all on VMDev.  Please let me know if this is not the case.

[Squeak-VMdev] Re: InterpreterSimulator

[Ned K. <ne...@sq...>]

On Wednesday 31 March 2004 1:14 pm, Dan Ingalls wrote:
> Hi, Guys -
>
> Can any of you tell me a recent version of Squeak in which the
> InterpreterSimulator actually ran?  By this I mean able to display a simple
> morphic screen and allow simple interactions (like show a menu, drag a
> morph), however slowly?
>
> I am debugging my way through the IS in 3.7, but it would help to have
> something fairly recent that actually works.
>
> Thanks in advance for anything (including humor ;-).

Though this may be in the humor category, here's what I was using most 
recently. I got it to run somewhat (so it may be a start).

Here's what I did (on my Intel P4 Linux box):

Start with a 5816 image and a new VM.
Load Tim's VMMaker 3.7b1
Load this CS
Open a Transcript
find a small image with Morphic.

In a Workspace:
	(InterpreterSimulatorLSB new openOn: 'small.image') test.

I see the Morphic screen from small.image painted, but it doesn't keep 
running.
I don't get any walkbacks; it just completes normally.

The messages in the Transcript are:

Looking for module MiscPrimitivePlugin ... loaded
<Running full GC ... done>
Looking for module FilePlugin
Looking for module SecurityPlugin ... loaded ... loaded
Looking for module BitBltPlugin ... loaded

-- 
Ned Konz
http://bike-nomad.com/squeak/

[Squeak-VMdev] Re: CVS bits

[Ned K. <ne...@bi...>]

On Friday 02 April 2004 10:15 am, Tim Rowledge wrote:

> OK, I've sent another copy with, I hope, things fixed up for you.

OK, I'll take a look.

> It was a switch but now is a function pointer table. The table is made
> by the CCodeGen and it didn't occur to me that it might need
> macroising. Hmm.
>

I'll look at where it's defined; it probably would make sense to make a 
corresponding macro for it too.

> > * why couldn't you just define dispatchFunctionPointerOnin as
> >
> > #define dispatchFunctionPointerOnin(index, table)  ((table)[index])()
> >
> > since presumably the table is declared as
> > 	fptr const primTable[] = { func0, func1, func2 /* ... */ };
>
> Err, because I had no idea that phrasing might work.  :-) Feel free to
> try it and let me know the results...
>

OK.

> Thanks for the help

No problem... I just spent the last 2 days trying to reconstruct an image that 
I'd used in Japan for a presentation and then (apparently) hacked on... guess 
I reshaped a class without migrating it very well (and apparently without a 
backup first).

In the process I also made Postscript printing a lot nicer and more accurate.

Now I just have to convince the Mac-ists that a point is not the same thing as 
a pixel...

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

[Squeak-VMdev] Re: Report on the Debianized VM

[Ned K. <ne...@bi...>]

On Tuesday 30 March 2004 1:17 pm, Ned Konz wrote:
> On Tuesday 30 March 2004 10:38 am, Lex Spoon wrote:
> > Bert Freudenberg <be...@im...> wrote:
> > Yes, that VM package runs 3.7 images just fine, while stock 3.6g2 did
> > not.  I don't remember which Ned fix was the right one, but clearly it
> > is in there.
>
> We had some segfaults because of broken Ephemeron support, and because of a
> problem with some older ObjectsAsMethods prims (as I recall). Oh yes, and
> then there was the endian problem in squeak.h.

I think it was the endian problem in squeak.h if it's crashing immediately.

> A zipped up version of what I'm running now is at
> http://bike-nomad.com/Neds3.6g-3LinuxVM.zip
>
> I will bring the "ned-branch" version on SF up to date.

Anyway, I updated the ned-branch version on SF to what I'm running now.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

[Squeak-VMdev] Possible bug in socket handling...

[Ned K. <ne...@bi...>]

I've gotten a segfault a couple of times and have traced it down to where it 
happens in dataHandler() in sqUnixSocket.c.

It's at the line that says
  if (flags & AIO_R) notify(pss, READ_NOTIFY);

It appears as if pss is NULL there.

Though we can certainly add a check there, it seems like we should figure out 
why this is happening.

I have seen it occur when I tried to send a changeset to the list and I got a 
walkback because of an inability to reach the mail server (I'm not sure why 
this happened; it could be another bug).

I then told it to retry (or proceed?) and I got the segfault.

I wish I could make this happen again, but can any of you think of why the 
socket handle might be getting destroyed prematurely?

It looks like this could happen if the socket were marked as Invalid without 
being disabled in the aio system and then someone called 
sqSocketConnectionStatus (which will clear out the pss pointer).

So is there a problem in acceptHandler() where if accept() returns <0 and the 
errno is not ECONNABORTED we mark the socket as Invalid and close the fd but 
don't aioDisable() it?

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

Re: [Squeak-VMdev] SourceForge or SqueakForge?

[<gor...@bl...>]

Hi guys!

(Was offline this weekend)

Tim Rowledge <ti...@su...> wrote:
> So are we going to do this? If so, somebody that can handle any setup
> still pending will need to step up soon - or tell us that nothing needs
> doing of course.
> 
> If we're going to switch for 3.7b we need to move fairly soon. We need
> to decide upon the setup, allowed users etc. Can we move the SF archive
> and history across? Do we want to? 
> 
> I have a particular and hopefully temporary problem in that I have no
> practical way to upload anything for now. The RISC OS cvs cannot yet
> cope with the ssh stuff that SF is using, I can't make any Mac version
> do much and my winxp laptop refuses to talk to my network - and I
> probably couldn't cope with a winxp cvs anyway. Doing anything with
> that damn thing is like dentistry with pain enhancers. My linux box is
> buried in a storage unit so I can't even fall back on the tacky cmdline
> cvs it has installed. Hopefully somebody will feel sorry enough for me
> to offer to proxy for me in some manner. Or is there some way to have
> cvs using :server: (via rsh) or :pserver: and still be acceptably safe?
> RISC OS cvs can handle those.
> 
> Slightly OT, can anyone point me to any doc that might explain to me
> how to keep a local cvs system for my day to day hacking and yet upload
> to SqF when appropriate?
> 
> Alternatively, Goran (I think) suggested maybe using subversion; any
> other opinions?  Sometimes I think printing out in barcode and pickling
> in peat might be simpler.
>
> tim

Well, I think we should move. If we do then we can make whatever
decisions we want regarding SSH etc.. Regarding subversion - I just
wanted to mention that we could switch to something better - and perhaps
Arch would be a better choice btw. But I don't think we should do the
switch right now - let's move first. :)

We will also move the  downloadable files and mack up some simply
frontend for them, a Swiki or similar is perhaps the "simplest thing".

I could take a look at this at the earliest tonight. But I will only do
it if people speak up and say "Yes please!". :) No point in putting in
time if we don't all agree.

And of course, if someone else could spend the time I would be really
grateful - I really, really need to sit down with SM instead and I have
no daytime to spare.

regards, Göran

[Squeak-VMdev] VMMaker 3.7 beta

[Tim R. <ti...@su...>]

It's 3.7 beta time and thus time to make another release ofVMMaker.
Since I've made a bunch of changes I thought I'd mention some of the
details and ask if they cause any problems for people.

The b1 version added to 3.6:-
Add ClassRefsBrowsingForPlugins ( extends image support for classrefs)
Add InterpreterSimulator-primitiveGetAttribute (support Simulator)
Add InterpreterSimulator-sqGrowMemoryBy (ditto)
Add primYield.1.cs - adds primitive for ProcessorScheduler>yield
Add primCopy.1.cs - adds a prim to copy Objects, revised from ar
original to make numbered (168)
Add SlightlyFasterActivate-JMM.8.cs
Add ImageStartupFix-JMM.1.cs - consider
doing the object counting for real?
Add bytecodePrimPoint-internal-tpr.1.cs - variant of
MakePrimPointXInternal-JMM.1.cs
Add InterpreterPlugin-halt.st
Add isArray stuff
- update Cross/vm/sqVirtualMachine.[ch]
- IsArrayVM.1.cs - which changes core VM code to use isArray:
- IsArrayVMProxy.1.cs- which add isArray to the proxy for simulation
- IsArrayPlugins.2.cs - which uses isArray in some plugin code

This version adds:-

fixes for the object-as-methods prims

New mechanism for requiring the CCodeGen to retain methods even if they
appear unused. This spreads the responsibility around to class methods
named #requiredMethodNames, called as part of CCodeGenerator>addClass:

New primitive calling; instead of a case statement we have a table of
function pointers and jump directly. To support this a macro and
typedef are added to Cross/sq.h

The cumbersome timing of primitives is removed from primitiveResponse since
most internal numbered prims are quick. Those that are not use
#forceInterruptCheck to require an ASAP checkForInterrupts. fIC is
essentially idempotent and can be called several times in a prim without harm.
I use this instead of simply setting the interruptCheckCounter to 0 because
that seems to mess up the feedback mechanism. The external call prim
now has the primitive timing code since many named prims are quite long
operations; I'm still looking for a nice way to improve that. Maybe
changing the codegen to do something clever. I guess the ffi prim ought
to do something similar. Note that this change could be backed out if
the latter two points cause a problem for anyone.  Allowing plugin code
to call forceInterruptCheck requires a step in sqVirtualMachine - but
then Andreas' isArray code had already caused that. Internal code like
ioGetNextEvent(), ioShowDisplay() etc that takes a long time can freely
call fIC if it seems warranted. The evidence so far is that the timer
change is very worthwhile on RISC OS and mildly beneficial on other
platforms. It also allows the more direct usage of function pointers in
the prim table which will have other uses later. :-)

Misc. commenting, reformatting and tidying.




tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: SSD: Scramble Segment Directory

Re: [Squeak-VMdev] SourceForge or SqueakForge?

[Tim R. <ti...@su...>]

So are we going to do this? If so, somebody that can handle any setup
still pending will need to step up soon - or tell us that nothing needs
doing of course.

If we're going to switch for 3.7b we need to move fairly soon. We need
to decide upon the setup, allowed users etc. Can we move the SF archive
and history across? Do we want to? 

I have a particular and hopefully temporary problem in that I have no
practical way to upload anything for now. The RISC OS cvs cannot yet
cope with the ssh stuff that SF is using, I can't make any Mac version
do much and my winxp laptop refuses to talk to my network - and I
probably couldn't cope with a winxp cvs anyway. Doing anything with
that damn thing is like dentistry with pain enhancers. My linux box is
buried in a storage unit so I can't even fall back on the tacky cmdline
cvs it has installed. Hopefully somebody will feel sorry enough for me
to offer to proxy for me in some manner. Or is there some way to have
cvs using :server: (via rsh) or :pserver: and still be acceptably safe?
RISC OS cvs can handle those.

Slightly OT, can anyone point me to any doc that might explain to me
how to keep a local cvs system for my day to day hacking and yet upload
to SqF when appropriate?

Alternatively, Goran (I think) suggested maybe using subversion; any
other opinions?  Sometimes I think printing out in barcode and pickling
in peat might be simpler.

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Choose variable names that will not be confused.

Re: [Squeak-VMdev] Objects as Methods: SqueakMap version vs. VMMaker version?

[Andreas R. <and...@gm...>]

> Everything else has been added to the image. So the whole package can
> be deleted from SqueakMap.

I don't think so. The package clearly says it's for 3.2, 3.4, and 3.6 and
none of them contain those modifications.

  - Andreas

Re: [Squeak-VMdev] Objects as Methods: SqueakMap version vs. VMMaker version?

[Marcus D. <ma...@ir...>]

Am 26.03.2004 um 15:05 schrieb Ned Konz:
>
> Can I suggest that the VM portion of the Objects as Methods package on
> SqueakMap be removed and instead a pointer to the VMMaker package be 
> put in
> the version description?
>
Everything else has been added to the image. So the whole package can 
be deleted
from SqueakMap.

       Marcus

--
Marcus Denker ma...@ir...

[Squeak-VMdev] Objects as Methods: SqueakMap version vs. VMMaker version?

[Ned K. <ne...@sq...>]

I installed Andreas' "Objects as Methods" package from SqueakMap and VMMaker 
into a 5816 image.

I noticed that his 3 tests worked using my (3.6g2+++) VM, but also noticed 
that the (re)definition of a couple of classes left some things in 
Undeclared:

ObjectMemory lost class vars
RootTableRedZone

and inst vars
headerTypeBytes and youngStartLocal

Further, Interpreter class>>initializePrimitiveTable in Andreas' package is 2 
months older than the VMMaker one, and defines prim 248 as #primitiveRun 
instead of #primitiveInvokeObjectAsMethod.

And there is also an older version of 
SystemDictionary>>recreateSpecialObjectsArray which lacks the last (50th) 
slot containing #run:with:in:

So apparently the version in VMMaker is the more recent one.

Can I suggest that the VM portion of the Objects as Methods package on 
SqueakMap be removed and instead a pointer to the VMMaker package be put in 
the version description?

Also, I tried to use the "update streams" facility of the VMMaker package, but 
get a message that the update server is unavailable.

Perhaps it would make more sense to use SqueakMap package releases instead 
now.

Thanks,
-- 
Ned Konz
http://bike-nomad.com/squeak/