Smalltalk › Squeak › Squeak VM

Compiling squeak-vm for Linux 64bit

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

25 messages Options

whaevr

Compiling squeak-vm for Linux 64bit

Been trying to compile the latest squeak-vm (version 3.10-4) for x86_64 Linux, heres my configure line:

./Squeak-$_realver/platforms/unix/config/configure --prefix=/usr --without-quartz --with-x --enable-mpg-mmx

Ignore the $_realver its a variable used in the pkgbuild. It gets through configure but on running make it stops with the following error:

vm/vm.a(sqUnixMain.o): In function `vm_parseEnvironment':
sqUnixMain.c:(.text+0x15ad): undefined reference to `setLocaleEncoding'
vm/vm.a(sqNamedPrims.o):(.data+0x68): undefined reference to `FileCopyPlugin_exports'
vm/vm.a(sqNamedPrims.o):(.data+0xc0): undefined reference to `MIDIPlugin_exports'
vm/vm.a(sqNamedPrims.o):(.data+0xd0): undefined reference to `Mpeg3Plugin_exports'
collect2: ld returned 1 exit status
make: *** [squeak] Error 1

I've attached a full log of the compiler's output.

I can successfully compile version 3.9.8 with the same configure line.

log.txt (25K) Download Attachment

David T. Lewis

Re: Compiling squeak-vm for Linux 64bit

On Sat, Mar 14, 2009 at 09:15:18PM -0400, whaevr wrote:

>
> Been trying to compile the latest squeak-vm (version 3.10-4) for x86_64
> Linux, heres my configure line:
>
> ./Squeak-$_realver/platforms/unix/config/configure --prefix=/usr
> --without-quartz --with-x --enable-mpg-mmx
>
> Ignore the $_realver its a variable used in the pkgbuild. It gets through
> configure but on running make it stops with the following error:
>
>
> vm/vm.a(sqUnixMain.o): In function `vm_parseEnvironment':
> sqUnixMain.c:(.text+0x15ad): undefined reference to `setLocaleEncoding'
> vm/vm.a(sqNamedPrims.o):(.data+0x68): undefined reference to
> `FileCopyPlugin_exports'
> vm/vm.a(sqNamedPrims.o):(.data+0xc0): undefined reference to
> `MIDIPlugin_exports'
> vm/vm.a(sqNamedPrims.o):(.data+0xd0): undefined reference to
> `Mpeg3Plugin_exports'
> collect2: ld returned 1 exit status
> make: *** [squeak] Error 1

Hi Pat, thanks for joining the vm-dev list.

(Note to list: Pat is trying to build a 64-bit Linux distribution package
for a Squeak vm that can run an OLPC image. Bert and I suggested that we
move the discussion to this list.)

Pat, can you clarify where you obtained the source code for version
3.10-4? I am assuming that you are using sources that contain support
for OLPC, but I'm not sure if you are getting them directly from the
Subversion repository or from some other site. I want to try to reproduce
the problem on my PC if possible.

For your reference, when I build a 64-bit VM (for my personal use, I
do not distribute it), I will get the sources directly from Subversion
as follows:
$ svn co http://squeakvm.org/svn/squeak/trunk squeak-svn-source

I assume that you are building the VM using the sources found in
the ./platforms/unix/src directory. It may not be obvious, but the
files in this directory are actually intermediate files, the result
of automatic code generation from the "real" sources, which are
written in Smalltalk and maintained in the Squeak image (in a package
called "VMMaker").

This is important for building the VM on 64-bit Linux, because there
are a number of updates in the Smalltalk VMMaker sources needed for
a 64-bit that may not yet be reflected in the files that you find
in your platforms/unix/src directory. Likewise, there are changes
in the OLPC VMMaker sources that may not yet have been included in
the generic VMMaker (and we want to sort that out of course).

Let me know where you downloaded your sources from, and I'll try
to reproduce the errors.

Dave

Bert Freudenberg

Re: Compiling squeak-vm for Linux 64bit

On 15.03.2009, at 14:54, David T. Lewis wrote:

>
> On Sat, Mar 14, 2009 at 09:15:18PM -0400, whaevr wrote:
>>
>> Been trying to compile the latest squeak-vm (version 3.10-4) for
>> x86_64
>> Linux, heres my configure line:
>>
>> ./Squeak-$_realver/platforms/unix/config/configure --prefix=/usr
>> --without-quartz --with-x --enable-mpg-mmx
>>
>> Ignore the $_realver its a variable used in the pkgbuild. It gets
>> through
>> configure but on running make it stops with the following error:
>>
>>
>> vm/vm.a(sqUnixMain.o): In function `vm_parseEnvironment':
>> sqUnixMain.c:(.text+0x15ad): undefined reference to
>> `setLocaleEncoding'
>> vm/vm.a(sqNamedPrims.o):(.data+0x68): undefined reference to
>> `FileCopyPlugin_exports'
>> vm/vm.a(sqNamedPrims.o):(.data+0xc0): undefined reference to
>> `MIDIPlugin_exports'
>> vm/vm.a(sqNamedPrims.o):(.data+0xd0): undefined reference to
>> `Mpeg3Plugin_exports'
>> collect2: ld returned 1 exit status
>> make: *** [squeak] Error 1
>
> Hi Pat, thanks for joining the vm-dev list.
>
> (Note to list: Pat is trying to build a 64-bit Linux distribution
> package
> for a Squeak vm that can run an OLPC image. Bert and I suggested
> that we
> move the discussion to this list.)
>
> Pat, can you clarify where you obtained the source code for version
> 3.10-4? I am assuming that you are using sources that contain support
> for OLPC, but I'm not sure if you are getting them directly from the
> Subversion repository or from some other site. I want to try to
> reproduce
> the problem on my PC if possible.

I told Pat to use the official sources, so this should be the tarball
from

http://squeakvm.org/unix/

We have merged the olpc branch into the trunk, there are no special
OLPC sources anymore.

- Bert -

> For your reference, when I build a 64-bit VM (for my personal use, I
> do not distribute it), I will get the sources directly from Subversion
> as follows:
> $ svn co http://squeakvm.org/svn/squeak/trunk squeak-svn-source
>
> I assume that you are building the VM using the sources found in
> the ./platforms/unix/src directory. It may not be obvious, but the
> files in this directory are actually intermediate files, the result
> of automatic code generation from the "real" sources, which are
> written in Smalltalk and maintained in the Squeak image (in a package
> called "VMMaker").
>
> This is important for building the VM on 64-bit Linux, because there
> are a number of updates in the Smalltalk VMMaker sources needed for
> a 64-bit that may not yet be reflected in the files that you find
> in your platforms/unix/src directory. Likewise, there are changes
> in the OLPC VMMaker sources that may not yet have been included in
> the generic VMMaker (and we want to sort that out of course).
>
> Let me know where you downloaded your sources from, and I'll try
> to reproduce the errors.
>
> Dave
>

David T. Lewis

Re: Compiling squeak-vm for Linux 64bit

On Sun, Mar 15, 2009 at 02:57:25PM +0100, Bert Freudenberg wrote:

>
> On 15.03.2009, at 14:54, David T. Lewis wrote:
> >
> >Pat, can you clarify where you obtained the source code for version
> >3.10-4? I am assuming that you are using sources that contain support
> >for OLPC, but I'm not sure if you are getting them directly from the
> >Subversion repository or from some other site. I want to try to
> >reproduce
> >the problem on my PC if possible.
>
> I told Pat to use the official sources, so this should be the tarball
> from
>
> http://squeakvm.org/unix/
>

Thanks, I'll give that a try.

Dave

David T. Lewis

Re: Compiling squeak-vm for Linux 64bit

In reply to this post by Bert Freudenberg

On Sun, Mar 15, 2009 at 02:57:25PM +0100, Bert Freudenberg wrote:

I downloaded the tarball and built from the platforms/unix/src source
files. The attached log file (typescript.gz) shows what I did, and the
resulting output from configure and make.

There were no issues with the build (other than compiler warnings that
I expect from many of the plugins), and the resulting VM is functional.
That said, you don't want to try using sound sound (which crashes the VM)
or FFI (which needs the fixes on Mantis 7237).

Pat, can you please have a look at the attached typescript.gz file and
see if there is something different about the way you are doing the
build?

Clearly the sound support is going to need some work. This is actually
the first time I have loaded the sound libraries on my Linux laptop,
so I had not previously looked into this. There was some earlier
discussion about this on the list, although I don't recall if anything
was resolved.

Various other plugins that may be needed for EToys/OLPC are going to
need some work for 64-bit systems. But for what it's worth, the base
VM compiles and runs fine when built from the platforms/unix/src files
in the tarball.

Dave

typescript.gz (35K) Download Attachment

whaevr

Re: Compiling squeak-vm for Linux 64bit

Alright thanks guys for the suggestions, I re-did my pkgbuild. When I did an svn-checkout and was able to compile it just fine. I even used the same configure line as last time.

./unix/config/configure --prefix=/usr --without-quartz --with-x --enable-mpg-mmx

I also got my tarball from the link that Bert said in his email, I don't know why, but it just worked this time..

Waiting for it to re-compile now with my pkgbuild then I'll install it and try and run etoys again.

Sorry I haven't said anything for two days!

Pat

On Sun, Mar 15, 2009 at 8:30 PM, David T. Lewis <[hidden email]> wrote:

On Sun, Mar 15, 2009 at 02:57:25PM +0100, Bert Freudenberg wrote:
>
> On 15.03.2009, at 14:54, David T. Lewis wrote:
> >
> >Pat, can you clarify where you obtained the source code for version
> >3.10-4? I am assuming that you are using sources that contain support
> >for OLPC, but I'm not sure if you are getting them directly from the
> >Subversion repository or from some other site. I want to try to
> >reproduce
> >the problem on my PC if possible.
>
> I told Pat to use the official sources, so this should be the tarball
> from
>
> http://squeakvm.org/unix/
>
> We have merged the olpc branch into the trunk, there are no special
> OLPC sources anymore.

I downloaded the tarball and built from the platforms/unix/src source
files. The attached log file (typescript.gz) shows what I did, and the
resulting output from configure and make.

There were no issues with the build (other than compiler warnings that
I expect from many of the plugins), and the resulting VM is functional.
That said, you don't want to try using sound sound (which crashes the VM)
or FFI (which needs the fixes on Mantis 7237).

Pat, can you please have a look at the attached typescript.gz file and
see if there is something different about the way you are doing the
build?

Clearly the sound support is going to need some work. This is actually
the first time I have loaded the sound libraries on my Linux laptop,
so I had not previously looked into this. There was some earlier
discussion about this on the list, although I don't recall if anything
was resolved.

Various other plugins that may be needed for EToys/OLPC are going to
need some work for 64-bit systems. But for what it's worth, the base
VM compiles and runs fine when built from the platforms/unix/src files
in the tarball.

Dave

whaevr

Re: Compiling squeak-vm for Linux 64bit

Sucess!

Screenshot:

http://img90.imageshack.us/img90/5656/81857129.png

Didn't have to change my pkgbuild for etoys or anything. I do have the pkgbuild for squeak-vm to checkout of svn for a source. I don't know why it didn't work before with the tarball. I'll brush these pkgbuilds up to standard and ship them off to be included in the aur asap!

Thanks guys!

Pat

On Mon, Mar 16, 2009 at 5:54 PM, whaevr <[hidden email]> wrote:

Alright thanks guys for the suggestions, I re-did my pkgbuild. When I did an svn-checkout and was able to compile it just fine. I even used the same configure line as last time.
./unix/config/configure --prefix=/usr --without-quartz --with-x --enable-mpg-mmx

I also got my tarball from the link that Bert said in his email, I don't know why, but it just worked this time..
Waiting for it to re-compile now with my pkgbuild then I'll install it and try and run etoys again.

Sorry I haven't said anything for two days!
Pat

On Sun, Mar 15, 2009 at 8:30 PM, David T. Lewis <[hidden email]> wrote:

On Sun, Mar 15, 2009 at 02:57:25PM +0100, Bert Freudenberg wrote:
>
> On 15.03.2009, at 14:54, David T. Lewis wrote:
> >
> >Pat, can you clarify where you obtained the source code for version
> >3.10-4? I am assuming that you are using sources that contain support
> >for OLPC, but I'm not sure if you are getting them directly from the
> >Subversion repository or from some other site. I want to try to
> >reproduce
> >the problem on my PC if possible.
>
> I told Pat to use the official sources, so this should be the tarball
> from
>
> http://squeakvm.org/unix/
>
> We have merged the olpc branch into the trunk, there are no special
> OLPC sources anymore.

I downloaded the tarball and built from the platforms/unix/src source
files. The attached log file (typescript.gz) shows what I did, and the
resulting output from configure and make.

There were no issues with the build (other than compiler warnings that
I expect from many of the plugins), and the resulting VM is functional.
That said, you don't want to try using sound sound (which crashes the VM)
or FFI (which needs the fixes on Mantis 7237).

Pat, can you please have a look at the attached typescript.gz file and
see if there is something different about the way you are doing the
build?

Clearly the sound support is going to need some work. This is actually
the first time I have loaded the sound libraries on my Linux laptop,
so I had not previously looked into this. There was some earlier
discussion about this on the list, although I don't recall if anything
was resolved.

Various other plugins that may be needed for EToys/OLPC are going to
need some work for 64-bit systems. But for what it's worth, the base
VM compiles and runs fine when built from the platforms/unix/src files
in the tarball.

Dave

Bert Freudenberg

Re: Compiling squeak-vm for Linux 64bit

On 16.03.2009, at 23:04, whaevr wrote:

> Sucess!
>
> Screenshot:
>
> http://img90.imageshack.us/img90/5656/81857129.png
>

Great :)

> Didn't have to change my pkgbuild for etoys or anything. I do have
> the pkgbuild for squeak-vm to checkout of svn for a source. I don't
> know why it didn't work before with the tarball. I'll brush these
> pkgbuilds up to standard and ship them off to be included in the aur
> asap!

If the release tarball works, that would be much more reliable than
the svn trunk, which might break at times.

- Bert -

whaevr

Re: Compiling squeak-vm for Linux 64bit

I just tried compiling with the realease tarball again, and it actually compiled this time. I was using part of a pkgbuild from the former maintainer, this time I used all mine. It did build this time but when I ran "etoys" I get this error.

Segmentation fault

18222984 Cursor>beCursor
18223168 [] in Cursor class>currentCursor:
18222892 BlockContext>on:do:
18222156 Cursor class>currentCursor:
18221972 InputSensor>currentCursor:
18221880 Cursor>show
17376136 SmalltalkImage>snapshot:andQuit:embedded:
17376044 SmalltalkImage>snapshot:andQuit:
17375696 [] in UndefinedObject>?
14031856 WorldState>runStepMethodsIn:
14031764 PasteUpMorph>runStepMethods
14013036 WorldState>doOneCycleNowFor:
14012944 WorldState>doOneCycleFor:
14012852 PasteUpMorph>doOneCycle
14007696 [] in Project class>spawnNewProcess
14007880 [] in BlockContext>newProcess

So whatever is causing this is fixed in the svn version..

Pat

On Mon, Mar 16, 2009 at 6:13 PM, Bert Freudenberg <[hidden email]> wrote:

On 16.03.2009, at 23:04, whaevr wrote:

Sucess!

Screenshot:

http://img90.imageshack.us/img90/5656/81857129.png

Great :)

Didn't have to change my pkgbuild for etoys or anything. I do have the pkgbuild for squeak-vm to checkout of svn for a source. I don't know why it didn't work before with the tarball. I'll brush these pkgbuilds up to standard and ship them off to be included in the aur asap!

If the release tarball works, that would be much more reliable than the svn trunk, which might break at times.

- Bert -

David T. Lewis

Re: Compiling squeak-vm for Linux 64bit

In reply to this post by whaevr

On Mon, Mar 16, 2009 at 06:04:59PM -0400, whaevr wrote:
>
> Sucess!
>
> Screenshot:
>
> http://img90.imageshack.us/img90/5656/81857129.png

Nice!

> Didn't have to change my pkgbuild for etoys or anything. I do have the
> pkgbuild for squeak-vm to checkout of svn for a source. I don't know why it
> didn't work before with the tarball. I'll brush these pkgbuilds up to
> standard and ship them off to be included in the aur asap!

Excellent, good progress. A word of caution though: Be careful not
to set the expectation that this is a solid VM. It compiles and runs,
but I can guarantee 100% that there will be problems at runtime,
including crashing the VM when certain functions are exercised. This
is just a matter of working though the type declarations in some VM
plugins (and the sound functions apparently), but we are not there
yet for 64-bit platforms and EToys users are not going to be happy
if the VM crashes in the middle of their creative work ;)

Dave

whaevr

Re: Compiling squeak-vm for Linux 64bit

Alright then, I'll hold off on sending the pkgbuilds then. I haven't sent them yet, I've been trying to figure out if its possible to do a selective svn checkout. I don't need to checkout the the windows and mac versions.

Suppose I should wait then for the next stable squeak release?

Pat

On Mon, Mar 16, 2009 at 7:27 PM, David T. Lewis <[hidden email]> wrote:

On Mon, Mar 16, 2009 at 06:04:59PM -0400, whaevr wrote:
>
> Sucess!
>
> Screenshot:
>
> http://img90.imageshack.us/img90/5656/81857129.png

Nice!

> Didn't have to change my pkgbuild for etoys or anything. I do have the
> pkgbuild for squeak-vm to checkout of svn for a source. I don't know why it
> didn't work before with the tarball. I'll brush these pkgbuilds up to
> standard and ship them off to be included in the aur asap!

Excellent, good progress. A word of caution though: Be careful not
to set the expectation that this is a solid VM. It compiles and runs,
but I can guarantee 100% that there will be problems at runtime,
including crashing the VM when certain functions are exercised. This
is just a matter of working though the type declarations in some VM
plugins (and the sound functions apparently), but we are not there
yet for 64-bit platforms and EToys users are not going to be happy
if the VM crashes in the middle of their creative work ;)

Dave

David T. Lewis

Re: Compiling squeak-vm for Linux 64bit

On Mon, Mar 16, 2009 at 07:36:22PM -0400, whaevr wrote:

> On Mon, Mar 16, 2009 at 7:27 PM, David T. Lewis <[hidden email]> wrote:
> > On Mon, Mar 16, 2009 at 06:04:59PM -0400, whaevr wrote:
> > >
> > > Sucess!
> > >
> > > Screenshot:
> > >
> > > http://img90.imageshack.us/img90/5656/81857129.png
> >
> > Nice!
> >
> > > Didn't have to change my pkgbuild for etoys or anything. I do have the
> > > pkgbuild for squeak-vm to checkout of svn for a source. I don't know why
> > it
> > > didn't work before with the tarball. I'll brush these pkgbuilds up to
> > > standard and ship them off to be included in the aur asap!
> >
> > Excellent, good progress. A word of caution though: Be careful not
> > to set the expectation that this is a solid VM. It compiles and runs,
> > but I can guarantee 100% that there will be problems at runtime,
> > including crashing the VM when certain functions are exercised. This
> > is just a matter of working though the type declarations in some VM
> > plugins (and the sound functions apparently), but we are not there
> > yet for 64-bit platforms and EToys users are not going to be happy
> > if the VM crashes in the middle of their creative work ;)
>
> Alright then, I'll hold off on sending the pkgbuilds then. I haven't sent
> them yet, I've been trying to figure out if its possible to do a selective
> svn checkout. I don't need to checkout the the windows and mac versions.

Bert, help me out on this. Who is the target audience? It's great if
this get released to folks on an experimental basis, but it would be
a mistake to provide it to EToys users who expect a stable and reliable
system.

> Suppose I should wait then for the next stable squeak release?
>

I'm not sure what the timing would be on this. The stable, supported
Squeak VMs are currently targeted at 32-bit platforms, and for the
most part people using 64-bit platforms are probably building their
own. My hunch is that most users of 64-bit VMs are either hobbyists
like me, or people running servers (such as Seaside web applications)
where the various multimedia plugins are not important. For EToys,
the multimedia functions should work without problems, so that is
why I am saying to be cautious.

Dave

José "L. Redrejo" Rodríguez

Re: Compiling squeak-vm for Linux 64bit

El lun, 16-03-2009 a las 19:57 -0400, David T. Lewis escribió:

> On Mon, Mar 16, 2009 at 07:36:22PM -0400, whaevr wrote:
> > On Mon, Mar 16, 2009 at 7:27 PM, David T. Lewis <[hidden email]> wrote:
> > > On Mon, Mar 16, 2009 at 06:04:59PM -0400, whaevr wrote:
> > > >
> > > > Sucess!
> > > >
> > > > Screenshot:
> > > >
> > > > http://img90.imageshack.us/img90/5656/81857129.png
> > >
> > > Nice!
> > >
> > > > Didn't have to change my pkgbuild for etoys or anything. I do have the
> > > > pkgbuild for squeak-vm to checkout of svn for a source. I don't know why
> > > it
> > > > didn't work before with the tarball. I'll brush these pkgbuilds up to
> > > > standard and ship them off to be included in the aur asap!
> > >
> > > Excellent, good progress. A word of caution though: Be careful not
> > > to set the expectation that this is a solid VM. It compiles and runs,
> > > but I can guarantee 100% that there will be problems at runtime,
> > > including crashing the VM when certain functions are exercised. This
> > > is just a matter of working though the type declarations in some VM
> > > plugins (and the sound functions apparently), but we are not there
> > > yet for 64-bit platforms and EToys users are not going to be happy
> > > if the VM crashes in the middle of their creative work ;)
> >
> > Alright then, I'll hold off on sending the pkgbuilds then. I haven't sent
> > them yet, I've been trying to figure out if its possible to do a selective
> > svn checkout. I don't need to checkout the the windows and mac versions.
>
> Bert, help me out on this. Who is the target audience? It's great if
> this get released to folks on an experimental basis, but it would be
> a mistake to provide it to EToys users who expect a stable and reliable
> system.
>
> > Suppose I should wait then for the next stable squeak release?
> >
>
> I'm not sure what the timing would be on this. The stable, supported
> Squeak VMs are currently targeted at 32-bit platforms, and for the
> most part people using 64-bit platforms are probably building their
> own. My hunch is that most users of 64-bit VMs are either hobbyists
> like me, or people running servers (such as Seaside web applications)
> where the various multimedia plugins are not important. For EToys,
> the multimedia functions should work without problems, so that is
> why I am saying to be cautious.
>

I can not agree. I'm using the ltsp project in the secondary schools of
my region: there is a ltsp server with 8 Gb of RAM in every classroom
with 15-30 thin clients. These servers use amd64, betweeen some other
non so obvious reasons, to be able to use correctly the 8 Gb of ram, and
I have to use i386 emulation to be able to poorly run Squeak because the
vm breaks whenever they want to use sound, the plugin (in fact the
plugin doesn't work in i386b either), pango, gstreamer, etc. I'm
speaking of 3.200 servers plus 60.000 clients. And the users are
teachers and students, not hobbyists who can compile a vm by
themselves... Also, the squeak-vm is in the Debian repository, compiled
for non-i386 architectures used in the sugar project and, obviously,
with the same bugs.
And many other places using Debian Edu now know of Squeak and, whenever
they want to use a good ltsp server for the classes, they can not use
Squeak. So, from my point of view, at least fixing sound and pango is
urgent in 64 bits VMs, as both things are used by default in the etoys
image. Fixing the browser plugin should be done also for all the archs,
obviously.

Regards.
José L.

signature.asc (204 bytes) Download Attachment

Andreas.Raab

Re: Compiling squeak-vm for Linux 64bit

José L. Redrejo Rodríguez wrote:
> And many other places using Debian Edu now know of Squeak and, whenever
> they want to use a good ltsp server for the classes, they can not use
> Squeak. So, from my point of view, at least fixing sound and pango is
> urgent in 64 bits VMs, as both things are used by default in the etoys
> image. Fixing the browser plugin should be done also for all the archs,
> obviously.

The difficulty is that we're all busy doing other things and very little
time and effort is being put into the 64bit port. It's also a bit
surprising for me to find out that you're looking at deploying on that
scale without having at least one dedicated VM person. I have found that
for really shipping Squeak you do need a VM person - if only to make
sure you have the right icon, the right fixes, the right plugins and
whatever else might go into your particular deployment. It doesn't have
to be Eliot (though that wouldn't hurt ;-) but someone needs to be on
top of these issues. In which case that is the person who should look at
fixing these problems in your context and, after fixing them for your
application, how we can integrate this into the VM proper.

Cheers,
- Andreas

Bert Freudenberg

Re: Compiling squeak-vm for Linux 64bit

In reply to this post by José "L. Redrejo" Rodríguez

On 17.03.2009, at 08:37, José L. Redrejo Rodríguez wrote:

> El lun, 16-03-2009 a las 19:57 -0400, David T. Lewis escribió:
>> On Mon, Mar 16, 2009 at 07:36:22PM -0400, whaevr wrote:
>>> On Mon, Mar 16, 2009 at 7:27 PM, David T. Lewis
>>> <[hidden email]> wrote:
>>>> Excellent, good progress. A word of caution though: Be careful not
>>>> to set the expectation that this is a solid VM. It compiles and
>>>> runs,
>>>> but I can guarantee 100% that there will be problems at runtime,
>>>> including crashing the VM when certain functions are exercised.
>>>> This
>>>> is just a matter of working though the type declarations in some VM
>>>> plugins (and the sound functions apparently), but we are not there
>>>> yet for 64-bit platforms and EToys users are not going to be happy
>>>> if the VM crashes in the middle of their creative work ;)
>>>
>>> Alright then, I'll hold off on sending the pkgbuilds then. I
>>> haven't sent
>>> them yet, I've been trying to figure out if its possible to do a
>>> selective
>>> svn checkout. I don't need to checkout the the windows and mac
>>> versions.
>>
>> Bert, help me out on this. Who is the target audience? It's great if
>> this get released to folks on an experimental basis, but it would be
>> a mistake to provide it to EToys users who expect a stable and
>> reliable
>> system.

Etoys and the Squeak VM is getting packaged into many more Linux
distributions recently. José pioneered this last year with his
packaging for Debian. It went into Fedora a few weeks ago and
yesterday Mandriva. It's not even that we (Etoys devs) are pushing
this, but it is a natural outcome of us trying to work with the larger
open source community. In fact we don't even know of all packaging
efforts - such as Pat's attempt to make it work in 64 bit archlinux.

A big surge is coming from Etoys being distributed as part of the
Sugar platform (the UI originally developed for the OLPC XO-1 kids
laptop). SugarLabs just released version 0.84.0 with big fanfare and
so I expect many more packagers to try and making Etoys work on their
favorite system, for which the Squeak VM is a dependency.

>>> Suppose I should wait then for the next stable squeak release?
>>
>> I'm not sure what the timing would be on this. The stable, supported
>> Squeak VMs are currently targeted at 32-bit platforms, and for the
>> most part people using 64-bit platforms are probably building their
>> own. My hunch is that most users of 64-bit VMs are either hobbyists
>> like me, or people running servers (such as Seaside web applications)
>> where the various multimedia plugins are not important. For EToys,
>> the multimedia functions should work without problems, so that is
>> why I am saying to be cautious.
>
>
> I can not agree. I'm using the ltsp project in the secondary schools
> of
> my region: there is a ltsp server with 8 Gb of RAM in every classroom
> with 15-30 thin clients. These servers use amd64, betweeen some other
> non so obvious reasons, to be able to use correctly the 8 Gb of ram,
> and
> I have to use i386 emulation to be able to poorly run Squeak because
> the
> vm breaks whenever they want to use sound, the plugin (in fact the
> plugin doesn't work in i386b either), pango, gstreamer, etc. I'm
> speaking of 3.200 servers plus 60.000 clients. And the users are
> teachers and students, not hobbyists who can compile a vm by
> themselves... Also, the squeak-vm is in the Debian repository,
> compiled
> for non-i386 architectures used in the sugar project and, obviously,
> with the same bugs.
> And many other places using Debian Edu now know of Squeak and,
> whenever
> they want to use a good ltsp server for the classes, they can not use
> Squeak. So, from my point of view, at least fixing sound and pango is
> urgent in 64 bits VMs, as both things are used by default in the etoys
> image. Fixing the browser plugin should be done also for all the
> archs,
> obviously.
>
> Regards.
> José L.

That is interesting news. I was not aware anybody is seriously wanting
to use Etoys on 64 bits. Besides, I though that amd64 is capable of
running 64 and 32 bit software side-by-side just fine so there is no
urgent need to clean up the VM (although I'm of course thankful to
David who is hacking away on this). As far as I know it's not
"emulation" at all, so why do you say it runs "poorly"?

- Bert -

José "L. Redrejo" Rodríguez

Re: Compiling squeak-vm for Linux 64bit

In reply to this post by Andreas.Raab

El mar, 17-03-2009 a las 00:48 -0700, Andreas Raab escribió:

> José L. Redrejo Rodríguez wrote:
> > And many other places using Debian Edu now know of Squeak and, whenever
> > they want to use a good ltsp server for the classes, they can not use
> > Squeak. So, from my point of view, at least fixing sound and pango is
> > urgent in 64 bits VMs, as both things are used by default in the etoys
> > image. Fixing the browser plugin should be done also for all the archs,
> > obviously.
>
> The difficulty is that we're all busy doing other things and very little
> time and effort is being put into the 64bit port. It's also a bit
> surprising for me to find out that you're looking at deploying on that
> scale without having at least one dedicated VM person. I have found that
> for really shipping Squeak you do need a VM person - if only to make
> sure you have the right icon, the right fixes, the right plugins and
> whatever else might go into your particular deployment. It doesn't have
> to be Eliot (though that wouldn't hurt ;-) but someone needs to be on
> top of these issues. In which case that is the person who should look at
> fixing these problems in your context and, after fixing them for your
> application, how we can integrate this into the VM proper.
>
> Cheers,
> - Andreas

I just needed to use 64 bits for my systems, and want the teachers to go
on using Squeak. It's not a planned used of 64 bits for Squeak, it's
just a need. As it doesn't work I've ended using a chroot 32 bits
environment to start it in 32 bits.
Anyway, the plugin doesn't work correctly in 32 bits either, so not all
the problems are related to the architecture.
Maybe you can remember that the human resources we have are very limited
to do too many things. Only the deployment of a large scale of this
project waste most of our efforts, so we can not have the privilege of
keeping somebody to maintain single applications. For most applications
we depend on the community that's behind. Our work is more focused in
the architecture of the system and our developments are restricted to
the applications oriented to make life with computers easier for
teachers and students. If firefox, openoffice, or squeak have a problem
we can take a look, try to workaround the problem and fixing it if the
bug doesn't need too much time, but with two or three Eliots there is
not much more that can be done (appart from contacting with the
community to tell them there're problems)

Cheers.
José L.

signature.asc (204 bytes) Download Attachment

José "L. Redrejo" Rodríguez

Re: Compiling squeak-vm for Linux 64bit

In reply to this post by Bert Freudenberg

El mar, 17-03-2009 a las 10:32 +0100, Bert Freudenberg escribió:

> On 17.03.2009, at 08:37, José L. Redrejo Rodríguez wrote:
>
> > El lun, 16-03-2009 a las 19:57 -0400, David T. Lewis escribió:
> >> On Mon, Mar 16, 2009 at 07:36:22PM -0400, whaevr wrote:
> >>> On Mon, Mar 16, 2009 at 7:27 PM, David T. Lewis
> >>> <[hidden email]> wrote:
> >>>> Excellent, good progress. A word of caution though: Be careful not
> >>>> to set the expectation that this is a solid VM. It compiles and
> >>>> runs,
> >>>> but I can guarantee 100% that there will be problems at runtime,
> >>>> including crashing the VM when certain functions are exercised.
> >>>> This
> >>>> is just a matter of working though the type declarations in some VM
> >>>> plugins (and the sound functions apparently), but we are not there
> >>>> yet for 64-bit platforms and EToys users are not going to be happy
> >>>> if the VM crashes in the middle of their creative work ;)
> >>>
> >>> Alright then, I'll hold off on sending the pkgbuilds then. I
> >>> haven't sent
> >>> them yet, I've been trying to figure out if its possible to do a
> >>> selective
> >>> svn checkout. I don't need to checkout the the windows and mac
> >>> versions.
> >>
> >> Bert, help me out on this. Who is the target audience? It's great if
> >> this get released to folks on an experimental basis, but it would be
> >> a mistake to provide it to EToys users who expect a stable and
> >> reliable
> >> system.
>
> Etoys and the Squeak VM is getting packaged into many more Linux
> distributions recently. José pioneered this last year with his
> packaging for Debian. It went into Fedora a few weeks ago and
> yesterday Mandriva. It's not even that we (Etoys devs) are pushing
> this, but it is a natural outcome of us trying to work with the larger
> open source community. In fact we don't even know of all packaging
> efforts - such as Pat's attempt to make it work in 64 bit archlinux.
>
> A big surge is coming from Etoys being distributed as part of the
> Sugar platform (the UI originally developed for the OLPC XO-1 kids
> laptop). SugarLabs just released version 0.84.0 with big fanfare and
> so I expect many more packagers to try and making Etoys work on their
> favorite system, for which the Squeak VM is a dependency.
>
> >>> Suppose I should wait then for the next stable squeak release?
> >>
> >> I'm not sure what the timing would be on this. The stable, supported
> >> Squeak VMs are currently targeted at 32-bit platforms, and for the
> >> most part people using 64-bit platforms are probably building their
> >> own. My hunch is that most users of 64-bit VMs are either hobbyists
> >> like me, or people running servers (such as Seaside web applications)
> >> where the various multimedia plugins are not important. For EToys,
> >> the multimedia functions should work without problems, so that is
> >> why I am saying to be cautious.
> >
> >
> > I can not agree. I'm using the ltsp project in the secondary schools
> > of
> > my region: there is a ltsp server with 8 Gb of RAM in every classroom
> > with 15-30 thin clients. These servers use amd64, betweeen some other
> > non so obvious reasons, to be able to use correctly the 8 Gb of ram,
> > and
> > I have to use i386 emulation to be able to poorly run Squeak because
> > the
> > vm breaks whenever they want to use sound, the plugin (in fact the
> > plugin doesn't work in i386b either), pango, gstreamer, etc. I'm
> > speaking of 3.200 servers plus 60.000 clients. And the users are
> > teachers and students, not hobbyists who can compile a vm by
> > themselves... Also, the squeak-vm is in the Debian repository,
> > compiled
> > for non-i386 architectures used in the sugar project and, obviously,
> > with the same bugs.
> > And many other places using Debian Edu now know of Squeak and,
> > whenever
> > they want to use a good ltsp server for the classes, they can not use
> > Squeak. So, from my point of view, at least fixing sound and pango is
> > urgent in 64 bits VMs, as both things are used by default in the etoys
> > image. Fixing the browser plugin should be done also for all the
> > archs,
> > obviously.
> >
> > Regards.
> > José L.
>
> That is interesting news. I was not aware anybody is seriously wanting
> to use Etoys on 64 bits. Besides, I though that amd64 is capable of
> running 64 and 32 bit software side-by-side just fine so there is no
> urgent need to clean up the VM (although I'm of course thankful to
> David who is hacking away on this). As far as I know it's not
> "emulation" at all, so why do you say it runs "poorly"?

Not, it's not emulation, and running 32 bits applications in a 64 bits

environment works, it's what I'm doing, but the perfomance is worse, and
the integration with the user desktop with all the applications (and the
desktop itself) running in 64 bits has aesthetical issues. And you know,
for end users, the way an application looks uses to be important.

So, for my end users, I've workarounded most of the problems (appart
from the browser plugin that segfaults in 32 bits whenever you close the
tab where it's running), but the problems are still there, and everyday
there are more people trying to use amd64 and don't want (or don't know)
to hack the applications to make them work. And there are some projects
(as the sugar project in Debian, or Debian Edu) that want to use Squeak
and are stalled because of the 64 bits issues. I don't know if that's
urgent for the Squeak community, but it's something that has to be known
to decide if it is important or not. That's why I begun my intervention
in this thread answering to David that the 64-bits are needed not only
for hobbyists, but for many more people.

Cheers
José L.

signature.asc (204 bytes) Download Attachment

Bert Freudenberg

Re: Compiling squeak-vm for Linux 64bit

On 17.03.2009, at 11:28, José L. Redrejo Rodríguez wrote:

> El mar, 17-03-2009 a las 10:32 +0100, Bert Freudenberg escribió:
>>
>> That is interesting news. I was not aware anybody is seriously
>> wanting
>> to use Etoys on 64 bits. Besides, I though that amd64 is capable of
>> running 64 and 32 bit software side-by-side just fine so there is no
>> urgent need to clean up the VM (although I'm of course thankful to
>> David who is hacking away on this). As far as I know it's not
>> "emulation" at all, so why do you say it runs "poorly"?
> Not, it's not emulation, and running 32 bits applications in a 64 bits
> environment works, it's what I'm doing, but the perfomance is worse,

Really? How did you measure that?

> and
> the integration with the user desktop with all the applications (and
> the
> desktop itself) running in 64 bits has aesthetical issues. And you
> know,
> for end users, the way an application looks uses to be important.

Huh? How does Etoys in 64 bits look different from 32 bits?

> So, for my end users, I've workarounded most of the problems (appart
> from the browser plugin that segfaults in 32 bits whenever you close
> the
> tab where it's running), but the problems are still there,

Yes, I have not worked on the plugin in a while. Sorry. The plugin is
not used in Sugar, so I did not pay much attention to it. When I find
some spare time I will look into it. Patches welcome of course, as
well as links to detailed bug reports.

> and everyday
> there are more people trying to use amd64 and don't want (or don't
> know)
> to hack the applications to make them work. And there are some
> projects
> (as the sugar project in Debian, or Debian Edu) that want to use
> Squeak
> and are stalled because of the 64 bits issues.

Seriously, that's the first time I hear that 64 bits issues are
stalling anything related to Etoys.

> I don't know if that's
> urgent for the Squeak community, but it's something that has to be
> known
> to decide if it is important or not. That's why I begun my
> intervention
> in this thread answering to David that the 64-bits are needed not only
> for hobbyists, but for many more people.

Well, thanks for speaking up. You have to distinguish between the
squeak.org community and the Etoys community. Both talk about "Squeak"
but mean entirely different things. Most in the squeak.org community
do not think of Squeak as a product with users, but rather as a tool
they only use themselves. E.g., there is even resistance to creating a
squeak-users mailing list aimed at Smalltalk developers who just want
to use Squeak for developing :/

This is different for the Etoys community. They see "Squeak Etoys" is
an educational tool that is used by teachers, parents, and children.
The new "Squeakland Foundation" was created to support that community.
They will have an open ear to your concerns.

The VM guys here basically churn away on keeping up the illusion that
Squeak simply works ;)

- Bert -

Göran Krampe

Re: Compiling squeak-vm for Linux 64bit

Hi!

Really wrong forum, but what the heck.

Bert Freudenberg wrote:
> Most in the squeak.org community do
> not think of Squeak as a product with users, but rather as a tool they
> only use themselves. E.g., there is even resistance to creating a
> squeak-users mailing list aimed at Smalltalk developers who just want to
> use Squeak for developing :/

Interesting. I wonder if I am one of those "resisting". When I heard the
idea of creating a squeak-users list I first thought that, no, Squeak is
not polished enough to be just "used" as a multimedia environment.

Because I didn't think of "using" to possibly could have meant "using
for development"! Yeah, call me daft.

Another reason is probably that I don't understand why anyone would only
want to "use" Squeak without any interest in how it is being moved
forward nor how it works inside. When you develop in Squeak you
typically invest in its future, so why on earth would you not be
considering yourself a member of the "squeak-dev" community?

Anyway, for other "development tools" I can see myself more clearly as a
"user" - but a Smalltalk environment is so intertwined with itself that
I don't see that separation. I also do not like squeak-dev turning into
some kind of "club for the mighty developers". Which is why I was
hesitant about the beginners list too - although I probably was wrong there.

[SNIP]
> They will have an open ear to your concerns.

I do think Squeakers in general have a very "open ear" - it is not ears
we lack, it is time to spend in solving problems that someone else has
that we lack. :) At least most of us lack it.

> The VM guys here basically churn away on keeping up the illusion that
> Squeak simply works ;)
>
> - Bert -

regards, Göran

José "L. Redrejo" Rodríguez

Re: Compiling squeak-vm for Linux 64bit

In reply to this post by Bert Freudenberg

El mar, 17-03-2009 a las 12:45 +0100, Bert Freudenberg escribió:

> On 17.03.2009, at 11:28, José L. Redrejo Rodríguez wrote:
>
> > El mar, 17-03-2009 a las 10:32 +0100, Bert Freudenberg escribió:
> >>
> >> That is interesting news. I was not aware anybody is seriously
> >> wanting
> >> to use Etoys on 64 bits. Besides, I though that amd64 is capable of
> >> running 64 and 32 bit software side-by-side just fine so there is no
> >> urgent need to clean up the VM (although I'm of course thankful to
> >> David who is hacking away on this). As far as I know it's not
> >> "emulation" at all, so why do you say it runs "poorly"?
> > Not, it's not emulation, and running 32 bits applications in a 64 bits
> > environment works, it's what I'm doing, but the perfomance is worse,
>
> Really? How did you measure that?

It's a total subjetive impression: big projects take more time to load
in this environment, than in a pure 32 bits environment.

>
> > and
> > the integration with the user desktop with all the applications (and
> > the
> > desktop itself) running in 64 bits has aesthetical issues. And you
> > know,
> > for end users, the way an application looks uses to be important.
>
> Huh? How does Etoys in 64 bits look different from 32 bits?
>

Obviously, it's not Etoys , but the windows that contains etoys (i.e.:
gtk or qt theme, etc.)

> > So, for my end users, I've workarounded most of the problems (appart
> > from the browser plugin that segfaults in 32 bits whenever you close
> > the
> > tab where it's running), but the problems are still there,
>
> Yes, I have not worked on the plugin in a while. Sorry. The plugin is
> not used in Sugar, so I did not pay much attention to it. When I find
> some spare time I will look into it. Patches welcome of course, as
> well as links to detailed bug reports.

I'll fill a bug in mantis, but in brief, the test is pretty easy: use
firefox, open a new tab and load a squeak project. Then try to close
that tab, and firefox segfaults. The same if you just clic on the back
button of the browser.

>
> > and everyday
> > there are more people trying to use amd64 and don't want (or don't
> > know)
> > to hack the applications to make them work. And there are some
> > projects
> > (as the sugar project in Debian, or Debian Edu) that want to use
> > Squeak
> > and are stalled because of the 64 bits issues.
>
> Seriously, that's the first time I hear that 64 bits issues are
> stalling anything related to Etoys.
>

64 bits issues are stalling the use of etoys in Debian, and inside
Debian it's doing it in the sugar project (it's not the only problem,
bootstrapping of the image and license are a problem, as we both know
well)

> > I don't know if that's
> > urgent for the Squeak community, but it's something that has to be
> > known
> > to decide if it is important or not. That's why I begun my
> > intervention
> > in this thread answering to David that the 64-bits are needed not only
> > for hobbyists, but for many more people.
>
>
> Well, thanks for speaking up. You have to distinguish between the
> squeak.org community and the Etoys community. Both talk about "Squeak"
> but mean entirely different things. Most in the squeak.org community
> do not think of Squeak as a product with users, but rather as a tool
> they only use themselves. E.g., there is even resistance to creating a
> squeak-users mailing list aimed at Smalltalk developers who just want
> to use Squeak for developing :/
>
> This is different for the Etoys community. They see "Squeak Etoys" is
> an educational tool that is used by teachers, parents, and children.
> The new "Squeakland Foundation" was created to support that community.
> They will have an open ear to your concerns.
>
> The VM guys here basically churn away on keeping up the illusion that
> Squeak simply works ;)
>

I know, I know. For those who don't know it, my concerns are related
only to the use of Squeak in education. Some years ago, there was no
difference between Squeak and eToys, today, it mainly means eToys, but
eToys need the vm to work...

signature.asc (204 bytes) Download Attachment