Folks -
I'll show my complete ignorance here but can someone explain to me what the status of closure support in the Unix VMs is? Windows and Macs have binaries that people can just download; I don't think the Unix VM is usually shipped as binary, no?
In any case, what is the process that users have to go through to get a closure-enabled VM on their preferred Unix flavor?
Thanks, - Andreas
On Tue, Jul 14, 2009 at 03:56:40PM -0700, Andreas Raab wrote:
Folks -
I'll show my complete ignorance here but can someone explain to me what the status of closure support in the Unix VMs is? Windows and Macs have binaries that people can just download; I don't think the Unix VM is usually shipped as binary, no?
Ian has recently returned from holiday, and will be available to help with updates shortly. In the mean time, Bryce Kampjes has stepped forward to provide closure enabled VMs to support Pharo, etc (thanks!).
The only thing that is required for a closure enabled VM is to build the distribution using a recent VMMaker. There is no external support code required, so nothing unix specific.
In any case, what is the process that users have to go through to get a closure-enabled VM on their preferred Unix flavor?
Just build the VM with recent VMMaker and Subversion support code. That's it. Near term, use Bryce's Exupery VM with closure support. Real soon now, use whatever Ian next compiles.
There are a number of outstanding issues and updates that we should try to coordinate over the next couple of months, and I think it's on me to publish a suggested to-do list for this. But as far as the closure support, it's basically just a matter of compile it and go.
Dave
On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raabandreas.raab@gmx.de wrote:
In any case, what is the process that users have to go through to get a closure-enabled VM on their preferred Unix flavor?
Download the 'GNU/Linux and other Unix' VM from: http://pharo-project.org/pharo-download
I've also attached a README.
On Fri, Jul 17, 2009 at 01:23:55PM +0200, Damien Cassou wrote:
On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raabandreas.raab@gmx.de wrote:
In any case, what is the process that users have to go through to get a closure-enabled VM on their preferred Unix flavor?
Download the 'GNU/Linux and other Unix' VM from: http://pharo-project.org/pharo-download
I've also attached a README.
Damien,
Thanks for the link.
Andreas,
I repeated the test of loading closure support from your MCUpdateTest update stream, this time using the Pharo (Exupery) 32-bit Linux VM rather than my homebrew 64-bit VM. The results are the same, with the load stopping in the preamble to Compiler-ar.70.
So with respect to running the closure bytecode support, there is no evidence of a difference between the VM compiled for 32 bit pointers (Exupery build) versus a VM compiled for 64 bit pointers.
Dave
David T. Lewis wrote:
I repeated the test of loading closure support from your MCUpdateTest update stream, this time using the Pharo (Exupery) 32-bit Linux VM rather than my homebrew 64-bit VM. The results are the same, with the load stopping in the preamble to Compiler-ar.70.
Thanks David. If you have the time, can you do me a favor and attach gdb when it's in that state and see what printCallStack() gives us? Plus, if possible, a check whether the issue might be caused by something unrelated (i.e., one of the these negative address space wrap arounds; running out of disk space) would be useful. Lastly, any chance that you can send me a link to that particular image you're using? Perhaps there is just something strange with that image.
Cheers, - Andreas
On Fri, Jul 17, 2009 at 08:53:57AM -0700, Andreas Raab wrote:
David T. Lewis wrote:
I repeated the test of loading closure support from your MCUpdateTest update stream, this time using the Pharo (Exupery) 32-bit Linux VM rather than my homebrew 64-bit VM. The results are the same, with the load stopping in the preamble to Compiler-ar.70.
Thanks David. If you have the time, can you do me a favor and attach gdb when it's in that state and see what printCallStack() gives us? Plus, if possible, a check whether the issue might be caused by something unrelated (i.e., one of the these negative address space wrap arounds; running out of disk space) would be useful. Lastly, any chance that you can send me a link to that particular image you're using? Perhaps there is just something strange with that image.
To clarify: After the load process "gets hung up", apparently in the preamble of Compiler-ar.70, the image is fully responsive. Neither the image nor the VM is hung up, it's just that that load process has stopped and an MCMergeBrowser with title "Merging Compiler-ar-70" has opened.
Sorry, I don't have a way to post an image right now.
Dave
David T. Lewis wrote:
To clarify: After the load process "gets hung up", apparently in the preamble of Compiler-ar.70, the image is fully responsive. Neither the image nor the VM is hung up, it's just that that load process has stopped and an MCMergeBrowser with title "Merging Compiler-ar-70" has opened.
Oh! Well, if there are no conflicts, just hit the "merge" button and proceed. I'm not sure why it's doing this but there is a possibility that it just thought it needed to do a merge when there was really no reason to. (this is the expected behavior though if you've done local mods to packages)
Cheers, - Andres
On Fri, Jul 17, 2009 at 10:01:39AM -0700, Andreas Raab wrote:
David T. Lewis wrote:
To clarify: After the load process "gets hung up", apparently in the preamble of Compiler-ar.70, the image is fully responsive. Neither the image nor the VM is hung up, it's just that that load process has stopped and an MCMergeBrowser with title "Merging Compiler-ar-70" has opened.
Oh! Well, if there are no conflicts, just hit the "merge" button and proceed. I'm not sure why it's doing this but there is a possibility that it just thought it needed to do a merge when there was really no reason to. (this is the expected behavior though if you've done local mods to packages)
Wow, sometimes I really amaze myself ;-)
Sorry for the noise. As you can see I am not experienced with using MC in a shared environment, so you can officially consider this to be your dumb-user smoke test.
I can't reach SqueakSource at the moment to verify the process end-to-end, but after manually completing the update, everything looks good and the fib test gives 89 as expected.
So, on 64 bit Linux with 64 bit VM, closures are working fine.
Dave
David T. Lewis wrote:
Sorry for the noise. As you can see I am not experienced with using MC in a shared environment, so you can officially consider this to be your dumb-user smoke test.
Which is always useful. I hadn't even thought this might happen to someone ;-)
I can't reach SqueakSource at the moment to verify the process end-to-end, but after manually completing the update, everything looks good and the fib test gives 89 as expected.
So, on 64 bit Linux with 64 bit VM, closures are working fine.
Very, very good. Thanks so much!
Cheers, - Andreas
Am 17.07.2009 um 13:23 schrieb Damien Cassou:
On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raabandreas.raab@gmx.de wrote:
In any case, what is the process that users have to go through to get a closure-enabled VM on their preferred Unix flavor?
Download the 'GNU/Linux and other Unix' VM from:
I don't understand why UNIX is mentioned if only a Linux VM is available under this entry. I really would like to see a real (and actual) UNIX VM available for download.
Regards Andreas
On 17.07.2009, at 18:25, Andreas Wacknitz wrote:
Am 17.07.2009 um 13:23 schrieb Damien Cassou:
On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raabandreas.raab@gmx.de wrote:
In any case, what is the process that users have to go through to get a closure-enabled VM on their preferred Unix flavor?
Download the 'GNU/Linux and other Unix' VM from:
I don't understand why UNIX is mentioned if only a Linux VM is available under this entry. I really would like to see a real (and actual) UNIX VM available for download.
There are very few non-Linux Unix users in the Squeak community. If someone would step forward to maintain a Solaris or *BSD or whatever unixy VM binary they would be welcome. Until then, everyone who needs it compiles their own.
Alternatively, someone could set up compiling VMs on a build farm, which various projects do provide (even for free). That way we'd get more VM binaries (and hopefully the users would report back with problems).
- Bert -
Bert Freudenberg wrote:
On 17.07.2009, at 18:25, Andreas Wacknitz wrote:
Am 17.07.2009 um 13:23 schrieb Damien Cassou:
On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raabandreas.raab@gmx.de wrote:
In any case, what is the process that users have to go through to get a closure-enabled VM on their preferred Unix flavor?
Download the 'GNU/Linux and other Unix' VM from:
I don't understand why UNIX is mentioned if only a Linux VM is available under this entry. I really would like to see a real (and actual) UNIX VM available for download.
There are very few non-Linux Unix users in the Squeak community. If someone would step forward to maintain a Solaris or *BSD or whatever unixy VM binary they would be welcome. Until then, everyone who needs it compiles their own.
I used to use Squeak on NetBSD before that machine broke. It's in pkgsrc (NetBSDs packaging system) but that's meant to compile from source due to the number of platforms it runs on (and pkgsrc is used by several OSs)
On Fri, Jul 17, 2009 at 06:46:32PM +0200, Bert Freudenberg wrote:
On 17.07.2009, at 18:25, Andreas Wacknitz wrote:
Am 17.07.2009 um 13:23 schrieb Damien Cassou:
On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raabandreas.raab@gmx.de wrote:
In any case, what is the process that users have to go through to get a closure-enabled VM on their preferred Unix flavor?
Download the 'GNU/Linux and other Unix' VM from:
I don't understand why UNIX is mentioned if only a Linux VM is available under this entry. I really would like to see a real (and actual) UNIX VM available for download.
The home page for unix (including Linux) VMs is http://www.squeakvm.org/unix/. Traditionally this has included support for a fairly broad range of unix platforms, including Linux. Regardless of the relative popularity of various platforms, maintaining a broad range of support seems like a fundamentally Good Thing To Do, as it helps flush out all sorts of platform specific problems and generally makes it more likely that the VM will remain portable whenever Linux becomes unfashionable.
Currently the home page does not have updates for closure-enabled VMs, although I expect that we will be able to rectify this shortly. In the mean time, you can use the closure enabled VM that Bryce has provided for Linux systems (or of course just build your own; as long as you are using an up to date VMMaker, it will have the necessary closure support).
There are very few non-Linux Unix users in the Squeak community. If someone would step forward to maintain a Solaris or *BSD or whatever unixy VM binary they would be welcome. Until then, everyone who needs it compiles their own.
Actually I have no clue how many non-Linux Unix users might be out there. They certainly are a quiet lot, but they do seem to pop up with questions from time to time.
Alternatively, someone could set up compiling VMs on a build farm, which various projects do provide (even for free). That way we'd get more VM binaries (and hopefully the users would report back with problems).
A build farm would be a good idea, if someone is in a position to support it. Ian Piumarta has done this for many years using whatever resources might be at hand. I suspect that this is largely a labor of love, and it might not be appropriate for us to expect him to maintain a complete build farm on his kitchen table indefinitely ;)
Dave
Am 17.07.2009 um 18:46 schrieb Bert Freudenberg:
On 17.07.2009, at 18:25, Andreas Wacknitz wrote:
Am 17.07.2009 um 13:23 schrieb Damien Cassou:
On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raabandreas.raab@gmx.de wrote:
In any case, what is the process that users have to go through to get a closure-enabled VM on their preferred Unix flavor?
Download the 'GNU/Linux and other Unix' VM from:
I don't understand why UNIX is mentioned if only a Linux VM is available under this entry. I really would like to see a real (and actual) UNIX VM available for download.
There are very few non-Linux Unix users in the Squeak community. If someone would step forward to maintain a Solaris or *BSD or whatever unixy VM binary they would be welcome. Until then, everyone who needs it compiles their
I intend to create Solaris SPARC packages. Alas I have some problems with prerequisites at the moment. Libffi-3.0.8 has expected passes: 1049 unexpected failures: 285 unsupported tests: 15 I want to find out how to reduce the amount of failures (if possible). Then I will try to create real packages (not just tar files like on http://www.squeakvm.org/unix/) I don't like the /usr/local locations in the archives that are provided at squeakvm because they violate the SysV specifications. Alas I have to patch some places that were already fixed several months ago but nobody commited the changes. Of course I am also waiting for the closure changes appearing in the UNIX sources...
Alternatively, someone could set up compiling VMs on a build farm, which various projects do provide (even for free). That way we'd get more VM binaries (and hopefully the users would report back with problems).
Wow, where is a SPARC build system? :D
Regards Andreas
On 17.07.2009, at 21:55, Andreas Wacknitz wrote:
Am 17.07.2009 um 18:46 schrieb Bert Freudenberg:
On 17.07.2009, at 18:25, Andreas Wacknitz wrote:
Am 17.07.2009 um 13:23 schrieb Damien Cassou:
On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raabandreas.raab@gmx.de wrote:
In any case, what is the process that users have to go through to get a closure-enabled VM on their preferred Unix flavor?
Download the 'GNU/Linux and other Unix' VM from:
I don't understand why UNIX is mentioned if only a Linux VM is available under this entry. I really would like to see a real (and actual) UNIX VM available for download.
There are very few non-Linux Unix users in the Squeak community. If someone would step forward to maintain a Solaris or *BSD or whatever unixy VM binary they would be welcome. Until then, everyone who needs it compiles their
I intend to create Solaris SPARC packages. Alas I have some problems with prerequisites at the moment. Libffi-3.0.8 has expected passes: 1049 unexpected failures: 285 unsupported tests: 15 I want to find out how to reduce the amount of failures (if possible). Then I will try to create real packages (not just tar files like on http://www.squeakvm.org/unix/) I don't like the /usr/local locations in the archives that are provided at squeakvm because they violate the SysV specifications. Alas I have to patch some places that were already fixed several months ago but nobody commited the changes. Of course I am also waiting for the closure changes appearing in the UNIX sources...
/usr/local is just the default location for user-compiled software. If you are building system packages you can of course change that, use the prefix option for the configure script.
Alternatively, someone could set up compiling VMs on a build farm, which various projects do provide (even for free). That way we'd get more VM binaries (and hopefully the users would report back with problems).
Wow, where is a SPARC build system? :D
SourceForge used to have a Compile Farm but when I looked now it was discontinued. But this one seems to be still alive:
http://gcc.gnu.org/wiki/CompileFarm
- Bert -
Am 17.07.2009 um 22:22 schrieb Bert Freudenberg:
On 17.07.2009, at 21:55, Andreas Wacknitz wrote:
Am 17.07.2009 um 18:46 schrieb Bert Freudenberg:
On 17.07.2009, at 18:25, Andreas Wacknitz wrote:
Am 17.07.2009 um 13:23 schrieb Damien Cassou:
On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raabandreas.raab@gmx.de wrote:
In any case, what is the process that users have to go through to get a closure-enabled VM on their preferred Unix flavor?
Download the 'GNU/Linux and other Unix' VM from:
I don't understand why UNIX is mentioned if only a Linux VM is available under this entry. I really would like to see a real (and actual) UNIX VM available for download.
There are very few non-Linux Unix users in the Squeak community. If someone would step forward to maintain a Solaris or *BSD or whatever unixy VM binary they would be welcome. Until then, everyone who needs it compiles their
I intend to create Solaris SPARC packages. Alas I have some problems with prerequisites at the moment. Libffi-3.0.8 has expected passes: 1049 unexpected failures: 285 unsupported tests: 15 I want to find out how to reduce the amount of failures (if possible). Then I will try to create real packages (not just tar files like on http://www.squeakvm.org/unix/) I don't like the /usr/local locations in the archives that are provided at squeakvm because they violate the SysV specifications. Alas I have to patch some places that were already fixed several months ago but nobody commited the changes. Of course I am also waiting for the closure changes appearing in the UNIX sources...
/usr/local is just the default location for user-compiled software. If you are building system packages you can of course change that, use the prefix option for the configure script.
/usr/local violates SysV specs. User compiled software should be installed to /opt for SysV. /usr/local is only valid for BSD and Linux systems.
Andreas
On 17.07.2009, at 22:36, Andreas Wacknitz wrote:
Am 17.07.2009 um 22:22 schrieb Bert Freudenberg:
On 17.07.2009, at 21:55, Andreas Wacknitz wrote:
Am 17.07.2009 um 18:46 schrieb Bert Freudenberg:
On 17.07.2009, at 18:25, Andreas Wacknitz wrote:
Am 17.07.2009 um 13:23 schrieb Damien Cassou:
On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raab<andreas.raab@gmx.de > wrote: > In any case, what is the process that users have to go through > to get a > closure-enabled VM on their preferred Unix flavor?
Download the 'GNU/Linux and other Unix' VM from:
I don't understand why UNIX is mentioned if only a Linux VM is available under this entry. I really would like to see a real (and actual) UNIX VM available for download.
There are very few non-Linux Unix users in the Squeak community. If someone would step forward to maintain a Solaris or *BSD or whatever unixy VM binary they would be welcome. Until then, everyone who needs it compiles their
I intend to create Solaris SPARC packages. Alas I have some problems with prerequisites at the moment. Libffi-3.0.8 has expected passes: 1049 unexpected failures: 285 unsupported tests: 15 I want to find out how to reduce the amount of failures (if possible). Then I will try to create real packages (not just tar files like on http://www.squeakvm.org/unix/) I don't like the /usr/local locations in the archives that are provided at squeakvm because they violate the SysV specifications. Alas I have to patch some places that were already fixed several months ago but nobody commited the changes. Of course I am also waiting for the closure changes appearing in the UNIX sources...
/usr/local is just the default location for user-compiled software. If you are building system packages you can of course change that, use the prefix option for the configure script.
/usr/local violates SysV specs. User compiled software should be installed to /opt for SysV. /usr/local is only valid for BSD and Linux systems.
Andreas
Ah. Good to have experts :) That should be fixed in configure then (or maybe configure even knows and we override its defaults?)
- Bert -
Am 17.07.2009 um 22:55 schrieb Bert Freudenberg:
On 17.07.2009, at 22:36, Andreas Wacknitz wrote:
Am 17.07.2009 um 22:22 schrieb Bert Freudenberg:
On 17.07.2009, at 21:55, Andreas Wacknitz wrote:
Am 17.07.2009 um 18:46 schrieb Bert Freudenberg:
On 17.07.2009, at 18:25, Andreas Wacknitz wrote:
Am 17.07.2009 um 13:23 schrieb Damien Cassou:
> On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raab<andreas.raab@gmx.de > > wrote: >> In any case, what is the process that users have to go >> through to get a >> closure-enabled VM on their preferred Unix flavor? > > Download the 'GNU/Linux and other Unix' VM from:
I don't understand why UNIX is mentioned if only a Linux VM is available under this entry. I really would like to see a real (and actual) UNIX VM available for download.
There are very few non-Linux Unix users in the Squeak community. If someone would step forward to maintain a Solaris or *BSD or whatever unixy VM binary they would be welcome. Until then, everyone who needs it compiles their
I intend to create Solaris SPARC packages. Alas I have some problems with prerequisites at the moment. Libffi-3.0.8 has expected passes: 1049 unexpected failures: 285 unsupported tests: 15 I want to find out how to reduce the amount of failures (if possible). Then I will try to create real packages (not just tar files like on http://www.squeakvm.org/unix/) I don't like the /usr/local locations in the archives that are provided at squeakvm because they violate the SysV specifications. Alas I have to patch some places that were already fixed several months ago but nobody commited the changes. Of course I am also waiting for the closure changes appearing in the UNIX sources...
/usr/local is just the default location for user-compiled software. If you are building system packages you can of course change that, use the prefix option for the configure script.
/usr/local violates SysV specs. User compiled software should be installed to /opt for SysV. /usr/local is only valid for BSD and Linux systems.
Andreas
Ah. Good to have experts :) That should be fixed in configure then (or maybe configure even knows and we override its defaults?)
I am not an expert for autoconf and related things. As far as I know / usr/local is the default and you have to override it with --prefix= options (usually several are available). What it makes even more complicated is the fact that SysV asks not to use /opt/bin, opt/lib and so on but instead /opt/<package>/bin, /opt/ <package>/lib and so on. For example one could have /opt/squeak/ with sub directories bin, lib and what else is needed. Compiling squeak has some prerequisites like gmp, mpfr and libffi that need to find homes, too (if not already available at default places). As the aforementioned libraries are not delivered I have to build them or have to find providers (like OpenCSW or Blastwave). As I think that it will be more convenient for Squeakers I intend to provide them in a separate package. So nobody needs to deal with 3rd party packages. At the moment I am not sure whether to use /opt/squeak as the base directory or something different.
Andreas
On Saturday 18 Jul 2009 2:06:15 am Andreas Wacknitz wrote:
/usr/local violates SysV specs. User compiled software should be installed to /opt for SysV. /usr/local is only valid for BSD and Linux systems.
This is true only if you are installing Squeak as a traditional Unix program. /usr was reserved for network wide shared files and sys admins did not want users modifying it. /opt was pretty much available to local host admins.
Squeak is quite well-behaved in that respect and can run pretty much from a subtree located anywhere (e.g. $HOME), even on volumes mounted with noexec. See Etoys-to-go for launcher scripts that override compiled paths. If you are experimenting with different vms, this is a good option.
FYI .. Subbu
On Fri, Jul 17, 2009 at 09:55:09PM +0200, Andreas Wacknitz wrote:
Am 17.07.2009 um 18:46 schrieb Bert Freudenberg:
There are very few non-Linux Unix users in the Squeak community. If someone would step forward to maintain a Solaris or *BSD or whatever unixy VM binary they would be welcome. Until then, everyone who needs it compiles their
I intend to create Solaris SPARC packages. Alas I have some problems with prerequisites at the moment. Libffi-3.0.8 has expected passes: 1049 unexpected failures: 285 unsupported tests: 15 I want to find out how to reduce the amount of failures (if possible).
I don't know if SPARC is a 64 bit platform these days (i.e. 64 bit C pointers by default), but if so please note that the 64 bit FFI changes have not yet been merged, see http://bugs.squeak.org/view.php?id=7237
Of course I am also waiting for the closure changes appearing in the UNIX sources...
No need to wait, all of the necessary changes are already in the VMMaker package. There is no unix-specific code involved.
Dave
Am 18.07.2009 um 00:40 schrieb David T. Lewis:
On Fri, Jul 17, 2009 at 09:55:09PM +0200, Andreas Wacknitz wrote:
Am 17.07.2009 um 18:46 schrieb Bert Freudenberg:
There are very few non-Linux Unix users in the Squeak community. If someone would step forward to maintain a Solaris or *BSD or whatever unixy VM binary they would be welcome. Until then, everyone who needs it compiles their
I intend to create Solaris SPARC packages. Alas I have some problems with prerequisites at the moment. Libffi-3.0.8 has expected passes: 1049 unexpected failures: 285 unsupported tests: 15 I want to find out how to reduce the amount of failures (if possible).
I don't know if SPARC is a 64 bit platform these days (i.e. 64 bit
SPARC v9 is 64 bit. My printed SPARC v9 spec is from 1994. In Solaris usually the kernel is 64 bit, libraries are available in 32 and 64 bit (64 bit in a sparcv9 sub directory) and most applications in 32 bit. As long as an application doesn't need a 64 bit address space there is no need to have it 64 bit because unlike x86 / x64 you won't gain speed improvements in 64. The prerequisites I mentioned are available in both depths (gmp and mpfr passing all checks). Only libffi has many failing checks at the moment. My plan is to create a working squeak VM first and then care for some improvements on libffi and one or two packages. At the moment I am using Sun's GCC4SS as it generated faster executables but it will make it necessary to at least install the appropriate run time libraries. So I also consider to create a version that only depends on the system supplied gcc-3.4.3.
C pointers by default), but if so please note that the 64 bit FFI changes have not yet been merged, see http://bugs.squeak.org/view.php?id=7237
Thanks for the pointer. I son't know yet whether it will be necessary to create a 64 bit version. It seems as if most people are still satisfied with 32 bit and on SPARC this will be faster.
Of course I am also waiting for the closure changes appearing in the UNIX sources...
No need to wait, all of the necessary changes are already in the VMMaker package. There is no unix-specific code involved.
I still don't have experiences with VMMaker. It's a little bit confusing to have sources on squeakvm.org and also VMMaker. I will try it out as soon as I have a running squeak on Solaris...
Regards Andreas
On Sat, Jul 18, 2009 at 08:45:13AM +0200, Andreas Wacknitz wrote:
Am 18.07.2009 um 00:40 schrieb David T. Lewis:
On Fri, Jul 17, 2009 at 09:55:09PM +0200, Andreas Wacknitz wrote:
Of course I am also waiting for the closure changes appearing in the UNIX sources...
No need to wait, all of the necessary changes are already in the VMMaker package. There is no unix-specific code involved.
I still don't have experiences with VMMaker. It's a little bit confusing to have sources on squeakvm.org and also VMMaker. I will try it out as soon as I have a running squeak on Solaris...
If you are trying to build a VM for any unix species other than what you find on Ian's distribution page, then you should consider it an absolute requirement to use VMMaker to generate the sources. The files in platforms/unix/src will pretty much always be out of date, as they are a snapshot of generated sources as of whenever Ian may have last built a distribution.
It will take you a few hours of messing around with the VMMaker tool to get used to it, but the investment will save you a lot of confusion and wasted time.
Yes it is confusing to have a copy of the generated sources in the platforms tree, but it seems to be important for Linux distribution builders to have access to the C code, so I think it still needs to be there despite the confusion.
Dave
Am 19.07.2009 um 16:40 schrieb David T. Lewis:
On Sat, Jul 18, 2009 at 08:45:13AM +0200, Andreas Wacknitz wrote:
Am 18.07.2009 um 00:40 schrieb David T. Lewis:
On Fri, Jul 17, 2009 at 09:55:09PM +0200, Andreas Wacknitz wrote:
Of course I am also waiting for the closure changes appearing in the UNIX sources...
No need to wait, all of the necessary changes are already in the VMMaker package. There is no unix-specific code involved.
I still don't have experiences with VMMaker. It's a little bit confusing to have sources on squeakvm.org and also VMMaker. I will try it out as soon as I have a running squeak on Solaris...
If you are trying to build a VM for any unix species other than what you find on Ian's distribution page, then you should consider it an absolute requirement to use VMMaker to generate the sources. The files in platforms/unix/src will pretty much always be out of date, as they are a snapshot of generated sources as of whenever Ian may have last built a distribution.
It will take you a few hours of messing around with the VMMaker tool to get used to it, but the investment will save you a lot of confusion and wasted time.
Yes it is confusing to have a copy of the generated sources in the platforms tree, but it seems to be important for Linux distribution builders to have access to the C code, so I think it still needs to be there despite the confusion.
Dave
I have created a Solaris-10 SPARC package from Squeak-3.10-5 sources with minor patches in the SocketPlugin for UNIX. This has no closure support yet and I expect FFI will not work because of the actual state of the libffi that I used. It depends on the runtime libraries for gcc-4.3.2 from Sun (SUNWgccfss432_runtime.tar.bz2 file downloadable from Sun).
The next step is to get some experiences with VMMaker and to create closure sources with it. Some simple speed test results for my momentary SPARC machines (taken with Cuis):
" Blade 2500 (2*1,6GHz UltraSPARC-IIIi): " 0 tinyBenchmarks '97190584 bytecodes/sec; 4133412 sends/sec'
" Blade 2500 (2*1,28GHz UltraSPARC-IIIi): " 0 tinyBenchmarks '77015643 bytecodes/sec; 3275651 sends/sec'
" Blade 2000 (2*1,2GHz UltraSPARC-III)" 0 tinyBenchmarks '73101085 bytecodes/sec; 2990128 sends/sec'
" E250 (2*300MHz UltraSPARC-II):" 0 tinyBenchmarks '19643953 bytecodes/sec; 761256 sends/sec'
Regards Andreas
On Fri, Jul 17, 2009 at 9:55 PM, Andreas WacknitzA.Wacknitz@gmx.de wrote:
I intend to create Solaris SPARC packages. Alas I have some problems with prerequisites at the moment. Libffi-3.0.8 has
Hi Andreas,
I have been building squeak on Solaris / SPARC for about 4 years now for my own use. I have a list of 8 patches that I've put together, as well as a small script to apply them and run configure 'correctly'.
I agree with you about /opt; I use /opt/squeak as --prefix.
The main issue that I'm facing at the moment is that gcc-4.4.0 generates code that causes unaligned accesses in fetchFloatAtinto; the same code works in gcc-4.2.4 on SPARC. Until I or someone else (hint!) fixes this, I'm continuing to build with gcc-4.2.4. But it does concern me that the VM code shows bugs like this from time to time. I suspect that some problems remain hidden due to the fact that most users are using x86 (on whatever OS), so alignment, long pointers, and endianness bugs are never encountered.
So building and testing the VM on a platform like SPARC which enforces alignment strictly, where pointers are/can be 64-bits, and which is big-endian, will benefit the VM code.
Thanks for helping with this. Andrew
On Sat, Jul 18, 2009 at 05:25:48PM +0200, Andrew Gaylard wrote:
The main issue that I'm facing at the moment is that gcc-4.4.0 generates code that causes unaligned accesses in fetchFloatAtinto; the same code works in gcc-4.2.4 on SPARC. Until I or someone else (hint!) fixes this, I'm continuing to build with gcc-4.2.4.
fetchFloatAtInto() is implemented in platforms/Cross/vm/sqMemoryAccess.h in the form of cpp macros. It might be tricky to debug this, but I note that the implementation depends on DOUBLE_WORD_ALIGNMENT, which is a macro that would have been set when you run configure. You might playing with this setting to see if it gives you the results you want. For example, as a complete SWAG, it might be the case that SPARC plus gcc-4.2.4 needs this macro defined but for some reason configure is not setting it for you.
In any case, it would be good if you could open a Mantis issue on this so we don't forget about the issue.
But it does concern me that the VM code shows bugs like this from time to time. I suspect that some problems remain hidden due to the fact that most users are using x86 (on whatever OS), so alignment, long pointers, and endianness bugs are never encountered.
There are lots of bugs like this, and many of them are being flushed out simply because x86_64 is becoming a very common platform these days. The good news is that most bugs of this nature are quite obvious (usually a vm crash), so we typically don't get intermittent symptoms.
So building and testing the VM on a platform like SPARC which enforces alignment strictly, where pointers are/can be 64-bits, and which is big-endian, will benefit the VM code.
Absolutely yes!
Dave
Bert Freudenberg wrote:
On 17.07.2009, at 18:25, Andreas Wacknitz wrote:
Am 17.07.2009 um 13:23 schrieb Damien Cassou:
On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raabandreas.raab@gmx.de wrote:
In any case, what is the process that users have to go through to get a closure-enabled VM on their preferred Unix flavor?
Download the 'GNU/Linux and other Unix' VM from:
I don't understand why UNIX is mentioned if only a Linux VM is available under this entry. I really would like to see a real (and actual) UNIX VM available for download.
There are very few non-Linux Unix users in the Squeak community. If someone would step forward to maintain a Solaris or *BSD or whatever unixy VM binary they would be welcome. Until then, everyone who needs it compiles their own.
Hmm, the unix VM still fails to build properly on NetBSD 3.0 due to not including rpath info (and thus crashing due to missing libraries at runtime) and also it doesn't detect OSS sound properly. Bugs I believe I reported back around VM version 1.3 or so...
Here is a list of VM updates that I think would be reasonable to accomplish over the next couple of months. This is based on known issues (Mantis) with solutions that are either available now, or that can be completed without significant additional work. Comments? Additions or changes?
Dave
1) Closure support. - Priority: High, should be done as soon as possible - All major VM distributions should support images with closure bytecodes. - Current status: All necessary support incorporated in VMMaker, no platforms changes needed. - Need Ian to do a build/release to cover Unix/Linux.
2) Changes to support Etoys and teaching for kids. - Priority: High, supports large educational programs. - Mantis 7266: SerialPlugin doesn't handle arbitrary nodes names - Mantis 7103: Playing sounds in linux 64 bits causes a vm segmentation fault - Current status: These require changes to VMMaker and platforms sources, all platforms effected. Changes are straightforward but must be done in a coordinated manner for all platforms.
3) Some simple updates for 23/64 bit platforms. - Priority: Low - Mantis 7236: Make AsynchFilePlugin work on 32/64 bit images and 32/64 bit unix VMs - Mantis 6828: make FileCopyPlugin work on 32/64 bit images and 32/64 bit unix VMs - Current status: These are minor updates, low priority but easy to do. Patches are available but must be coordinated for all platforms.
4) 64-bit FFI (Interpreter updates as well as FFI) - Priority: Medium - Mantis 7237: Make FFI work on 64 bit platforms - Current status: Patches are available, but additional work and testing may be required on some platforms. I consider this update important because it effects the interpreter as well as FFI itself, e.g. these changes are a prerequisite to closing out the issues in Mantis 6987: "signed32BitValueOf:, signed64BitValueOf: etc. broken".
Hi David,
On Mon, Jul 20, 2009 at 11:05 AM, David T. Lewis lewis@mail.msen.comwrote:
Here is a list of VM updates that I think would be reasonable to accomplish over the next couple of months. This is based on known issues (Mantis) with solutions that are either available now, or that can be completed without significant additional work. Comments? Additions or changes?
Dave
- Closure support.
- Priority: High, should be done as soon as possible
- All major VM distributions should support images with closure bytecodes.
- Current status: All necessary support incorporated in VMMaker, no
platforms changes needed.
- Need Ian to do a build/release to cover Unix/Linux.
Agreed. There is an additional task which should be ready in August (sorry it is taking so long but we have other priorities) and that is using the Stack VM which is substantially faster (~ 20%) and a step towards the Cogit which is a lot faster.
2) Changes to support Etoys and teaching for kids.
- Priority: High, supports large educational programs.
- Mantis 7266: SerialPlugin doesn't handle arbitrary nodes names
- Mantis 7103: Playing sounds in linux 64 bits causes a vm segmentation
fault
- Current status: These require changes to VMMaker and platforms sources,
all platforms effected. Changes are straightforward but must be done in a coordinated manner for all platforms.
- Some simple updates for 23/64 bit platforms.
- Priority: Low
- Mantis 7236: Make AsynchFilePlugin work on 32/64 bit images and 32/64
bit unix VMs
- Mantis 6828: make FileCopyPlugin work on 32/64 bit images and 32/64 bit
unix VMs
- Current status: These are minor updates, low priority but easy to do.
Patches are available but must be coordinated for all platforms.
I'm currently working on some stuff that might affect this but there's no guarantee that we'll release it. So I agree priority is low.
4) 64-bit FFI (Interpreter updates as well as FFI)
- Priority: Medium
- Mantis 7237: Make FFI work on 64 bit platforms
- Current status: Patches are available, but additional work and testing
may be required on some platforms. I consider this update important because it effects the interpreter as well as FFI itself, e.g. these changes are a prerequisite to closing out the issues in Mantis 6987: "signed32BitValueOf:, signed64BitValueOf: etc. broken".
best Eliot
On Mon, Jul 20, 2009 at 11:25:15AM -0700, Eliot Miranda wrote:
Hi David,
On Mon, Jul 20, 2009 at 11:05 AM, David T. Lewis lewis@mail.msen.comwrote:
Here is a list of VM updates that I think would be reasonable to accomplish over the next couple of months. This is based on known issues (Mantis) with solutions that are either available now, or that can be completed without significant additional work. Comments? Additions or changes?
Dave
- Closure support.
- Priority: High, should be done as soon as possible
- All major VM distributions should support images with closure bytecodes.
- Current status: All necessary support incorporated in VMMaker, no
platforms changes needed.
- Need Ian to do a build/release to cover Unix/Linux.
Agreed. There is an additional task which should be ready in August (sorry it is taking so long but we have other priorities) and that is using the Stack VM which is substantially faster (~ 20%) and a step towards the Cogit which is a lot faster.
That's actually good timing with respect to some of the other things on the list. End of summer corresponds to start of the school year in the northern hemisphere, so we can target having all major VMs supporting the closure bytecodes now, followed by an end-of-summer release that covers at least item #2 two below. That would be the right time to also include whatever things you may have ready to go in the August time frame.
- Changes to support Etoys and teaching for kids.
- Priority: High, supports large educational programs.
- Mantis 7266: SerialPlugin doesn't handle arbitrary nodes names
- Mantis 7103: Playing sounds in linux 64 bits causes a vm segmentation
fault
- Current status: These require changes to VMMaker and platforms sources,
all platforms effected. Changes are straightforward but must be done in a coordinated manner for all platforms.
- Some simple updates for 23/64 bit platforms.
- Priority: Low
- Mantis 7236: Make AsynchFilePlugin work on 32/64 bit images and 32/64
bit unix VMs
- Mantis 6828: make FileCopyPlugin work on 32/64 bit images and 32/64 bit
unix VMs
- Current status: These are minor updates, low priority but easy to do.
Patches are available but must be coordinated for all platforms.
I'm currently working on some stuff that might affect this but there's no guarantee that we'll release it. So I agree priority is low.
- 64-bit FFI (Interpreter updates as well as FFI)
- Priority: Medium
- Mantis 7237: Make FFI work on 64 bit platforms
- Current status: Patches are available, but additional work and testing
may be required on some platforms. I consider this update important because it effects the interpreter as well as FFI itself, e.g. these changes are a prerequisite to closing out the issues in Mantis 6987: "signed32BitValueOf:, signed64BitValueOf: etc. broken".
best Eliot
vm-dev@lists.squeakfoundation.org