Unix VM closure enabled?
Locked
12
12
 
|
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 |
|
|
In reply to this post by Andreas.Raab
On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raab<[hidden email]> 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 Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry |
README.txt (1K) |
|
On Fri, Jul 17, 2009 at 01:23:55PM +0200, Damien Cassou wrote: > > On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raab<[hidden email]> 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 |
Re: Unix VM closure enabled?
|
|
In reply to this post by Damien Cassou-3
Am 17.07.2009 um 13:23 schrieb Damien Cassou: > On Wed, Jul 15, 2009 at 12:56 AM, Andreas Raab<[hidden email]> > 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 |
Re: Unix VM closure enabled?
|
|
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<[hidden email]> >> 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 - |
|
|
In reply to this post by David T. Lewis
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 |
|
|
In reply to this post by Bert Freudenberg
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 Raab<[hidden email]> >>> 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. > (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) |
|
|
In reply to this post by Bert Freudenberg
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 Raab<[hidden email]> > >>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 |
|
|
In reply to this post by Andreas.Raab
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 |
Re: Unix VM closure enabled?
|
|
In reply to this post by Bert Freudenberg
Am 17.07.2009 um 18:46 schrieb Bert Freudenberg: 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... Wow, where is a SPARC build system? :D Regards Andreas |
Re: Unix VM closure enabled?
|
|
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<[hidden email]> 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 - |
Re: Unix VM closure enabled?
|
|
Am 17.07.2009 um 22:22 schrieb Bert Freudenberg: /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
|
Re: Unix VM closure enabled?
|
|
On 17.07.2009, at 22:36, Andreas Wacknitz wrote:
Ah. Good to have experts :) That should be fixed in configure then (or maybe configure even knows and we override its defaults?) - Bert - |
Re: Unix VM closure enabled?
|
|
Am 17.07.2009 um 22:55 schrieb Bert Freudenberg:
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
|
|
|
In reply to this post by Andreas Wacknitz
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 |
Re: Unix VM closure enabled?
|
|
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 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 |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |