squeak-vmdev — CVS-related Virtual Machine Development Issues

[Squeak-VMdev] Re: GC improvements

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

>> Tim - is there any chance that we can get these changes into the 3.8
>> VMMaker? This stuff will be critical for the next Tweak version and 
>> having
>> it in the official 3.8 would heavily simplify migration.
> Perhaps you could chat with John about the GC monitoring code he
> suggested recently. There is a degree of overlap that you might be able
> to mutually remove, making my lif emuch simpler.

I haven't seen that code ... but what I am proposing here should allow us to 
run tuning code from the image instead of the VM.

> Aaaannnnnd, how is this going to relate to the 64bit code? I'm still
> waiting for some answers about that before doing anything much to
> vmmaker.

Just asked Ian about this today (I'll defer to him for an ultimate answer).

Cheers,
  - Andreas

[Squeak-VMdev] Re: GC improvements

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

In message <028001c4fdc6$34760c00$0301000a@R22>
          "Andreas Raab" <and...@gm...> wrote:

> Tim - is there any chance that we can get these changes into the 3.8 
> VMMaker? This stuff will be critical for the next Tweak version and having 
> it in the official 3.8 would heavily simplify migration.
Perhaps you could chat with John about the GC monitoring code he
suggested recently. There is a degree of overlap that you might be able
to mutually remove, making my lif emuch simpler.

Aaaannnnnd, how is this going to relate to the 64bit code? I'm still
waiting for some answers about that before doing anything much to
vmmaker.  


tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
"Bother," said Pooh, reading his bank statement from Barings.

[Squeak-VMdev] VMMaker fix for SVN

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

... so that VMMaker doesn't try to copy .snv directories.

Cheers,
  - Andreas

[Squeak-VMdev] GC improvements

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

Folks,

After some talking to Ian today he convinced to finally fix the one 
remaining issue with weak arrays, namely that weak arrays in old space hold 
on strongly to values in young space and therefore prevent those values to 
be garbage collected.

Fixing this turned actually out to be almost trivial - it's about ten lines 
of code or so and I really don't understand why I didn't fix this in the 
original version (but what the heck...) Since this exercise was so easy, I 
also added a number of GC related primitives all of which would have saved 
my day at some point in the past:

* primitiveIsYoung: This answers the question whether an object currently 
lives in young or in old space.

* primitiveIsRoot: Answers the question whether any given object is 
currently a root for young space.

* primitiveRootTable: Answers a snapshot of the current root table. Useful 
to examine the roots table if the analysis requires complex other operations 
during which the root table might be modified itself. Note that since this 
primitive can cause GC there is a small chance that it will give an 
inaccurate answer.

* primitiveRootTableAt: Answers a single element of the root table (by 
one-based index). This primitive can be used to quickly scan the root table 
for certain objects.

* primitiveSetGCSemaphore: Indicates a semaphore (index) to be signaled 
whenever a garbage collection occurs. I can see at least two uses uses for 
the GC semaphore: running cleanup actions (for example after full GCs 
occured) and dynamic parameter tuning for the GC algorithm itself.

Tim - is there any chance that we can get these changes into the 3.8 
VMMaker? This stuff will be critical for the next Tweak version and having 
it in the official 3.8 would heavily simplify migration.

Cheers,
  - Andreas

Re: [Squeak-VMdev] svn updates made for mac 3.8.5b1

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

In message <D53...@ma...>
          John M McIntosh <jo...@ma...> wrote:

> I've made my svn updates to bring the thrunk upto the mac 3.8.5b1 VM.
> 
> I'm curious about the winding down of the
> http://sourceforge.net/projects/squeak location
> Right now if you hunt about, will you arrive there and see old code, or
> arrive somewhere else and get
> the svn tree?
Good question. If we're actually moving to the svn server at hplabs
along with the mirroring previously discussed then it would be nice to
get it all setup for public access, announced, and the SF stuff killed
off for the 3.8 release  There's way too much chaos and confusion around
without adding more.


tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Disclaimer:  Any errors in spelling, tact, or fact are transmission errors.

[Squeak-VMdev] tags in SVN tree

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

I was chatting with Ian and I *think* I'm going to create tags  
(mac#.#.#bx) for 3.2.1 onwards so people can more easily build those VM
if they need/want to at some point in the far future.  Thoughts from  
anyone, as outlined to Ian I'll do an svn copy to create the tag


> Ah, so if I want to create a tag release for the mac 3.2.2 version so  
> that one could later pull back the mac3.2.2 build so you can build
> just that version would I do?
>
> svn copy -r 179 http://squeak.hpl.hp.com/svn/squeak/trunk   
> http://squeak.hpl.hp.com/svn/squeak/tags/mac3.2.2


--
======================================================================== 
===
John M. McIntosh <jo...@sm...> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===

[Squeak-VMdev] svn updates made for mac 3.8.5b1

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

I've made my svn updates to bring the thrunk upto the mac 3.8.5b1 VM.

I'm curious about the winding down of the
http://sourceforge.net/projects/squeak location
Right now if you hunt about, will you arrive there and see old code, or
arrive somewhere else and get
the svn tree?
--
======================================================================== 
===
John M. McIntosh <jo...@sm...> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===

Re: [Squeak-VMdev] Re: Developing a new event sensor

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

In message <02ed01c4f51a$79f8cd80$7b01a8c0@R22>
          "Andreas Raab" <and...@gm...> wrote:

> > It DOES NOT RUN in a normal image.
> 
> You mean this seriously? Then how do we load it?
Just load it as a normal  .mcz but don't do "InputEventSensor install" -
at least not if you expect to keep using the image. It might be amusing
to run it in a simulator but I haven't done so yet.

It's intended to only deliver events, no old state stuff at all and
lots of code in morphics/mvc appears to use that old stuff. I'm
assuming Tweak is pure and clean and wonderful and doesn't do that.

This 'release' is intended purely as an extended suggestion piece. It's
as simple I can make it today - I'm hoping somebody else can look at at
it and offer opinions on whether it is simple enough, or missing
something crucial for Tweak etc.

We also need to decide on some of the issues in my original mail since
they affect the design of both this and probably VM code. Certainly
there may need to be a subclass with an inputSemaphore mechanism if
anyone wants to actually make use of asynchronous event notification
from the VM.

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Fractured Idiom:- QUE SERA SERF - Life is feudal

Re: [Squeak-VMdev] Re: Developing a new event sensor

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

> It DOES NOT RUN in a normal image.

You mean this seriously? Then how do we load it?

Cheers,
  - Andreas

----- Original Message ----- 
From: "Tim Rowledge" <ti...@su...>
To: <squ...@li...>
Sent: Friday, January 07, 2005 10:49 PM
Subject: [Squeak-VMdev] Re: Developing a new event sensor


> Here's a first version. It DOES NOT RUN in a normal image. I
> deliberately haven't implemented all those state based methods from the
> old days and so running InputEventSensor (dumb name, suggest better
> please) install will crash your image. This is aimed mostly at Tweak
> but if anyone wanted to take on the massive image cleanup to make
> morphic and mvc work cleanly off events, great.
> 
> Feedback welcomed.
> 
> tim
> --
> Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
> Backups?  We doan *NEED* no steenking baX%^~,VbKx    NO CARRIER
>

[Squeak-VMdev] Re: Developing a new event sensor

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

Here's a first version. It DOES NOT RUN in a normal image. I
deliberately haven't implemented all those state based methods from the
old days and so running InputEventSensor (dumb name, suggest better
please) install will crash your image. This is aimed mostly at Tweak
but if anyone wanted to take on the massive image cleanup to make
morphic and mvc work cleanly off events, great.

Feedback welcomed.

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Backups?  We doan *NEED* no steenking baX%^~,VbKx    NO CARRIER

[Squeak-VMdev] Developing a new event sensor

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

Hi guys,
as a small part of cleaning things up for tweak and 4.0 etc I'm making
a start at a cleaned up event grabber. The current stuff is a nasty
mess of partially overridden methods and mixed use of variables that
needs termination asap.

A couple of questions for you:-

interrupt semaphore. InputSensor has a class variable and keeps a
semaphore in the special objects array and passes it to the vm, which
can then signal it directly. EventSensor uses an instvar, uses the prim
only 'as backwards compatability' and expects to trap the interrupt key
in the processEvent: method. Looking through the vm code I have it's
a bit tricky working out which VMs might be making use of the semaphore
directly. So, given a clean sheet, what would people prefer to do? I
must admit a small attachment to directly signalling from the vm.

interrupt key. Sort of used, sort of setup but completely not platform
specific and probably should be. 'cmd-.' is decidedly not suited to RISC
OS. As with the semaphore, there is a VM angle and we can decide what
to do in this new version.

inputSemaphore. I'm proposing to put this in a subclass that will add
support for platforms that can signal it asynchronously. Other
platforms don't need it - I think.

old state variables & methods. 'twould be nice to dump these so I hope
Tweak doesn't need them.

Comments and thoughts welcomed.

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: DNC: Do Not Collect $200

Re: [Squeak-VMdev] Proposed small changes to some Cross files

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

Hi Tim,

A few questions:
* What are current VMs supposed to fill for "windowIndex" in the events?
* Why a "SmallInt" window index if the field allows for a full 32bit value?
  (this would be extremely advantageous on windows as we could just use 
HANDLE value which I would absolutely want to use for a variety of reasons)
* What's a "WindowEventStinks"? Who would signal it and under which 
condition? (I have never heard of that before)

Otherwise it looks good to me.

Cheers,
 - Andreas

----- Original Message ----- 
From: "Tim Rowledge" <ti...@su...>
To: <squ...@li...>
Sent: Tuesday, December 07, 2004 10:46 AM
Subject: [Squeak-VMdev] Proposed small changes to some Cross files


> I'd like some yay/nay opinions on committing the attached small changes
> to sq.h et al. for the Ffenestri support. I can't see any chance of them
> causing damage but I try to be polite about these things when possible.
>
> One change is purely for RISC OS now that the CC has long long support,
> another is simply a comment change about timers (following on from the
> cached primitive function pointers changes) and the last is adding some
> event types for Ffenestri.
>
> If I don't hear any valid screams by the end of today I'll commit them
> to the SVN repository tonight and we'll see what happens.
>
> tim
> --
> Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
> Useful random insult:- Parked his head and forgot where he left it.
> 

[Squeak-VMdev] Proposed small changes to some Cross files

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

I'd like some yay/nay opinions on committing the attached small changes
to sq.h et al. for the Ffenestri support. I can't see any chance of them
causing damage but I try to be polite about these things when possible.

One change is purely for RISC OS now that the CC has long long support,
another is simply a comment change about timers (following on from the
cached primitive function pointers changes) and the last is adding some
event types for Ffenestri.

If I don't hear any valid screams by the end of today I'll commit them
to the SVN repository tonight and we'll see what happens.

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Useful random insult:- Parked his head and forgot where he left it.

[Squeak-VMdev] Re: spontaneous menu change

[Milan Z. <mil...@sy...>]

Ned,

Thanks. It sounds like what you are saying is this: "Caps Lock on" should=20
modify ONLY Keyboard events from keys A-Z. (not 123 Keyboard events.., not=
=20
mouse events).

=46WIW I agree, I confirmed this is the behaviour of following applications:

	Windows: Pbrush, Notepad
	Linux: Gimp, KWrite, others

=46rom the little I can understand, it seems your suggested change would ma=
ke=20
Linux Squeak VM behave in a way consistent with the above apps.

Milan

On November 28, 2004 01:41 pm, Ned Konz wrote:
> On Saturday 27 November 2004 4:21 pm, Doug Way wrote:
> > So, log it in Mantis as a bug.  (I guess I'll log it if no one else
> > already has.)  The fact that the bug doesn't happen on Windows & Mac OS
> > X makes it likely that it's a bug in the Linux VM... perhaps that VM is
> > specifically turning Caps Lock into Shift when it shouldn't, or
> > something.  At least, I assume that other Linux apps do not treat Caps
> > Lock exactly the same as holding down Shift...
>
> I'd say it's a bug too. Using xev, this is what I see coming straight from
> X:
>
> left-button press
> Caps lock Shift state
> 0 0 0
> 0 1 1
> 1 0 2
> 1 1 3
>
> A key
> Caps lock Shift state char
> 0 0 0 a
> 0 1 1 A
> 1 0 2 A
> 1 1 3 a
>
> 1 key
> Caps lock Shift state char
> 0 0 0 1
> 0 1 1 !
> 1 0 2 1
> 1 1 3 !
>
> So we do get a clear distinction between caps lock and shift, and the caps
> lock does indeed only affect letters.
>
> The bug appears to be in platforms/unix/vm-display-X11/sqUnixX11.c where =
we
> see:
>
> static int x2sqModifier(int state)
> {
>   int mods=3D 0;
>   if (optMapIndex || cmdMapIndex)
>     {
>       int shift=3D 1 & ((state >> ShiftMapIndex) ^ (state >> LockMapIndex=
));
>       int ctrl=3D  1 & (state >> ControlMapIndex);
>       int cmd=3D   1 & (state >> cmdMapIndex);
>       int opt=3D   1 & (state >> optMapIndex);
>       mods=3D (shift ? ShiftKeyBit   : 0)
>
>  |   (ctrl  ? CtrlKeyBit    : 0)
>  |   (cmd   ? CommandKeyBit : 0)
>  |   (opt   ? OptionKeyBit  : 0);
>
> etc.
>
> That is, we're always inverting the SHIFT state when we see a Caps Lock.
>
> But then we're calling XLookupString() to process the keystroke events, a=
nd
> it handles the Caps Lock correctly.
>
> So I'd argue that we should just look at the Shift and ignore the CapsLock
> altogether.
>
> That is:
>
>       int shift=3D 1 & (state >> ShiftMapIndex);
>
> Any thoughts on this? Would this cause any problems?
>
> Thanks,

[Squeak-VMdev] Re: spontaneous menu change

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

On Saturday 27 November 2004 4:21 pm, Doug Way wrote:

> So, log it in Mantis as a bug.  (I guess I'll log it if no one else
> already has.)  The fact that the bug doesn't happen on Windows & Mac OS
> X makes it likely that it's a bug in the Linux VM... perhaps that VM is
> specifically turning Caps Lock into Shift when it shouldn't, or
> something.  At least, I assume that other Linux apps do not treat Caps
> Lock exactly the same as holding down Shift...

I'd say it's a bug too. Using xev, this is what I see coming straight from X:

left-button press
Caps lock Shift state
0 0 0
0 1 1
1 0 2
1 1 3

A key
Caps lock Shift state char
0 0 0 a
0 1 1 A
1 0 2 A
1 1 3 a

1 key
Caps lock Shift state char
0 0 0 1
0 1 1 !
1 0 2 1
1 1 3 !

So we do get a clear distinction between caps lock and shift, and the caps 
lock does indeed only affect letters.

The bug appears to be in platforms/unix/vm-display-X11/sqUnixX11.c where we 
see:

static int x2sqModifier(int state)
{
  int mods= 0;
  if (optMapIndex || cmdMapIndex)
    {
      int shift= 1 & ((state >> ShiftMapIndex) ^ (state >> LockMapIndex));
      int ctrl=  1 & (state >> ControlMapIndex);
      int cmd=   1 & (state >> cmdMapIndex);
      int opt=   1 & (state >> optMapIndex);
      mods= (shift ? ShiftKeyBit   : 0)
 |   (ctrl  ? CtrlKeyBit    : 0)
 |   (cmd   ? CommandKeyBit : 0)
 |   (opt   ? OptionKeyBit  : 0);

etc.

That is, we're always inverting the SHIFT state when we see a Caps Lock.

But then we're calling XLookupString() to process the keystroke events, and it 
handles the Caps Lock correctly.

So I'd argue that we should just look at the Shift and ignore the CapsLock 
altogether.

That is:

      int shift= 1 & (state >> ShiftMapIndex);

Any thoughts on this? Would this cause any problems?

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

Re: [Squeak-VMdev] Securing imageNamePutLength()

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

Fine with me.

Cheers,
  - Andreas
----- Original Message ----- 
From: "Tim Rowledge" <ti...@su...>
To: <squ...@li...>
Sent: Wednesday, November 24, 2004 4:05 AM
Subject: [Squeak-VMdev] Securing imageNamePutLength()


> I'd like to improve the safety of the writing the image name; currently
> the slang code for primitiveImageName merely assumes success in writing
> absolutely anything you pass it. Since (so far as I can see) all
> platforms have a practical maximum path length it seems like a good
> thing to be able to return an indication as to whether the string was
> truly acceptable - size, illegal chars, plausible path, whatever suits
> the platform.
> 
> Right now all four main platforms do something different:-
> Acorn returns flase if the string cannot be canonicalised as a filename
> but returns default if ok!
> Mac returns the lesser of allowable image name size and actual length
> Unix returns the same
> Windows returns 1.
> 
> Can we agree that returning something uniform (say 0) to indicate that
> the prim should fail is a good idea? I'd like to make this a 3.8 thing
> if possible.
> 
> 
> tim
> --
> Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
> Oxymorons: Legally drunk
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Squeak-VMdev mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squeak-vmdev
>

Re: [Squeak-VMdev] Cleaning up Interpreter>writeImage:

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

On the mac I do
char *getImageName(void) {}
void SetImageNameViaString(char *string,UInt32 encoding) {}

and provide character set encoding information, so I never refer to the  
global directly, rather only thru methods that consider the
character encoding the VM is set to use.


On Nov 23, 2004, at 7:28 PM, Tim Rowledge wrote:

> In a similar vein to my previous email, I'd like to make a small
> cleanup in the writeImage code - it currently refers directly to
> 'imageName'. This feels nasty since it's not an ivar, a temp or
> anything accessible to the slang code - it's a C global kept mostly in
> blahMain.c or wherever. It just makes me cringe when I see it.
>
> We already have a prototype for a nice little getter function in sq.h,
> so could we try using
> char * getImageName(void); ?
>
> All it needs to be is
> char * getImageName(void) {
> 	return imageName;
> }
>
>
> tim
> --
> Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
> Strange OpCodes: ESR: Emulate Slide Rule
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real  
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Squeak-VMdev mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squeak-vmdev
>
>
--
======================================================================== 
===
John M. McIntosh <jo...@sm...> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===

[Squeak-VMdev] Cleaning up Interpreter>writeImage:

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

In a similar vein to my previous email, I'd like to make a small
cleanup in the writeImage code - it currently refers directly to
'imageName'. This feels nasty since it's not an ivar, a temp or
anything accessible to the slang code - it's a C global kept mostly in
blahMain.c or wherever. It just makes me cringe when I see it.

We already have a prototype for a nice little getter function in sq.h,
so could we try using
char * getImageName(void); ?

All it needs to be is
char * getImageName(void) {
	return imageName;
}


tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: ESR: Emulate Slide Rule

[Squeak-VMdev] Securing imageNamePutLength()

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

I'd like to improve the safety of the writing the image name; currently
the slang code for primitiveImageName merely assumes success in writing
absolutely anything you pass it. Since (so far as I can see) all
platforms have a practical maximum path length it seems like a good
thing to be able to return an indication as to whether the string was
truly acceptable - size, illegal chars, plausible path, whatever suits
the platform.

Right now all four main platforms do something different:-
Acorn returns flase if the string cannot be canonicalised as a filename
but returns default if ok!
Mac returns the lesser of allowable image name size and actual length
Unix returns the same
Windows returns 1.

Can we agree that returning something uniform (say 0) to indicate that
the prim should fail is a good idea? I'd like to make this a 3.8 thing
if possible.


tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Oxymorons: Legally drunk

Re: [Squeak-VMdev] [VM] Verification of struct foo differences on x86 needed

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

On Tuesday 23 November 2004 10:33 am, I wrote:
> * remove the UnixVMMaker>>createCodeGenerator method and repeat the above
> steps.

note that you may want to close the VMMaker window and re-open it (I'm not 
sure when the UnixVMMaker instance is created).

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

[Squeak-VMdev] [VM] Verification of struct foo differences on x86 needed

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

Hi all,

I noticed the other day that when I build a Linux/x86 VM using the global 
struct foo (which is the default for Unix) that it is faster than when I 
build without using the struct foo. That is, the bytecodes/sec speed is the 
same, and the sends/sec speed is 25-30% slower without struct foo.

This contradicted what Andreas had seen earlier; he's been *not* using the 
struct foo for his Windows builds.

Also, I found (as Andreas has) that gcc 2.95.4 produces a VM that is faster 
than the 3.3 or 3.4 gcc versions that I've tried. I'd earlier thought that a 
3.x version had produced faster code, but I guess I was wrong (or it was on a 
3.x version of GCC that I haven't tested recently).

Anyway, could someone with an x86 machine duplicate my test:

* make a clean build directory
* clean out the generated sources (assuming you're using Unix)
* generate VM sources
* configure and make the VM using GCC 2.95 and the -O3 flag:

 cd build
 CC=gcc-2.95 CFLAGS="-O3" ../platforms/unix/config/configure

run tinyBenchmarks on the resultant VM

then...

* remove the UnixVMMaker>>createCodeGenerator method and repeat the above 
steps.

Here's what I get for various configurations and compilers:

0 tinyBenchmarks

gcc 2.95.4, no struct foo, -O3
  '221837088 bytecodes/sec; 4782330 sends/sec'
  '219178082 bytecodes/sec; 4352264 sends/sec'

gcc 2.95.4, struct foo, -O3
'221453287 bytecodes/sec; 6569575 sends/sec'
 '203013481 bytecodes/sec; 6563459 sends/sec'

gcc 2.95.4, no struct foo
-O3
 '221070811 bytecodes/sec; 4743711 sends/sec'
  '221645021 bytecodes/sec; 4662139 sends/sec'

gcc 2.95.4, struct foo
-O3
 '222996515 bytecodes/sec; 6843839 sends/sec'
 '220309810 bytecodes/sec; 6739153 sends/sec'
-O3 -fno-gcse
 '113980409 bytecodes/sec; 5194661 sends/sec'

gcc 3.3.5, struct foo
-O3
   '200469851 bytecodes/sec; 6857154 sends/sec'
 '198603568 bytecodes/sec; 6778033 sends/sec'
-O2
 '202371541 bytecodes/sec; 6232674 sends/sec'
 '203984063 bytecodes/sec; 6113751 sends/sec'


gcc 3.4.2, struct foo
-O3
 '113374667 bytecodes/sec; 5276313 sends/sec'
 '111888111 bytecodes/sec; 5284224 sends/sec'

gcc 3.4.2, struct foo
-O3 -fnew-ra
 '113374667 bytecodes/sec; 5233225 sends/sec'
 '112379280 bytecodes/sec; 5217731 sends/sec'

gcc 3.4.2, struct foo
-O3 -fno-gcse
 '113174182 bytecodes/sec; 5190835 sends/sec'
 '112478031 bytecodes/sec; 5272367 sends/sec'

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

[Squeak-VMdev] SqueakForge etc

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

Hi all!

Given private email I have concluded that my "engagement" in this issue
is not needed. I hope you guys (the port maintainers) move ahead and
make things happen in whatever directions you have outlined and that
there will soon exist an up to date source code repository of the VM
source available on the net.

cheers, Göran

Re: [Squeak-VMdev] SourceForge or SqueakForge?

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

Hi fellow Squeakers! (good mood today :))

le...@cc... wrote:
> I've been using subversion for a while now (over a year) and now I
> always choose it over CVS when possible.  Some nice features are:
[SNIP of examples]
> Overall, my experience suggests that the summary given by others is
> correct: it is CVS with some of the annoying parts cleaned up.

Yes, I haven't used it myself but I agree - this is what it looks like
from everything I have read.

> As for accessing from Squeak, I expect that svn is harder to implement
> directly; CVS operates on one file at a time, while svn operations can
> be more complicated.

Eh... well, the main difference might be (given that I haven't looked at
Svn) that the client part of CVS is somewhat simple to implement (the
pserver protocol) because it is just a slave-mode-kinda-thing, all the
logic is on the server side. So the protocol is almost a trivial
remote-filesystem-protocol with some CVS-state-management thrown in. I
implemented it up to 90% in Sqcvs (why though escapes me for the moment,
but it was fun :)).

Perhaps Svn has a similar design of course and it would be easy.

And btw Darcs is also "bad" in this regard - since it is serverless all
the logic is "in the client" so to speak. So reimplementing those 3000
lines of Haskell is not an option :).

What we *could* do is of course to set up some kind of gateway
(regardless if we go with Svn/CVS/whatever) so that it is at least easy
to checkout/update the tree for readonly purposes.

Hacking up something like that would be fun.

> It's not necessary to implement svn natively,
> though, given that we have OSProcess arounnd.  Just fork-exec svn
> processes as necessary.

It wasn't "necessary" with CVS either - it is just that Tim has issues
on RiscOS (not sure what they are at the moment) and that there is a
"cleanliness" of course if we could have a mechanism that works on all
platforms that Squeak works including the really odd ones. But... of
course, we should also remember that there is always a dependency on the
other parts of the VM build system like gcc etc. So any VCS that builds
somewhat cleanly using gcc doesn't add any problem AFAICT.
 		
> Incidentally, if you do switch to SVN, be aware that you don't need to
> bother with all the HTTP-based stuff that they try to get you to use. 
> The "svn+ssh" mode works just fine and is equivalent to accessing CVS
> over ssh the familiar way it is done on SourceForge.
> 
> I don't know anything about darcs or about the different styles of VCS
> systems, so can't help there.
> 
> -Lex

Just a quick note about Darcs:

I just love it. :) Even if we don't go with Darcs for the Squeak VM (and
I suspect highly we won't, since the people that have the vote (=port
maintainers) are so much against it) I intend to set up a Darcs "mirror"
of the Squeak CVS and I also intend to use it for all my other personal
needs. It is just so damn wonderful.

I really, *really* recommend everyone to take a swift look just to
broaden your views, totally regardless of the Squeak VM hosting issue.
And it is EASY to play with it a few minutes.

regards, Göran

Re: [Squeak-VMdev] SourceForge or SqueakForge?

[<le...@cc...>]

Bert Freudenberg <be...@im...> wrote:
> Am 12.11.2004 um 21:15 schrieb le...@cc...:
> 
> > I've been using subversion for a while now (over a year) and now I
> > always choose it over CVS when possible.[...]
> > I don't know anything about darcs or about the different styles of VCS
> > systems, so can't help there.
> 
> Can we interpret this as
> 
>               CVS   SVN    DARCS
> Lex         -2       +2       0
> 
> ? ;-)
> 

Hmm, that sounds about right, but I had decided to abstain.  The people
who use it all the time should choose!  Just take this as warning that
if you use CVS, or if you switch to DARCS and it sucks, I will harp
forever about how SVN would have made things easier.  :)

Lex

Re: [Squeak-VMdev] Is there a problem accessing BFAV archive?

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

Please send your question to squ...@li... - this 
list is for discussion of vm related aspects only.

Cheers,
  - Andreas

----- Original Message ----- 
From: "David T. Lewis" <le...@ma...>
To: <squ...@li...>
Sent: Friday, November 12, 2004 10:44 AM
Subject: [Squeak-VMdev] Is there a problem accessing BFAV archive?


>
> I cannot seem to get BFAV to receive any updates more recent than 
> 03-Oct-2004.
>
> This is with a fresh Squeak3.7g2Full image, "Squeak3.7 of 4 September 2004 
> update 5989",
> with BFAV loaded from SqueakMap.
>
> I get the message "Last update failed" in the bottom message window of the
> BFAV PatchArchiveClient after doing a "load updates", which suggests some 
> kind
> of problem getting a complete update from the server.
>
> Am I just doing something stupid, or is anybody else having a problem with 
> this?
>
> Dave
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Squeak-VMdev mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squeak-vmdev
>