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.
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
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
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
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
Thanks, I'll give that a try.
Dave
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
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
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 lewis@mail.msen.com 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
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 whaevr@archlinux.us 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 lewis@mail.msen.comwrote:
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
On 16.03.2009, at 23:04, whaevr wrote:
Sucess!
Screenshot:
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 -
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 bert@freudenbergs.dewrote:
On 16.03.2009, at 23:04, whaevr wrote:
Sucess!
Screenshot:
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 -
On 16.03.2009, at 23:26, whaevr wrote:
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..
Ah, right, that was fixed only 3 weeks ago, and there was no point release since.
- Bert -
On Mon, Mar 16, 2009 at 06:04:59PM -0400, whaevr wrote:
Sucess!
Screenshot:
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
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 lewis@mail.msen.com wrote:
On Mon, Mar 16, 2009 at 06:04:59PM -0400, whaevr wrote:
Sucess!
Screenshot:
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
On Mon, Mar 16, 2009 at 07:36:22PM -0400, whaevr wrote:
On Mon, Mar 16, 2009 at 7:27 PM, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Mar 16, 2009 at 06:04:59PM -0400, whaevr wrote:
Sucess!
Screenshot:
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
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 lewis@mail.msen.com wrote:
On Mon, Mar 16, 2009 at 06:04:59PM -0400, whaevr wrote:
Sucess!
Screenshot:
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.
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
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.
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 lewis@mail.msen.com 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 -
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 lewis@mail.msen.com 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.
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 -
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
On 17.03.2009, at 13:36, Göran Krampe wrote:
Hi!
Really wrong forum, but what the heck.
Wrong indeed. Reply-to set to squeak-dev.
For those coming late: the original thread starts to get interesting around here: http://lists.squeakfoundation.org/pipermail/vm-dev/2009-March/002427.html
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.
Hehe. Well, at least I am trying to always distinguish between "Etoys" and "Squeak". This was not always necessary, and in particular the education community refers to Etoys as Squeak out of habit. But around here "Squeak" means Smalltalk development.
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?
Good question. But when you develop in, say, Python, don't you "invest in its future"? Still, most Python users would not contribute to Python directly, right? But indirectly they do.
In my opinion broadening the user base of Squeak would have long-term benefits. Yes you may get more annoying questions, but that's what the proposed users list would be for (initially anyway - there might even be more books if there was a real market). With more Squeak users there also would be more who jump the fence and become Squeak developers. Which would cover your next point ...
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.
regards, Göran
... which is that each individual only has so much time. But if we had a larger community and made it really easy to contribute, we'd still move much faster.
- Bert -
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...
On 17.03.2009, at 13:38, José L. Redrejo Rodríguez wrote:
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.
I'd be interested in seeing benchmark numbers. If there is indeed a 32 bit emulation layer then this is possible (although I'd find it hard to imagine).
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.)
Oh. Now that's silly. So you mean a 32 bit application cannot open a window on a display that is running a 64 bit window manager? That cannot be, or you could not run 64 bit and 32 bit apps side by side.
The only reason I could see is that the window manager decorates the Etoys window differently from other windows. Does the window decoration really change when you use the 64 bit VM?
Or maybe the way you run Squeak confuses the window manager - how exactly do you do it?
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 am not aware of any more license issues. They still don't like the image concept, yes.
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...
Indeed :) It helps to call it "Etoys" on Squeak mailing lists because not everyone can remember who is actually using Etoys and who another Squeak version.
- Bert -
Someone might want to look into if the project read is using the multibyte streams in text mode. If so in my past experience with Sophie is that a read requires reading byte by byte, which actually ends up reading a byte by byte from the file system. Although this is *fast* (a relative term) because stdio caches data for reading, perhaps the 32 to 64 thunking between the C code and the 32/64 stdio is intensive.
For Sophie and other products we would suck the entire file into a read//write internal stream, then pass that to the multibyte stream reader.
For writing the pattern is even worse because the multi-byte logic in text mode writes one byte at a time. Write 5 mb and it's 5 million system calls and the overhead is quite large. For Sophie we built a caching output stream that would stream out to memory, then at close time flush the contents to the file stream.
PS you can see this on unix systems by looking at system calls (or the like).
On 17-Mar-09, at 5:38 AM, José L. Redrejo Rodríguez wrote:
It's a total subjetive impression: big projects take more time to load in this environment, than in a pure 32 bits environment.
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
On Tue, Mar 17, 2009 at 08:37:00AM +0100, 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.
Jos??,
Thank you for bringing this up. It's good to know that this is important, and as you can see, most of us on this list were not aware of the interest.
For my part, I will try to resolve the issues on 64-bit sound and pango when I get some free time. But this will not be until April because I will be away on vacation until then. And of course I am just a hobby hacker so don't expect too much right away ;)
Dave
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
David T. Lewis -
Göran Krampe -
John M McIntosh -
José L. Redrejo Rodríguez -
whaevr