Smalltalk › Squeak › Squeak VM

linux 64bit vm running a 32 bit images - networking vm crash

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

tom-201

linux 64bit vm running a 32 bit images - networking vm crash

hi,

i am running a 64bit vm (elf64 / x86_64) linux, no i
have no 32bit compat x11 libs and i dont want to have
them...
the vm crashes on any network operation, any clues?

Program received signal SIGSEGV, Segmentation fault.
0x0000000000416711 in byteSizeOf (oop=-1398317376) at
gnu-interp.c:2902
2902 header = longAt(oop);
(gdb) bt
#0 0x0000000000416711 in byteSizeOf (oop=-1398317376)
at gnu-interp.c:2902
#1 0x00000000004a376d in
primitiveResolverStartNameLookup () at
.../platforms/unix/src/vm/intplugins/SocketPlugin/SocketPlugin.c:318
#2 0x0000000000416e76 in dispatchFunctionPointer
(aFunctionPointer=0xaca75ec0) at gnu-interp.c:3953
#3 0x0000000000416e76 in dispatchFunctionPointer
(aFunctionPointer=0xaca75ec0) at gnu-interp.c:3953
#4 0x000000000042abb1 in interpret () at
gnu-interp.c:7761
#5 0x0000000000415609 in main (argc=<value optimized
out>, argv=0x7fff3fd1cce8, envp=<value optimized out>)
...platforms/unix/vm/sqUnixMain.c:1379

Segmentation fault

23308044 [] in >addressForName:timeout:
23308136 [] in Semaphore>critical:
23307768 BlockContext>ensure:
23307676 Semaphore>critical:
23306908 >addressForName:timeout:
23299436 >httpGetDocument:args:accept:request:
23303844 >httpGet:args:accept:request:
23303380 >httpGet:args:user:passwd:
23303012 MCHttpRepository>allFileNames
23302896 MCFileBasedRepository>allFileNamesOrCache
23302788 MCFileBasedRepository>readableFileNames
23302696 MCFileRepositoryInspector>refresh
23302540
MCFileRepositoryInspector>setRepository:workingCopy:
23302356 >repository:workingCopy:
23302264 MCFileBasedRepository>morphicOpen:
23302448 [] in MCWorkingCopyBrowser>openRepository
23302172 Object>ifNotNilDo:
23302080 MCWorkingCopyBrowser>openRepository
23301620 PluggableButtonMorph>performAction
23301436 PluggableButtonMorphPlus>performAction
23301528 [] in PluggableButtonMorph>mouseUp:
23301344 SequenceableCollection>do:
23301252 PluggableButtonMorph>mouseUp:
23301120 PluggableButtonMorphPlus>mouseUp:
23301028 Morph>handleMouseUp:
23300936 MouseButtonEvent>sentTo:
23300568 Morph>handleEvent:
23300476 Morph>handleFocusEvent:
23300660 [] in HandMorph>sendFocusEvent:to:clear:
23300752 [] in PasteUpMorph>becomeActiveDuring:
23300384 BlockContext>on:do:
23300292 PasteUpMorph>becomeActiveDuring:
23300016 HandMorph>sendFocusEvent:to:clear:
23299924 HandMorph>sendEvent:focus:clear:
23299832 HandMorph>sendMouseEvent:
23299344 HandMorph>handleEvent:
23293552 HandMorph>processEvents
23293668 [] in WorldState>doOneCycleNowFor:
23293460 SequenceableCollection>do:
23293368 WorldState>handsDo:
23293276 WorldState>doOneCycleNowFor:
23291300 WorldState>doOneCycleFor:
23291208 PasteUpMorph>doOneCycle
14434012 [] in >spawnNewProcess
14434196 [] in BlockContext>newProcess

thanks in andvance ;)

__________________________________ Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever

Martin Kuball

Re: linux 64bit vm running a 32 bit images - networking vm crash

Hi Tom,

you could try using the appended version of SocketPlugin.c. Copy it to
plattform/unix/src/vm/intplugins/SocketPlugin and build the vm. If you use
a different src-folder for the VMMaker stuff change the path acordingly.

I reported that bug some time ago on this list. But I failed to create a
mantis entry, though. Shame on me.

Martin

Am Tuesday 29 May 2007 schrieb tom:

> hi,
>
> i am running a 64bit vm (elf64 / x86_64) linux, no i
> have no 32bit compat x11 libs and i dont want to have
> them...
> the vm crashes on any network operation, any clues?
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000416711 in byteSizeOf (oop=-1398317376) at
> gnu-interp.c:2902
> 2902 header = longAt(oop);
> (gdb) bt
> #0 0x0000000000416711 in byteSizeOf (oop=-1398317376)
> at gnu-interp.c:2902
> #1 0x00000000004a376d in
> primitiveResolverStartNameLookup () at
> .../platforms/unix/src/vm/intplugins/SocketPlugin/SocketPlugin.c:318
> #2 0x0000000000416e76 in dispatchFunctionPointer
> (aFunctionPointer=0xaca75ec0) at gnu-interp.c:3953
> #3 0x0000000000416e76 in dispatchFunctionPointer
> (aFunctionPointer=0xaca75ec0) at gnu-interp.c:3953
> #4 0x000000000042abb1 in interpret () at
> gnu-interp.c:7761
> #5 0x0000000000415609 in main (argc=<value optimized
> out>, argv=0x7fff3fd1cce8, envp=<value optimized out>)
> ...platforms/unix/vm/sqUnixMain.c:1379
>
> Segmentation fault
>
> 23308044 [] in >addressForName:timeout:
> 23308136 [] in Semaphore>critical:
> 23307768 BlockContext>ensure:
> 23307676 Semaphore>critical:
> 23306908 >addressForName:timeout:
> 23299436 >httpGetDocument:args:accept:request:
> 23303844 >httpGet:args:accept:request:
> 23303380 >httpGet:args:user:passwd:
> 23303012 MCHttpRepository>allFileNames
> 23302896 MCFileBasedRepository>allFileNamesOrCache
> 23302788 MCFileBasedRepository>readableFileNames
> 23302696 MCFileRepositoryInspector>refresh
> 23302540
> MCFileRepositoryInspector>setRepository:workingCopy:
> 23302356 >repository:workingCopy:
> 23302264 MCFileBasedRepository>morphicOpen:
> 23302448 [] in MCWorkingCopyBrowser>openRepository
> 23302172 Object>ifNotNilDo:
> 23302080 MCWorkingCopyBrowser>openRepository
> 23301620 PluggableButtonMorph>performAction
> 23301436 PluggableButtonMorphPlus>performAction
> 23301528 [] in PluggableButtonMorph>mouseUp:
> 23301344 SequenceableCollection>do:
> 23301252 PluggableButtonMorph>mouseUp:
> 23301120 PluggableButtonMorphPlus>mouseUp:
> 23301028 Morph>handleMouseUp:
> 23300936 MouseButtonEvent>sentTo:
> 23300568 Morph>handleEvent:
> 23300476 Morph>handleFocusEvent:
> 23300660 [] in HandMorph>sendFocusEvent:to:clear:
> 23300752 [] in PasteUpMorph>becomeActiveDuring:
> 23300384 BlockContext>on:do:
> 23300292 PasteUpMorph>becomeActiveDuring:
> 23300016 HandMorph>sendFocusEvent:to:clear:
> 23299924 HandMorph>sendEvent:focus:clear:
> 23299832 HandMorph>sendMouseEvent:
> 23299344 HandMorph>handleEvent:
> 23293552 HandMorph>processEvents
> 23293668 [] in WorldState>doOneCycleNowFor:
> 23293460 SequenceableCollection>do:
> 23293368 WorldState>handsDo:
> 23293276 WorldState>doOneCycleNowFor:
> 23291300 WorldState>doOneCycleFor:
> 23291208 PasteUpMorph>doOneCycle
> 14434012 [] in >spawnNewProcess
> 14434196 [] in BlockContext>newProcess
>
> thanks in andvance ;)
>
>
> __________________________________ Kennt man wirklich jeden über
> 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever

SocketPlugin.c (40K) Download Attachment

David T. Lewis

Re: linux 64bit vm running a 32 bit images - networking vm crash

In reply to this post by tom-201

On Tue, May 29, 2007 at 12:50:45PM +0200, tom wrote:
>
> i am running a 64bit vm (elf64 / x86_64) linux, no i
> have no 32bit compat x11 libs and i dont want to have
> them...
> the vm crashes on any network operation, any clues?

In your platforms directory (the one you got from Subversion), the
sqMemoryAccess.h file needs a patch. This is in Mantis bug report #4608
<http://bugs.squeak.org/view.php?id=4608>, and the actual patched file
is <http://bugs.squeak.org/file_download.php?file_id=2809&type=bug>.

Also apply the fix in Mantis #5688. You don't need this to get a running
VM, but you will not be able to connect to SqueakMap until you have
included this fix in your VM.

See also the reply from Martin Kuball. I'm not sure if the patch on
Mantix #5688 addresses the same issue, but possible it does. In any
case, #4608 and #5688 are sufficient to give you a working VM on
64-bit Linux systems.

There are some other issues listed in the Mantis "Squeak 64 bit" category,
but I don't think you need to worry about them if you are just running
32 bit images.

Dave

Philippe Marschall

Re: linux 64bit vm running a 32 bit images - networking vm crash

2007/5/30, David T. Lewis <[hidden email]>:

>
> On Tue, May 29, 2007 at 12:50:45PM +0200, tom wrote:
> >
> > i am running a 64bit vm (elf64 / x86_64) linux, no i
> > have no 32bit compat x11 libs and i dont want to have
> > them...
> > the vm crashes on any network operation, any clues?
>
> In your platforms directory (the one you got from Subversion), the
> sqMemoryAccess.h file needs a patch. This is in Mantis bug report #4608
> <http://bugs.squeak.org/view.php?id=4608>, and the actual patched file
> is <http://bugs.squeak.org/file_download.php?file_id=2809&type=bug>.
>
> Also apply the fix in Mantis #5688. You don't need this to get a running
> VM, but you will not be able to connect to SqueakMap until you have
> included this fix in your VM.
>
> See also the reply from Martin Kuball. I'm not sure if the patch on
> Mantix #5688 addresses the same issue, but possible it does. In any
> case, #4608 and #5688 are sufficient to give you a working VM on
> 64-bit Linux systems.
>
> There are some other issues listed in the Mantis "Squeak 64 bit" category,
> but I don't think you need to worry about them if you are just running
> 32 bit images.

Why are these patches not included if you need them to get a working VM?

Cheers
Philippe

> Dave
>
>

Andreas.Raab

Re: linux 64bit vm running a 32 bit images - networking vm crash

Philippe Marschall wrote:
> Why are these patches not included if you need them to get a working VM?

Because people are busy and there has been a (to me) astonishing lack of
interest in 64 bit VMs.

Cheers,
- Andreas

Philippe Marschall

Re: linux 64bit vm running a 32 bit images - networking vm crash

2007/5/30, Andreas Raab <[hidden email]>:
>
> Philippe Marschall wrote:
> > Why are these patches not included if you need them to get a working VM?
>
> Because people are busy and there has been a (to me) astonishing lack of
> interest in 64 bit VMs.

I know several people how have a 64bit system and don't run 64bit VMs
exactly because of all these issues to get them working.

Cheers
Philippe

> Cheers,
> - Andreas
>

Martin Kuball

Re: linux 64bit vm running a 32 bit images - networking vm crash

Am Wednesday 30 May 2007 schrieb Philippe Marschall:

> 2007/5/30, Andreas Raab <[hidden email]>:
> > Philippe Marschall wrote:
> > > Why are these patches not included if you need them to get a working
> > > VM?
> >
> > Because people are busy and there has been a (to me) astonishing lack
> > of interest in 64 bit VMs.
>
> I know several people how have a 64bit system and don't run 64bit VMs
> exactly because of all these issues to get them working.

Please keep trying. I'm really interested in making this work and getting
the fixes into svn and VMMaker (although I wasn't really active in this
regard lately).

Martin

Andreas.Raab

Re: linux 64bit vm running a 32 bit images - networking vm crash

In reply to this post by Philippe Marschall

Philippe Marschall wrote:

> 2007/5/30, Andreas Raab <[hidden email]>:
>> Philippe Marschall wrote:
>> > Why are these patches not included if you need them to get a working
>> VM?
>>
>> Because people are busy and there has been a (to me) astonishing lack of
>> interest in 64 bit VMs.
>
> I know several people how have a 64bit system and don't run 64bit VMs
> exactly because of all these issues to get them working.

But you seem to be the first person to show any reaction in a couple of
months (check the list archives).

Cheers,
- Andreas

Philippe Marschall

Re: linux 64bit vm running a 32 bit images - networking vm crash

2007/5/30, Andreas Raab <[hidden email]>:

>
> Philippe Marschall wrote:
> > 2007/5/30, Andreas Raab <[hidden email]>:
> >> Philippe Marschall wrote:
> >> > Why are these patches not included if you need them to get a working
> >> VM?
> >>
> >> Because people are busy and there has been a (to me) astonishing lack of
> >> interest in 64 bit VMs.
> >
> > I know several people how have a 64bit system and don't run 64bit VMs
> > exactly because of all these issues to get them working.
>
> But you seem to be the first person to show any reaction in a couple of
> months (check the list archives).

Just by checking the mailing list posts you would guess that Seaside
has about a dozen of users. It's sometimes amazing to find out what
users you have that you never heard about or didn't even subscribe to
the mailing list.

Cheers
Philippe

timrowledge

Re: linux 64bit vm running a 32 bit images - networking vm crash

In reply to this post by Martin Kuball

Martin - and others of course - what exactly do you want a 64bit vm
for? Do you really need more than 4gb sized object memory spaces?
What benefit is there to running a 64bit integer baesed vm with a
32bit oop based image? Perhaps I'm forgetting something but it
doesn't seem like anything terribly useful.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SSAN: Stop, and See if Anyone Notices

Chris Muller-3

Re: linux 64bit vm running a 32 bit images - networking vm crash

I don't want a 4GB image, but I may want a lot of normal-sized Squeak
images running on a piece of "big-iron". But I guess the current VM's
have some problem where the oop was defined as signed, so images
cannot even *reside* above 1GB (or whatever it is).

So even if that was fixed, that would take 32-bit Squeak up to 4GB
boundary, only if all 32-bits were for the oop.

... I saw this ad on the back of InfoRag earlier today. Some IBM
blade, multi-Xeon-multi-core, up to 48GB high-speed RAM, "starting" at
$2K. Cool, this could probably run a lot of images simultaneously,
but how far could you go with 32-bit Squeak on this?

On 5/30/07, tim Rowledge <[hidden email]> wrote:

>
> Martin - and others of course - what exactly do you want a 64bit vm
> for? Do you really need more than 4gb sized object memory spaces?
> What benefit is there to running a 64bit integer baesed vm with a
> 32bit oop based image? Perhaps I'm forgetting something but it
> doesn't seem like anything terribly useful.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: SSAN: Stop, and See if Anyone Notices
>
>
>

johnmci

Re: linux 64bit vm running a 32 bit images - networking vm crash

On May 30, 2007, at 6:17 PM, Chris Muller wrote:

> I don't want a 4GB image, but I may want a lot of normal-sized Squeak
> images running on a piece of "big-iron". But I guess the current VM's
> have some problem where the oop was defined as signed, so images
> cannot even *reside* above 1GB (or whatever it is).

2GB, and lurking are changes to fix that issue, but someone has to
buckle down
and do testing, then mmm say oh yes should be fixed. But how would
you know?

>
> So even if that was fixed, that would take 32-bit Squeak up to 4GB
> boundary, only if all 32-bits were for the oop.
>
> ... I saw this ad on the back of InfoRag earlier today. Some IBM
> blade, multi-Xeon-multi-core, up to 48GB high-speed RAM, "starting" at
> $2K. Cool, this could probably run a lot of images simultaneously,
> but how far could you go with 32-bit Squeak on this?

Depends on the image footprint, 3GB images then what 15 or so
Plus then one cpu needed for each Squeak VM, plus a couple of spares
to do
operating system I/O, housekeeping etc. etc.

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===

Chris Muller-3

Re: linux 64bit vm running a 32 bit images - networking vm crash

Cool, I think you're saying, once the signed oop is fixed, there
should be no problem with memory locations beyond 4GB. Curious
though, why the signed-oop bug also affects where images *start* in
memory instead of only how large they could be.. Given (theoretical)
unlimited memory, then, does the signed-oop fix allow an unlimited
number of running Squeak images?

I wasn't sure because of the image being referred as "direct-pointer";
thought that might mean hard-referenced memory locations limited to 32
bits.

thanks.

On 5/30/07, John M McIntosh <[hidden email]> wrote:

>
>
> On May 30, 2007, at 6:17 PM, Chris Muller wrote:
>
> > I don't want a 4GB image, but I may want a lot of normal-sized Squeak
> > images running on a piece of "big-iron". But I guess the current VM's
> > have some problem where the oop was defined as signed, so images
> > cannot even *reside* above 1GB (or whatever it is).
>
> 2GB, and lurking are changes to fix that issue, but someone has to
> buckle down
> and do testing, then mmm say oh yes should be fixed. But how would
> you know?
>
> >
> > So even if that was fixed, that would take 32-bit Squeak up to 4GB
> > boundary, only if all 32-bits were for the oop.
> >
> > ... I saw this ad on the back of InfoRag earlier today. Some IBM
> > blade, multi-Xeon-multi-core, up to 48GB high-speed RAM, "starting" at
> > $2K. Cool, this could probably run a lot of images simultaneously,
> > but how far could you go with 32-bit Squeak on this?
>
> Depends on the image footprint, 3GB images then what 15 or so
> Plus then one cpu needed for each Squeak VM, plus a couple of spares
> to do
> operating system I/O, housekeeping etc. etc.
>
> --
> ========================================================================
> ===
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> ========================================================================
> ===
>
>
>

K. K. Subramaniam

Re: linux 64bit vm running a 32 bit images - networking vm crash

In reply to this post by Chris Muller-3

On Thursday 31 May 2007 6:47 am, Chris Muller wrote:
> ... I saw this ad on the back of InfoRag earlier today. Some IBM
> blade, multi-Xeon-multi-core, up to 48GB high-speed RAM, "starting" at
> $2K. Cool, this could probably run a lot of images simultaneously,
> but how far could you go with 32-bit Squeak on this?
Chris,

Look at it this way - given the huge test cycles and the number of bugs that
leak past into processes with 20MB footprint, would you trust processes that
need a 100x footprint? or would you settle for a bunch of co-operating
processes (like Croquet) ? Those 48GB RAM continue to consume energy even
when your memory usage drops to 1GB. 2K looks cheap till you get the power
bill :-).

The 32-bit to 64-bit transition is going to be much painful and much more
longer than the 16-32b transition.

Regards .. Subbu

johnmci

Re: linux 64bit vm running a 32 bit images - networking vm crash

In reply to this post by Chris Muller-3

On May 30, 2007, at 8:22 PM, Chris Muller wrote:

> Cool, I think you're saying, once the signed oop is fixed, there
> should be no problem with memory locations beyond 4GB. Curious
> though, why the signed-oop bug also affects where images *start* in
> memory instead of only how large they could be.. Given (theoretical)
> unlimited memory, then, does the signed-oop fix allow an unlimited
> number of running Squeak images?
>
> I wasn't sure because of the image being referred as "direct-pointer";
> thought that might mean hard-referenced memory locations limited to 32
> bits.
>
> thanks.

This issue is if the oops value becomes negative. A image is located
in memory at point X, if image size + X > 2GB, you'll die. The direct
object reference pointer *IS* a memory address, all references are
swizzled at image load time so that the object reference value
becomes the memory address. It's still a object reference, don't
forget, however at some point people
do compares on it, and signed versus unsigned compares have different
meanings.

There should be no problem with memory in the 2GB to 4GB range for
32bits. images once the fix is done, tested, and given the VM good
housekeeping seal of approval.

For 64bit images right now you have no problems with the range
0-2^63 which is a lot.... Can you even assemble a disk farm that
will provide that backing store?

The fix will double that to 2^64.

Note of course you can't get *all* the address space, most operating
system maps out large chunks for memory mapped devices, ROM, etc etc.

The number of squeak images you can run is limited by the combined
total of memory and Virtual Memory swapping store. Some operating system
take an optimistic viewpoint (BSD) and just pretend to give you the
memory, and you pretend to use it. If you do and exceed all nooks and
crannies of
the storage system, then some Process will die...

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===

Bert Freudenberg

Re: linux 64bit vm running a 32 bit images - networking vm crash

In reply to this post by Chris Muller-3

On May 31, 2007, at 5:22 , Chris Muller wrote:

> Cool, I think you're saying, once the signed oop is fixed, there
> should be no problem with memory locations beyond 4GB.

No - each process in the operating system gets their own virtual
memory space. As long as your image is not larger than 4 GB you can
run the 32-bit version, but as many copies of it as RAM+Swap allows.
Each one will see its address space starting at 0 going up to 4 GB.
There is no "memory locations beyond 4GB" for a 32 bit process, but
the big irons can run many of them.

- Bert -

K. K. Subramaniam

Re: linux 64bit vm running a 32 bit images - networking vm crash

On Thursday 31 May 2007 1:48 pm, Bert Freudenberg wrote:
> On May 31, 2007, at 5:22 , Chris Muller wrote:
> > Cool, I think you're saying, once the signed oop is fixed, there
> > should be no problem with memory locations beyond 4GB.
>
> No - each process in the operating system gets their own virtual
> memory space. As long as your image is not larger than 4 GB you can
> run the 32-bit version, but as many copies of it as RAM+Swap allows.
4GB limit applies to the total per-process virtual space. If the space taken
up per-process kernel structures and internal fragmentation etc. are
accounted for, the limit on image size may work out somewhere between 3 to
3.5GB.

Regards .. Subbu

Martin Kuball

Re: linux 64bit vm running a 32 bit images - networking vm crash

In reply to this post by timrowledge

Am Thursday 31 May 2007 schrieb tim Rowledge:

> Martin - and others of course - what exactly do you want a 64bit vm
> for? Do you really need more than 4gb sized object memory spaces?
> What benefit is there to running a 64bit integer baesed vm with a
> 32bit oop based image? Perhaps I'm forgetting something but it
> doesn't seem like anything terribly useful.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: SSAN: Stop, and See if Anyone Notices

Well, I'm running a 64bit Linux and I don't want to change into a 32bit
environment to run squeak. That's all. And it works for me. The memory
access bug is fixed. And if I get some positive feedback from Philippe
about the network bug I will post a CS for VMMaker.

From my point of view it's just a matter of having the choice. And I think
people should have the choice If we can provide it.

Martin

tom-201

Re: linux 64bit vm running a 32 bit images - networking vm crash

In reply to this post by Andreas.Raab

--- Andreas Raab <[hidden email]> schrieb:

>
> Philippe Marschall wrote:
> > Why are these patches not included if you need
> them to get a working VM?
>
> Because people are busy and there has been a (to me)
> astonishing lack of
> interest in 64 bit VMs.
>
> Cheers,
> - Andreas
>

well, in case someone else wants to use a 64bit vm
with an 32bit image attached there is an unified patch
against vanilla 3.9-9 vm to fix sqMemoryAccess and
SocketPlugin, should be fixed at the right place but
at least this way you get a working vm + working
socket plugin ...

___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

64bit-vm.diff (3K) Download Attachment

timrowledge

Re: linux 64bit vm running a 32 bit images - networking vm crash

In reply to this post by Martin Kuball

On 31-May-07, at 9:39 AM, Martin Kuball wrote:

>
> Well, I'm running a 64bit Linux and I don't want to change into a
> 32bit
> environment to run squeak. That's all.

Somebody is going to have to explain this to me. Why would you have
to "change into a 32bit environment" ?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Oblitus sum perpolire clepsydras! = I forgot
to polish the clocks!