March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] VM Crashes

by Igor Stasenko

On 8 March 2013 10:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 08 Mar 2013, at 09:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> On 2013-03-08, at 02:52, "David T. Lewis" <lewis(a)mail.msen.com> wrote: >> >>> On Thu, Mar 07, 2013 at 11:23:22PM +0100, Sven Van Caekenberghe wrote: >>>> Hi Eliot, >>>> >>>> On 07 Mar 2013, at 23:12, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>>> I seem to be talking to thin air. If you would use an up-to-date VM your crashes would disappear. This bug was fixed this last week. You are using a VM from December of last year. Of course if you don't want to fix your bug lease continue to ignore anything I might have to say. >>>> >>>> I tried using your latest cog vm, but the Pharo 2.0 image side check complained: >>>> >>>> checkVMVersion >>>> "Display a warning if the VM is too old" >>>> | displayError | >>>> displayError := [ ^ self inform: 'Your VM is too old for this image. Please download the latest VM.' ]. >>>> [(VirtualMachine interpreterSourceDate > '2012-07-08+2:00' asDate) >>>> ifFalse: displayError >>>> ] on: Error do: [ :e| displayError value ]. >>>> >>>> I was unsure if this was a real problem or not ? >>> >>> This method in the image is completely wrong and misleading. The VM that >>> was being used is clearly *not* out of date. If the intent is to give the >>> user a message that says "please use only the latest Pharo VM", then it should >>> say so. >> >> Pharo ships with the PharoVM, hence the targeted audience will have an outdated >> PharoVM, we can make the message more explicit, but it IS an outdate VM no matter >> what. >> >> Besides, we print the VM version date in a different format, which won't lead to >> a parsing error. If you run this on a VM not built by us you get a VM out of date. >> >>> To check explicitly for a Pharo VM I would suggest adding a primitive or VM >>> parameter that identifies the VM as Pharo-specific so the checkVMVersion can >>> distinguish an out-of-date Pharo VM and provide an appropriate warning message. >> >> yes we could update the error message to inform that the user should download >> the latest PharoVM. But as I said before, Pharo is shipped with the branded >> PharoVM, to limit the confusion for newcomers. CogVM, NBCogCM, StackVM, SqueakVM >> and guess not what other names are simply not parseable by newcomers. >> >>> It is really not fair to ask Eliot to spend his time debugging "Cog problems" >>> when the image is sending incorrect error messages. >> >> well, he is free to adopt our additions we made to the FileSystem primitives and >> integrate NativeBoost. >> >> Only if those are integrated I see reason to make this error message disappear on >> other VMs than ours. Otherwise not displaying the error message is misleading >> behavior as well FOR THE WHOLE COMMUNITY. > > Thanks for the explanation, Camillo. > > The crux of the matter is the point about the FileSystem primitives and NativeBoost. > The test itself is misleading as it only seems to check a date and then declares VM's too old. > Maybe it should test for the primitives, if that is possible. > Also the warning 'Too old' should be changed to 'Does not contain the necessary primitives to run Pharo' if I understand correctly. > hmm.. then your tests will define "today's old VM" but since things are moving, you have to throw this test away fairly soon.. to avoid that, i would check the version / VM release date.. but not some concrete feature, because at longer time scale it makes no sense. And to cover features, we have unit tests :) > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > -- Best regards, Igor Stasenko.

March 8, 2013

Re: [Pharo-project] VM Crashes

by Camillo Bruni

> Thanks for the explanation, Camillo. > > The crux of the matter is the point about the FileSystem primitives and NativeBoost. > The test itself is misleading as it only seems to check a date and then declares VM's too old. > Maybe it should test for the primitives, if that is possible. Well indeed we could check if the FS primitives return an array containing all information we need. The date itself might be a bit brittle, but since the other VMs don't have a parseable date it should fail there, mission accomplished, though with dubious tests, I agree ;) > Also the warning 'Too old' should be changed to 'Does not contain the necessary primitives to run Pharo' if I understand correctly. If it's too old, what do you do? you go and fetch a newer VM ;). So I would say the implied actions are ok, especially for newcomers, but there should be more details indeed.

March 8, 2013

Re: [Pharo-project] VM Crashes

by Sven Van Caekenberghe

On 08 Mar 2013, at 09:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: > On 2013-03-08, at 02:52, "David T. Lewis" <lewis(a)mail.msen.com> wrote: > >> On Thu, Mar 07, 2013 at 11:23:22PM +0100, Sven Van Caekenberghe wrote: >>> Hi Eliot, >>> >>> On 07 Mar 2013, at 23:12, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>>> I seem to be talking to thin air. If you would use an up-to-date VM your crashes would disappear. This bug was fixed this last week. You are using a VM from December of last year. Of course if you don't want to fix your bug lease continue to ignore anything I might have to say. >>> >>> I tried using your latest cog vm, but the Pharo 2.0 image side check complained: >>> >>> checkVMVersion >>> "Display a warning if the VM is too old" >>> | displayError | >>> displayError := [ ^ self inform: 'Your VM is too old for this image. Please download the latest VM.' ]. >>> [(VirtualMachine interpreterSourceDate > '2012-07-08+2:00' asDate) >>> ifFalse: displayError >>> ] on: Error do: [ :e| displayError value ]. >>> >>> I was unsure if this was a real problem or not ? >> >> This method in the image is completely wrong and misleading. The VM that >> was being used is clearly *not* out of date. If the intent is to give the >> user a message that says "please use only the latest Pharo VM", then it should >> say so. > > Pharo ships with the PharoVM, hence the targeted audience will have an outdated > PharoVM, we can make the message more explicit, but it IS an outdate VM no matter > what. > > Besides, we print the VM version date in a different format, which won't lead to > a parsing error. If you run this on a VM not built by us you get a VM out of date. > >> To check explicitly for a Pharo VM I would suggest adding a primitive or VM >> parameter that identifies the VM as Pharo-specific so the checkVMVersion can >> distinguish an out-of-date Pharo VM and provide an appropriate warning message. > > yes we could update the error message to inform that the user should download > the latest PharoVM. But as I said before, Pharo is shipped with the branded > PharoVM, to limit the confusion for newcomers. CogVM, NBCogCM, StackVM, SqueakVM > and guess not what other names are simply not parseable by newcomers. > >> It is really not fair to ask Eliot to spend his time debugging "Cog problems" >> when the image is sending incorrect error messages. > > well, he is free to adopt our additions we made to the FileSystem primitives and > integrate NativeBoost. > > Only if those are integrated I see reason to make this error message disappear on > other VMs than ours. Otherwise not displaying the error message is misleading > behavior as well FOR THE WHOLE COMMUNITY. Thanks for the explanation, Camillo. The crux of the matter is the point about the FileSystem primitives and NativeBoost. The test itself is misleading as it only seems to check a date and then declares VM's too old. Maybe it should test for the primitives, if that is possible. Also the warning 'Too old' should be changed to 'Does not contain the necessary primitives to run Pharo' if I understand correctly. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 8, 2013

Re: [Pharo-project] Is ciPharo20CogVM.sh downloading a VM from December?

by Camillo Bruni

yes this is correct. The CogVM hasn't been properly built since december or so. The vm for Pharo is the PharoVM, simple ;) You can easily see that there is indeed no newer build: http://pharo.gforge.inria.fr/ci/vm/cog/mac/ but there is here: http://pharo.gforge.inria.fr/ci/vm/pharo/mac/ so use the following: ------------------------------------------------------------------- curl -L http://files.pharo.org/script/ciPharo20PharoVM.sh | bash ------------------------------------------------------------------- files.pharo.org ~~> forwards to pharo.gforge.inria.fr/ci but is going be replaced with a our own server pretty soon, so it might save you some work when using this url ;) PharoVM The official VM for Pharo heavily stressed by our CI ;) https://ci.inria.fr/pharo/view/VM/job/PharoVM/ https://ci.inria.fr/pharo/view/VM/job/PharoVM-tests/ I hope this answers your question? On 2013-03-07, at 20:50, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Hi - > > I buried this question in another thread and have decided to make it its > own. > > > Today when I ran this : > > curl http://pharo.gforge.inria.fr/ci/script/ciPharo20CogVM.sh | bash > > > I was left with a VM that claims this is true: > > paul@paul-laptop:~/pharo/p2$ ./vm.sh -version > 3.9-7 #1 Wed Dec 12 16:08:04 CET 2012 gcc 4.6.3 > CoInterpreter VMMaker-oscog-EstebanLorenzano.166 uuid: > 5773fcb9-2982-4507-8a9e-4308ec33731e Dec 12 2012 > StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.166 uuid: > 5773fcb9-2982-4507-8a9e-4308ec33731e Dec 12 2012 > git://gitorious.org/cogvm/blessed.git Commit: > 452863bdfba2ba0b188e7b172e9bc597a2caa928 Date: 2012-12-07 16:49:46 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #5922 > Linux pharo-linux64 3.2.0-31-generic #50-Ubuntu SMP Fri Sep 7 16:16:45 > UTC 2012 x86_64 x86_64 x86_64 GNU/Linux > plugin path: /home/paul/pharo/p2/vm/ [default: /home/paul/pharo/p2/vm/] > > > > and also: > > paul@paul-laptop:~/pharo/p2/vm$ ls -latr > total 39316 > -rw-r--r-- 1 paul paul 16235372 Oct 19 2009 PharoV10.sources > drwxrwxr-x 2 paul paul 4096 Sep 30 03:52 __MACOSX > -rwxrwxr-x 1 paul paul 34420 Dec 12 07:07 libFT2Plugin.so > -rwxrwxr-x 1 paul paul 34639 Dec 12 07:08 libSqueakFFIPrims.so > -rwxrwxr-x 1 paul paul 71180 Dec 12 07:08 libB3DAcceleratorPlugin.so > -rwxrwxr-x 1 paul paul 21929 Dec 12 07:08 libSqueakSSL.so > -rwxrwxr-x 1 paul paul 12230 Dec 12 07:08 libInternetConfigPlugin.so > -rwxrwxr-x 1 paul paul 14461 Dec 12 07:08 vm-display-null > -rwxrwxr-x 1 paul paul 1300278 Dec 12 07:08 CogVM > -rwxrwxr-x 1 paul paul 7773 Dec 12 07:08 vm-sound-null > -rwxrwxr-x 1 paul paul 28640 Dec 12 07:08 vm-sound-ALSA > -rwxrwxr-x 1 paul paul 121415 Dec 12 07:08 vm-display-X11 > -rw-r--r-- 1 paul paul 22239552 Mar 4 06:14 PharoV20.sources > drwxrwxr-x 3 paul paul 4096 Mar 7 06:58 . > drwxrwxr-x 4 paul paul 4096 Mar 7 11:00 .. > > > > Is that right and is that actually a VM with the latest updates? > > Thanks > > Paul >

March 8, 2013

Re: [Pharo-project] osprocess in pharo 2.0

by Camillo Bruni

On 2013-03-07, at 22:35, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > EstebanLM wrote >> it would be really cool to have a metacello configuration in >> MetaRepoForPharo20 > > There is one there :) I wonder why it fails on the build-server? https://ci.inria.fr/pharo-contribution/job/OSProcess/

March 8, 2013

Re: [Pharo-project] VM Crashes

by Camillo Bruni

On 2013-03-08, at 02:52, "David T. Lewis" <lewis(a)mail.msen.com> wrote: > On Thu, Mar 07, 2013 at 11:23:22PM +0100, Sven Van Caekenberghe wrote: >> Hi Eliot, >> >> On 07 Mar 2013, at 23:12, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> I seem to be talking to thin air. If you would use an up-to-date VM your crashes would disappear. This bug was fixed this last week. You are using a VM from December of last year. Of course if you don't want to fix your bug lease continue to ignore anything I might have to say. >> >> I tried using your latest cog vm, but the Pharo 2.0 image side check complained: >> >> checkVMVersion >> "Display a warning if the VM is too old" >> | displayError | >> displayError := [ ^ self inform: 'Your VM is too old for this image. Please download the latest VM.' ]. >> [(VirtualMachine interpreterSourceDate > '2012-07-08+2:00' asDate) >> ifFalse: displayError >> ] on: Error do: [ :e| displayError value ]. >> >> I was unsure if this was a real problem or not ? > > This method in the image is completely wrong and misleading. The VM that > was being used is clearly *not* out of date. If the intent is to give the > user a message that says "please use only the latest Pharo VM", then it should > say so. Pharo ships with the PharoVM, hence the targeted audience will have an outdated PharoVM, we can make the message more explicit, but it IS an outdate VM no matter what. Besides, we print the VM version date in a different format, which won't lead to a parsing error. If you run this on a VM not built by us you get a VM out of date. > To check explicitly for a Pharo VM I would suggest adding a primitive or VM > parameter that identifies the VM as Pharo-specific so the checkVMVersion can > distinguish an out-of-date Pharo VM and provide an appropriate warning message. yes we could update the error message to inform that the user should download the latest PharoVM. But as I said before, Pharo is shipped with the branded PharoVM, to limit the confusion for newcomers. CogVM, NBCogCM, StackVM, SqueakVM and guess not what other names are simply not parseable by newcomers. > It is really not fair to ask Eliot to spend his time debugging "Cog problems" > when the image is sending incorrect error messages. well, he is free to adopt our additions we made to the FileSystem primitives and integrate NativeBoost. Only if those are integrated I see reason to make this error message disappear on other VMs than ours. Otherwise not displaying the error message is misleading behavior as well FOR THE WHOLE COMMUNITY.

March 8, 2013

Re: [Pharo-project] please add me to phexample

by Stefan Marr

Hi Doru: On 08 Mar 2013, at 06:54, Tudor Girba wrote: > The #development version of ConfigurationOfPhexample points to a hardcoded version. Phexample is used extensively in Fame, and Fame is a Moose project, and we have the convention that the Moose projects should have the #development version point to a baseline. > > Please add me to the project so that I can fix the configuration. I added you. But, please, before you fix the configuration, have a look at Stef's solution to the #includesSubString: vs. #includesSubstring: issue between Pharo 1.4 and Pharo 2.0. His solution is to use Phexample-StefanMarr.67 as Pharo 2.0 implementation and Phexample-StephaneDucasse.68 as Pharo 1.4 version. See [1]. I don't think this is maintainable, but did not yet get around to do it properly. Thanks Stefan [1] http://smalltalkhub.com/#!/~Phexample/Phexample/diff/Phexample-StephaneDuca… -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

March 8, 2013

[Pharo-project] We should send the call for presentation for ESUG

by StÃ©phane Ducasse

so what is the status for the registration server? Stef

March 8, 2013

[Pharo-project] please add me to phexample

by Tudor Girba

Hi, The #development version of ConfigurationOfPhexample points to a hardcoded version. Phexample is used extensively in Fame, and Fame is a Moose project, and we have the convention that the Moose projects should have the #development version point to a baseline. Please add me to the project so that I can fix the configuration. Cheers, Doru -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

March 8, 2013

Re: [Pharo-project] VM Crashes

by David T. Lewis

On Thu, Mar 07, 2013 at 11:23:22PM +0100, Sven Van Caekenberghe wrote: > Hi Eliot, > > On 07 Mar 2013, at 23:12, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > I seem to be talking to thin air. If you would use an up-to-date VM your crashes would disappear. This bug was fixed this last week. You are using a VM from December of last year. Of course if you don't want to fix your bug lease continue to ignore anything I might have to say. > > I tried using your latest cog vm, but the Pharo 2.0 image side check complained: > > checkVMVersion > "Display a warning if the VM is too old" > | displayError | > displayError := [ ^ self inform: 'Your VM is too old for this image. Please download the latest VM.' ]. > [(VirtualMachine interpreterSourceDate > '2012-07-08+2:00' asDate) > ifFalse: displayError > ] on: Error do: [ :e| displayError value ]. > > I was unsure if this was a real problem or not ? This method in the image is completely wrong and misleading. The VM that was being used is clearly *not* out of date. If the intent is to give the user a message that says "please use only the latest Pharo VM", then it should say so. To check explicitly for a Pharo VM I would suggest adding a primitive or VM parameter that identifies the VM as Pharo-specific so the checkVMVersion can distinguish an out-of-date Pharo VM and provide an appropriate warning message. It is really not fair to ask Eliot to spend his time debugging "Cog problems" when the image is sending incorrect error messages. Dave

March 8, 2013