squeak-vmdev — CVS-related Virtual Machine Development Issues

Re: [Squeak-VMdev] primitive timing issues

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

I've found a relatively simple and I think plausible solution.

I factored out the forcing of an interrupt check but implemented it for now as
setting the interruptCheckCounter to -1000. In checkForInterrupts I also
factored out a test (and implemented it as 'is iCC < -100') so that forcing a
check no longer affects the feedback reset value. That at least stops
it climbing to ludicrous values. There is a small potential cost in the
check being done a bit more frequently. If we need to the force and
test can be macroized to let platforms have more choice viz Mac using a
cheap timer or whatever.

I've also, for now, changed the nextPollTick increment to 100 mS instead of
500, to give some chance of a timely response to an interruptKey press during a
heavy non-interactive process. We could quite reasonably make this settable
via vmParameter or a platform macro if that is a problem.

I made interruptChecksEveryNms vmParameter settable. I don't think the
default of 3mS is very helpful towards achieving 1mS Delay response
unless one wants to rely on enough forced interrupt checks being made
so I changed to 1mS.

Surprisingly few numbered prims need to force a check. Most that do
involve some GC so I put the forcing there. Some platform support
functions will be time consuming and the force can be added in those
places easily. For example, on RISC OS a getNextEvent that results in
polling the OS events is likely to take a while if some other app sucks
up the cycles. I have the impression from Ian that X11 clipboard
fetching can be traumatically long winded, so he can add a force to
that code. This strikes me as better than imposing a forced check on
every platform for all these things (io* and so on).

I've also altered the ioMSecs() wrap handling code in
checkForInterrupts. I think it was broken previously though given that
the timer probably wraps every six days or so it is hardly a major
problem.

As I mentioned on the general list, I'm reasonably certain that Ned's
recursive interrupt problem is not exacerbated by these changes. 

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Useful Latin Phrases:- Recedite, plebes! Gero rem imperialem! = Stand aside plebians! I am on imperial business.

Re: [Squeak-VMdev] fullDisplay, ioForceDisplay etc

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

Tim,

> Indeed, but what interaction should it have with the
> deferDisplayUpdates flag? I'm puzzled by the way that
> the win32 code for this does involve deferDisplayUpdates.

ioForceDisplayUpdate is a no-op on Windows these days. Ignore it.

> That's fine; it would be nice to have better commenting of
> this where possible. Again, the win32 code refers to
> deferDisplayUpdates which has the same concern as above.

And the same answer. Note that both of these depend on the setting of the
"fDeferredUpdate" variable which predates "deferDisplayUpdates" a couple of
years. But it's turned off by default these days.

Cheers,
  - Andreas

Re: [Squeak-VMdev] fullDisplay, ioForceDisplay etc

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

In message <ED1...@in...>
          Ian Piumarta <ian...@in...> wrote:


> fullDisplayUpdate() calls ioShowDisplay() for the entire Display (or 
> whatever surface, yada yada) area.
That one is pretty reasonable though the commenting could be more
helpful as to the actual users. It doesn't refer to deferDisplayUpdates
within any of the slang code.
> 
> ioShowDisplay() tells the VM that the Display has changed (and where).  
> (E.g., the Unix/X11 code grabs a PixMap out of the Display object and 
> paints it into the X11 window, but network/server latencies don't 
> guarantee an immediate effect on the physical screen.  Other VMs might 
> just add the rectangle to a damage list, in preparation for...)
Indeed, but what interaction should it have with the deferDisplayUpdates
flag? I'm puzzled by the way that the win32 code for this does involve
deferDisplayUpdates. I suppose my concern is that if the inner vm code
has some subtle difference to other platforms we could see odd effects
since a great deal of graphics code is written by Andreas on windows.
For example, for several releases some time ago I didn't see any morphs
while they were being dragged because nobody had mentioned some change
or other involving force update and defer and blahblah. Don't recall
the details anymore but it was that general area.
> 
> ioForceDisplayUpdate() tells the VM that any screen updates from 
> previous calls to ioShowDisplay that have not as yet been forced into 
> the physical framebuffer should now be forced into the framebuffer.  
> (E.g., the Unix/X11 code calls XFlush() which returns after the server 
> tells us that all pending PixMap writes have been propagated to the 
> framebuffer -- which is kind of pedantic, but it does allow the image 
> to assume the user is now seeing the most recent Display contents at 
> the time the prim returns.  Other VMs might defer synchronising the 
> physical screen with the Display explicitly -- e.g., if they blit bits 
> directly out of the Display object and use ioShowDisplay() only to 
> maintain a damage list to avoid repaints of overlapping areas.)
That's fine; it would be nice to have better commenting of this where
possible. Again, the win32 code refers to deferDisplayUpdates which has
the same concern as above. Which code should take note of deferment and
which can or should ignore it (I guess any of it can ignore it at a
potential performance cost).
> 
> Any clearer yet?
Somewhat but it would be nice to get it documented more cleanly. Some
explanation of the pixel reversal when depth is -ve would be good to get
in as well.

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: SFA: Seek Financial Assistance

Re: [Squeak-VMdev] fullDisplay, ioForceDisplay etc

[Ian P. <ian...@in...>]

On 21 Mar 2004, at 03:52, Tim Rowledge wrote:

> In fact there seems to be a little confusion as to which code forces a 
> display
> update right now, which can be deferred by the image and which can be
> done lazily by the vm. I'd be interested to know what the design intent
> is here!

fullDisplayUpdate() calls ioShowDisplay() for the entire Display (or 
whatever surface, yada yada) area.

ioShowDisplay() tells the VM that the Display has changed (and where).  
(E.g., the Unix/X11 code grabs a PixMap out of the Display object and 
paints it into the X11 window, but network/server latencies don't 
guarantee an immediate effect on the physical screen.  Other VMs might 
just add the rectangle to a damage list, in preparation for...)

ioForceDisplayUpdate() tells the VM that any screen updates from 
previous calls to ioShowDisplay that have not as yet been forced into 
the physical framebuffer should now be forced into the framebuffer.  
(E.g., the Unix/X11 code calls XFlush() which returns after the server 
tells us that all pending PixMap writes have been propagated to the 
framebuffer -- which is kind of pedantic, but it does allow the image 
to assume the user is now seeing the most recent Display contents at 
the time the prim returns.  Other VMs might defer synchronising the 
physical screen with the Display explicitly -- e.g., if they blit bits 
directly out of the Display object and use ioShowDisplay() only to 
maintain a damage list to avoid repaints of overlapping areas.)

Any clearer yet?

Ian

[Squeak-VMdev] fullDisplay, ioForceDisplay etc

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

Whilst playing with all this VM code I noticed a bit of confusion in
the area of fullDisplay and it's cousins.

Strange Mac code - sqMacUIEvents>case: updateEvt -> fullDisplayUpdate
-> ioForceDisplayUpdate -> does nothing. Comment claims to use
ioShowDisplay...

Similar kind of oddity in comments in win32 -
sqWin32window>ioForceDisplayUpdate claims:-
  /* force an update of the squeak window if using deferred updates */
but appears to NOT update if defer is on. Oh and comment in case:
WM_PAINT claims fullDisplayUpdate will call ioShowDisplay too.

In fact there seems to be a little confusion as to which code forces a display
update right now, which can be deferred by the image and which can be
done lazily by the vm. I'd be interested to know what the design intent
is here! Who knows, it might enable me to further improve the RISC OS
performance. 

primitiveBeDisplay comment claims that the Display oop will be recorded
in the specialOopArray as well as a separate variable. Currently there
appears to be no such variable. Shall we change the comment or the
code? A loooong time ago I wanted to have that separate variable but
nobody else liked the idea and I reworked stuff to not need it. Does
anyone want it?

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Nostalgia:  The good old days multiplied by a bad memory...

Re: [Squeak-VMdev] primitive timing issues

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

In message <F11...@in...>
          Ian Piumarta <ian...@in...> wrote:


> Hmmm.  Like primitives 127, 128 and 130, for example?
Excellent choices for discussion.

127 (showdisplayrect for those not able to look it up right now) has a
potentially huge time range. Depends on the size of the rectangle and
what the platform does with it. It invokes (usually) ioShowDisplay and
ioForceDisplayUpdate but might not. The latter does nothing on mac, an
ioProcessEvents on RISC OS, a variety of things on *nix and an
UpdateWindow on win32 if various defer related things are right. It's
_probably_ a good bet that it will take a fairly long time.

128 (arraybecome) is a pretty good bet for averaging a long time.

130 (fullgc) is a certainty on most systems; I'd say that any system
that can fullgc in well under a mS is not going to be worried about an
extra checkForInterrupt.

But we also have the normally very quick Float prims that can trigger a
GC - so some easy detection of a GC could be useful so that it can
trigger a checkForInterrupts. My guess is that it will be rare but we
should be able to cope with it.

[snip]
> 
> In those cases, just fall back on setting interruptCheckCounter to zero 
> in your ioGetNextEvent() thing.  (Like you already do, when the user 
> presses the interruptKeyCode, right? ;)
Easy for the things that are already platform specific (interesting
aside on interruptKey though; the event loop in the image is trying to
handle the semaphore itself. Is the vm expected to not signal it
anymore?) but not quite so simple for 'portable' prims IF we want to
try to do optimal checking for the platform. Anything beyond merely
setting interruptCheckCounter to 0 for example.

Well absent any strong suggestions from you guys I'll see what running
with just a zeroing the counter does. I'll even try it on my winXP
laptop if I can find a way to persuade the f^&$%^$ing thing to talk to
the network...(offline advice on settings etc welcomed) 

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: BH: Branch and Hang

Re: [Squeak-VMdev] primitive timing issues

[Ian P. <ian...@in...>]

Hi Tim,

> I've been messing in the area of primitive calling and found a small
> (5% - pMac) to big (150% - RISC OS) improvement in macrobenchmark
> performance by removing the timing stuff that currently surrounds
> primitive calls. (See primitiveResponse) I moved the timing to
> primitiveExternalCall on the dodgy sounding but surprisingly practical
> grounds that numbered prims are quick

Hmmm.  Like primitives 127, 128 and 130, for example?

;)

How about just changing it all to do The Right Thing.

> To tag the primitives that need this timer check, I suggest that some
> Slang equivalent of a pragma be tossed in. We can automagically add the
> macro reference to each exit.

That sounds like a close approximation to me.  (j5 had a completely 
local set of [numbered] primitive implementations, written by hand from 
scratch, in which I very carefully identified those that could 
potentially run for more than 1ms and avoided the timer check in all 
others.)

> There are however cases where the
> potential slowness is also very platform dependent and we ought to
> handle that. For example, getNextEvent could be very slow on RISC OS if
> it allows some other app to run and that app goes off and calculates pi
> to a gazillion places before returning. Some prims could be made long
> running if they trigger a GC.

In those cases, just fall back on setting interruptCheckCounter to zero 
in your ioGetNextEvent() thing.  (Like you already do, when the user 
presses the interruptKeyCode, right? ;)

> Oh, and some idea of what
> situation originally lead to the prim timing code being added would be
> interesting if anyone remembers.

It had (IIRC) a lot to do with timing a 1ms Delay a zillion times, 
storing the results into a Bag, and then asking for its sortedCounts.

Cheers,
Ian

[Squeak-VMdev] primitive timing issues

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

I've been messing in the area of primitive calling and found a small
(5% - pMac) to big (150% - RISC OS) improvement in macrobenchmark
performance by removing the timing stuff that currently surrounds
primitive calls. (See primitiveResponse) I moved the timing to
primitiveExternalCall on the dodgy sounding but surprisingly practical
grounds that numbered prims are quick and named ones are slow.

Of course, with no timing check, those numbered prims (like
primRelinquishCPU) that _are_ cycle-hogs cause problems with Delay
triggering. For example, I found that 1mS Delays were taking 87mS to
get triggered because the primRelinquishCPU on RISC OS involves letting
other apps take control. Combine this with the use of the
interruptCheckCounter and naturally x-thousand quickChecks between full
CheckForInterrupts can stretch to a long time. Yes, it gradually goes
down but can take a while.

The obvious (and quite effective) hack is to have the long running prim set
interruptCheckCounter to 0, which is adequate unless there is some
psychopathic code in use that involves no real message sends nor backward
branches for a long period. I suspect that the writer of code like that
deserves late Delay triggering; along with keelhauling. The problem
that concerns me with this approach is that it involves calling
checkForInterrupts for every prim that we tag as long-running, at a
price of a ioMSecs() and perhaps worse the fairly fast ramping up of
interruptCheckCounterFeedBackReset. Imagine a loop calling a suspect
long-runner prim that turns out to go quickly most of the time; each
time around we go to checkForInterrupts and add 10 to the feedbackreset
value. Once out of that loop we may take a while to drag it down again
and suffer delayed Delays in the meantime. The actual runtime cost of
excess checkForInterrupts is mostly ioMSecs and a few tests. I suppose
we could consider more sophisticated handling of the feedback - perhaps
checking the most recent interval between 'now' and 'lastTick' for
being a multiple of interruptChecksEveryNms and aggresively reducing the
feedbackreset.

Given the apparent large differences between platforms' costs for time
checking, perhaps the best answer is to use a macro so that we can do
the right thing for each machine. It might be worth changing
checkForInterrupts to take the 'now' value as an arg so that macros
that need to get the time can reuse it?

To tag the primitives that need this timer check, I suggest that some
Slang equivalent of a pragma be tossed in. We can automagically add the
macro reference to each exit. There are however cases where the
potential slowness is also very platform dependent and we ought to
handle that. For example, getNextEvent could be very slow on RISC OS if
it allows some other app to run and that app goes off and calculates pi
to a gazillion places before returning. Some prims could be made long
running if they trigger a GC.

Summary: it seems worthwhile to avoid timing all prims since so many
are smaller than the timer code. Your thoughts on what checks various
platforms & circumstances need is solicited. Oh, and some idea of what
situation originally lead to the prim timing code being added would be
interesting if anyone remembers.

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Useful Latin Phrases:- Ne auderis delere orbem rigidum meum! = Don't you dare erase my hard disk!

Re: [Squeak-VMdev] SourceForge or SqueakForge?

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

Hi all!

Cees de Groot <cg...@tr...> wrote:
> On Sun, 2004-03-07 at 23:47, gor...@bl... wrote:
> > Anyway, Cees - how do we proceed in the simplest way? Will you set up a
> > new virtual box, or should we use the one we/I have for SM etc?
>
> Use the current one - if it necessitates more memory, just shout.

I migh do that. :)

> One of
> the advantages of dressing things up on this single VM is that in the
> case The InternetOne (my ISP) goes bust, we can easily transfer the
> whole setup to one of the relatively cheap User-Mode Linux hosting
> providers out there. I'm not expecting it, but it's not completely
> unlikely either (still harsh economic times) so I'm preparing SqF for
> this contingency; it would be too bad if all the work put into this
> would fall on the floor just because some obscure Dutch ISP can't manage
> to survive, wouldn't it?

Also - since it is just a Debian machine - I could always rig one at
Bluefish too.

> I'm still in personal circumstances that don't allow me to put a lot of
> time into this, so I can't help out a lot with the setup. But IIRC, we
> have most of it running already, not?

Yes, we do. I can look into it.
 
> Regards,
> 
> Cees

regards, Göran

Re: [Squeak-VMdev] SourceForge or SqueakForge?

[Cees de G. <cg...@tr...>]

On Sun, 2004-03-07 at 23:47, gor...@bl... wrote:
> Anyway, Cees - how do we proceed in the simplest way? Will you set up a
> new virtual box, or should we use the one we/I have for SM etc?
> 
Use the current one - if it necessitates more memory, just shout. One of
the advantages of dressing things up on this single VM is that in the
case The InternetOne (my ISP) goes bust, we can easily transfer the
whole setup to one of the relatively cheap User-Mode Linux hosting
providers out there. I'm not expecting it, but it's not completely
unlikely either (still harsh economic times) so I'm preparing SqF for
this contingency; it would be too bad if all the work put into this
would fall on the floor just because some obscure Dutch ISP can't manage
to survive, wouldn't it?

I'm still in personal circumstances that don't allow me to put a lot of
time into this, so I can't help out a lot with the setup. But IIRC, we
have most of it running already, not?

Regards,

Cees

Re: [Squeak-VMdev] SourceForge or SqueakForge?

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

Hi guys!

tim Rowledge <ti...@su...> wrote:
> OK, it sounds like a reasonable concensus for moving.
> 
> Is Cees on this list? Or is the explicit cc: needed? I hope that's a 
> working address...

Not, sure - I threw in cg...@tr... instead. I did check with Cees on IRC
the other day - he is game.

Anyway, Cees - how do we proceed in the simplest way? Will you set up a
new virtual box, or should we use the one we/I have for SM etc?

If someone else could take the time to do this I would be grateful - if
noone has the experience needed for CVS, then I might squeeze it in of
course. Or Ken/Marcus might help perhaps.

regards, Göran

Re: [Squeak-VMdev] SourceForge or SqueakForge?

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

OK, it sounds like a reasonable concensus for moving.

Is Cees on this list? Or is the explicit cc: needed? I hope that's a 
working address...

tim

Re: [Squeak-VMdev] SourceForge or SqueakForge?

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

Hi guys!

Just wanted t o say a few things since I have set up and managed some
CVS repos.

- Setting up a CVS server at Cees place is trivial.
- Setting up the web frontend Andreas mentions is also simple, I have
used it at a customer.
- Perhaps it is time though to consider using Subversion instead. It
sounds like a very good replacement which lacks the most glaring
problems in CVS.

Either way, it would feel better to have full control of this at Cees
place instead of at SF.
It also means we can easier integrate this stuff into the rest of
Squeak's web presence - like for example having nightly tar-balls etc.

regards, Göran

Re: [Squeak-VMdev] SourceForge or SqueakForge?

[John M M. <jo...@sm...>]

I've no issues with it.

We should leave the project page on sourceforge tho (drop the source  
files), and point to our new site.
Just makes it easier for folks who find old links to sourceforge for  
squeak, or if they are hunting for smalltalk etc on sourceforge.


On Mar 3, 2004, at 6:04 PM, tim Rowledge wrote:

>
>>>> Can we obtain it better by dropping SF?
> Sounds like a near unanimous opinion then. John?
>
> tim
--
======================================================================== 
===
John M. McIntosh <jo...@sm...> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===

Re: [Squeak-VMdev] SourceForge or SqueakForge?

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

Ian Piumarta wrote:

> I've stopped committing anything to CVS on SF since two months ago, when 
> Cees et al pointed out the ridiculous position of the SF people on our 
> "license [non-] problems" and suggested we drop them.
Same action, different reasons - I simply don't have a machine currently 
on the net that runs a CVS that I care to use. Still trying to find a 
place to buy on the Island...

>
> A CVS repository takes almost no time to set up, and then runs itself.  
> (The only "setup" required is related to creating cvs accounts for those 
> people who should have check-in privileges, and currently that would 
> seem to concern no more than four people on the planet.)
Hopefully that makes it something that Cees will be happy to handle. 
Actually, is Cees on this sublist?

>>> What would we like from a CVS archive?
> 
> 
> Err... "man cvs"?  ;) ;) ;)
That, surely, tells us what we get rather than what we'd like...

> 
>>> Can we obtain it better by dropping SF?
Sounds like a near unanimous opinion then. John?

tim

Re: [Squeak-VMdev] SourceForge or SqueakForge?

[Ian P. <ian...@in...>]

> From: "tim Rowledge" <ti...@su...>
> Sent: Thursday, March 04, 2004 12:53 AM
> Subject: [Squeak-VMdev] SourceForge or SqueakForge?
>
>> A while ago Cees did the initial setup to allow us the option of 
>> moving
>> our source code archive away from SourceForge now that they seem to
>> regard Squeak as some sort of unwlecome visitor. We should probably 
>> come
>> to some conclusion about whether the move should happen.

I've stopped committing anything to CVS on SF since two months ago, 
when Cees et al pointed out the ridiculous position of the SF people on 
our "license [non-] problems" and suggested we drop them.

>> I'd imagine that the chief advantage would be more personal service;
>> Cees is 'one of us' and supports Squeak in many ways. The main
>> disadvantage is probably that Cees has other things to do and 
>> presumably
>> smaller resources than SF. (Does anyone know?)

A CVS repository takes almost no time to set up, and then runs itself.  
(The only "setup" required is related to creating cvs accounts for 
those people who should have check-in privileges, and currently that 
would seem to concern no more than four people on the planet.)

(All Cees has to do is press the Big Red Button on the front panel 
whenever the server crashes. ;)

>> What would we like from a CVS archive?

Err... "man cvs"?  ;) ;) ;)

>> Can we obtain it better by dropping SF?

Well...

On 04 Mar 2004, at 01:07, Andreas Raab wrote:
> There are exactly two features at SF that I like: It's the ability to 
> browse through a CVS repository via the web

I've set up cvsweb on two systems in the past.  (Andreas has even used 
one of them.)  Modulo a couple of insignificant caveats, it's *trivial* 
(one cgi script to install, 1 line to modify to tell it where to look 
for cvsroot, and max 2 or 3 lines to modify in the httpd.conf file to 
give the script the permissions it needs).  After that it "just works". 
  As above, no "Cees intervention" required, ever.

FWIW, SF uses cvsweb to front their browsable repository.  If we made 
our own, you wouldn't be able to tell them apart.

> and the file releases which allows people to get this stuff from 
> "around the corner".

One web page (fronting the CVS web and the "release archives"), and 
some kind of restricted "Squeak release engineering" account on the 
server machine (or other, given NFS/whatever) to manage those archives, 
are all that's really required.

> Other than that the only thing I care about is uptime and Cees has 
> been pretty good on that in general.

Seconded.  I've no complaints at all in that respect.

Cheers,
Ian

Re: [Squeak-VMdev] SourceForge or SqueakForge?

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

Really, I don't care all that much. There are exactly two features at SF
that I like: It's the ability to browse through a CVS repository via the web
which is *very* helpful if you just want check a particular file without
having to do the whole CVS stuff and the file releases which allows people
to get this stuff from "around the corner". Other than that the only thing I
care about is uptime and Cees has been pretty good on that in general.

Cheers,
  - Andreas

----- Original Message ----- 
From: "tim Rowledge" <ti...@su...>
To: <squ...@li...>
Sent: Thursday, March 04, 2004 12:53 AM
Subject: [Squeak-VMdev] SourceForge or SqueakForge?


> A while ago Cees did the initial setup to allow us the option of moving
> our source code archive away from SourceForge now that they seem to
> regard Squeak as some sort of unwlecome visitor. We should probably come
> to some conclusion about whether the move should happen.
>
> I'd imagine that the chief advantage would be more personal service;
> Cees is 'one of us' and supports Squeak in many ways. The main
> disadvantage is probably that Cees has other things to do and presumably
> smaller resources than SF. (Does anyone know?)
>
> What would we like from a CVS archive? Can we obtain it better by
> dropping SF?
>
> tim
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Squeak-VMdev mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squeak-vmdev
>

[Squeak-VMdev] SourceForge or SqueakForge?

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

A while ago Cees did the initial setup to allow us the option of moving
our source code archive away from SourceForge now that they seem to
regard Squeak as some sort of unwlecome visitor. We should probably come
to some conclusion about whether the move should happen.

I'd imagine that the chief advantage would be more personal service;
Cees is 'one of us' and supports Squeak in many ways. The main
disadvantage is probably that Cees has other things to do and presumably
smaller resources than SF. (Does anyone know?)

What would we like from a CVS archive? Can we obtain it better by
dropping SF?

tim

[Squeak-VMdev] New CVS setup

[Bert F. <be...@im...>]

I guess the vmdev list is more appropriate for discussing this ... 
cc'ed.

- Bert -

Am 08.01.2004 um 12:11 schrieb Cees de Groot:

>  <squ...@li...> said:
>> Talk to Cees de Groot for possible hosting - I am just guessing 
>> though.
>> And if Cees is unwilling I might be able to set you up.
>>
> Ok, I have setup CVS and copied the SourceForge CVS tree to
> cvs.squeakfoundation.org.
>
> cvs -d:pserver:ano...@cv...:/squeak login
>
> (just hit enter when a password is asked)
>
> cvs -z3 -d:pserver:ano...@cv...:/squeak co squeak
>
> If everyone agrees with this move, it'd be nice if the project
> developers would stop committing on SourceForge and start mailing me
> confirmations that they are switching over. I will then use your
> SourceForge ssh public keys+account info to set you up (that's the 
> best way
> I can think of to get your public keys to me in some secure fashion...)
>
> For registered developers, the procedure is analogous to sourceforge:
>
> export CVS_RSH=ssh
> cvs -z3 -d:ext:use...@cv...:/cvsroot/squeak co 
> squeak
>
> If anyone wants an extra repository, I suggest they present their
> project plan here on the list, when everyone seems to agree that the
> project is worthwhile, I'll setup a CVS repository.

[Squeak-VMdev] [ENH[VM] becomeForward:copyHash: (2)

[Brent P. <bre...@ai...>]

Hi,
This is my second sumission of this enhancement. This version is compatible 
with the existing image.

Attached is a zip archive which implements changes neccessary to perform a 
becomeForward WITHOUT changing the identity hash bits of the argument. This 
change has been introduced at the request of Chris Muller who needs it to 
provide fully transparent persistance of symbols in his Magma database.

 Currently this will crash your image:
 	String new becomeForward: #size.

The new changes allow:
 	String new becomeForward: #size copyHash: false.

 This leaves #size identityHash unchanged.
 The changes require changes to the virtual machine. A new primitive, 249,
	
	Interpreter>>#primitiveArrayBecomeOneWayCopyHash

has been introduced. It is the same as the existing primitive, 72, 
primitiveArrayBecomeOneWay, except that it accepts the additional copyHash 
flag as an argument.

Changes to the image are also required to support the changed primitive and 
introduce #becomeForward:copyHash: and friends.

This enhancement DOES NOT require coordinated changes to the virtual 
machine and image. It is possible to change the virtual machine and use the 
existing images. Only when the new functionality is required, should the 
image changes be installed.

Testing
-------
The zip archive includes a SUnit test class.
In addition, I have used the new virtual machine to load all updates from a 
pristine 3.6alpha[5325] to 3.7alpha[5423]. I have performed this test with 
and without the image changes installed.

I would be most grateful if the vm high priests can advise me on how to 
prepare this change for inclusion as it is of clear benefit to the Magma 
database and has been discussed at length before.

The 925kB win32 Squeak.exe is available on request for those who wish to 
test but do not wish to build their own vm.

Regards
Brent

-- 
Brent Pinkney
Aircom International (SA) cell: +27 83 518 4167
tel: +27 11 324 3615
fax: +27 11 784 8027 e-mail: bre...@ai... 

[Squeak-VMdev] Re: [ENH] [VM] Object>>#becomeForward:copyHash: (2)

[Daniel V. <da...@ne...>]

Brent Pinkney <bre...@ai...> wrote:
> This enhancement does require coordinated (simultaneous) changes to both 
> the vm and image.
> 
> Should this requirement, which was the simplest thing which could possibly 
> work, prevent this from being included, I can easily rework the changes so 
> that the new functionality is implemented in a separate primitive.
Good idea. Otherwise it would have to wait for VI4, which has been
coming RSN for a long time now.

Daniel

[Squeak-VMdev] [ENH] [VM] Object>>#becomeForward:copyHash: (2)

[Brent P. <bre...@ai...>]

Hi,

Attached is a zip archive which implements changes neccessary to proform a 
becomeForward WITHOUT changing the identity hash bits of the argument.

This change has been introduced at the request of Chris Muller who needs it 
to provide fully transparent persistance of symbols in his Magma database.

Currently this will crash your image:

	String new becomeForward: #size.

The new changes allow:

	String new becomeForward: #size copyHash: false.

This leaves #size identityHash unchanged.

The changes require changes to the virtual machine. Primitive 72 
(a.k.a.primitiveArrayBecomeOneWay) now takes the additional copyHash flag 
as an argument.

Changes to the image are also required to support the changed primitive and 
introduce #becomeForward:copyHash: and friends.

This enhancement does require coordinated (simultaneous) changes to both 
the vm and image.

Should this requirement, which was the simplest thing which could possibly 
work, prevent this from being included, I can easily rework the changes so 
that the new functionality is implemented in a separate primitive.

I would be most grateful if the vm high priests can advise me on how to 
prepare this change for inclusion as it is of clear benefit to the Magma 
database and has been discussed at length before.

Sunit tests included.

The 925kB win32 Squeak.exe is available on request for those who wish to 
test but do not wish to build their own vm.

Regards

Brent

[Squeak-VMdev] [ENH] [VM] Object>>#becomeForward:copyHash:

[Brent P. <bre...@ai...>]

Hi,

Attached is a zip archive which implements changes neccessary to proform a 
becomeForward WITHOUT changing the identity hash bits of the argument.

This change has been introduced at the request of Chris Muller who needs it 
to provide fully transparent persistance of symbols in his Magma database.

Currently this will crash your image:

	String new becomeForward: #size.

The new changes allow:

	String new becomeForward: #size copyHash: false.

This leaves #size identityHash unchanged.

The changes require changes to the virtual machine. Primitive 72 
(a.k.a.primitiveArrayBecomeOneWay) now takes the additional copyHash flag 
as an argument.

Changes to the image are also required to support the changed primitive and 
introduce #becomeForward:copyHash: and friends.

This enhancement does require coordinated (simultaneous) changes to both 
the vm and image.

Should this requirement, which was the simplest thing which could possibly 
work, prevent this from being included, I can easily rework the changes so 
that the new functionality is implemented in a separate primitive.

I would be most grateful if the vm high priests can advise me on how to 
prepare this change for inclusion as it is of clear benefit to the Magma 
database and has been discussed at length before.

Sunit tests included.

The 925kB win32 Squeak.exe is available on request for those who wish to 
test but do not wish to build their own vm.

Regards

Brent

RE: [Squeak-VMdev] Anyone willing to vouch for me?

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

> Actually, by adding you as developer I implicitly vouched for you.

And just for the records, here's the vote from the primary platform
maintainers:



> -----Original Message-----
> From: John M McIntosh [mailto:jo...@sm...] 
> Sent: Saturday, August 02, 2003 7:54 PM
> To: ian...@in...
> Cc: Ned Konz; Andreas Raab
> Subject: Re: [Squeak-VMdev] Anyone willing to vouch for me?
> 
> 
> >
> >>   [X] ACCEPT (NK)
> >
> >   [X] VOUCH (IKP)
> >   [ X] VOUCH (AR)
> >
> 
>     [X] VOUCH (JMM)
> 
> --
> ==============================================================
> ========== 
> ===
> John M. McIntosh <jo...@sm...> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  
> http://www.smalltalkconsulting.com
> 
> ==============================================================
> ========== 
> ===
> 

Re: [Squeak-VMdev] So this is where everyone has been hanging out...

[Bert F. <be...@is...>]

Ian Piumarta wrote:

> On Sat, 2 Aug 2003, Bert Freudenberg wrote:
> 
> 
>>>If 3.6 is built from 3.4 then 3.5 will become 3.7. ;)
>>
>>Oh, so you're not yet too confident in your modular stuff?
> 
> 
> I've not had any problems with it, but then again I know which buttons not
> to press. ;)

Well ... I hope there won't be any confusion then. It's easier to 
remember that anything past 3.5 uses the new scheme. But if you think 
it's not yet stable enough, sure, build it on 3.4.

> One thing that 3.5 doesn't currently do (compared with 3.4) is parse
> options embedded in the #! interpreter line at the top of "self-executing"
> images.

I doubt that is used a lot ;-)

-- Bert