Re: [Moose-dev] Re: where to report vm crashes? (while running Moose tests)
Locked
Re: [Moose-dev] Re: where to report vm crashes? (while running Moose tests)
 
|
It would be good to have a parallel job, but the problem is that you will get a message saying that the VM is too old for the Pharo 2.0 image.
Cheers, Doru On Tue, Mar 12, 2013 at 9:05 AM, Usman Bhatti <[hidden email]> wrote:
"Every thing has its own flow"
|
Re: [Moose-dev] Re: where to report vm crashes? (while running Moose tests)
|
|
On 2013-03-12, at 09:22, Tudor Girba <[hidden email]> wrote: > It would be good to have a parallel job, but the problem is that you will > get a message saying that the VM is too old for the Pharo 2.0 image. from that point of view, it is just a warning. Unless you do some fancy new FileSystem stuff it will continue to work with 2.0 and for a while with 3.0. So if you just keep it as a backup job that is fine then :) > Cheers, > Doru > > > On Tue, Mar 12, 2013 at 9:05 AM, Usman Bhatti <[hidden email]>wrote: > >> Doru, >> >> In the meantime, can we revert to CogVM because currently we cannot see >> the status of fixes and we cannot go any further with Moose 4.8 or may be >> create parallel jobs on Cog and Pharo vms ? >> >> >> >> On Mon, Mar 11, 2013 at 9:53 PM, Tudor Girba <[hidden email]> wrote: >> >>> Hi, >>> >>> Where should I report Pharo VM crashes with Pharo 2.0? >>> >>> In particular, I wanted to report the problem related to running Moose >>> tests from the command line: >>> >>> --- >>> You can reproduce it on Mac, quite consistently: just run the attached >>> script (you need to have wget installed), or do it manually: >>> >>> 1. download and unzip the latest Moose 4.8: >>> >>> https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastSuccessfulBuild/artifact/Moose-latest-dev-4.8.zip >>> 2. download and unzip the latest Pharo VM: >>> http://pharo.gforge.inria.fr/ci/vm/pharo/mac/pharo-mac-latest.zip >>> 3. execute: >>> ./Pharo.app/Contents/MacOS/Pharo ./Moose-latest-dev-4.8.image moosetest >>> >>> The VM crashes, but there is no trace of the error. >>> --- >>> >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "It's not what we do that matters most, it's how we do it." >>> >>> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" |
|
|
In reply to this post by Tudor Girba-2
not really true... the old vm should appear just in really old vm builds (there was a bug last week introduced in the last moment that was showing again the warning, but that is fixed now). now... I would really like you to stay using the new vms, and report the crashes so we can work on them... we cannot blindly fix, you now :) Esteban On Mar 12, 2013, at 9:22 AM, Tudor Girba <[hidden email]> wrote:
|
Re: [Moose-dev] Re: Re: where to report vm crashes? (while running Moose tests)
|
|
On Tue, Mar 12, 2013 at 9:39 AM, Esteban Lorenzano <[hidden email]> wrote:
Agreed, I proposed it because we didn't know when the bug was going to be fixed and with this bug, we do not see the progress of our bug fixes in Moose 4.8. But now that you say you'll have a look today (and hopefully it's fixed today :-), there's no need to create a parallel job on Cog.
usman Â
|
Re: [Moose-dev] Re: where to report vm crashes? (while running Moose tests)
|
|
In reply to this post by Camillo Bruni-3
Camillo,
On 12 Mar 2013, at 09:39, Camillo Bruni <[hidden email]> wrote: > from that point of view, it is just a warning. Unless you do some fancy > new FileSystem stuff it will continue to work with 2.0 and for a while with > 3.0. Is it not possible to clarify *exactly* what is missing and will not work well. Right now this is like a mystery. We are all developers and capable of understanding a technical explanation ;-) Which primitives are we talking about, how are they used and what end user effect do they have ? I know that NativeBoost is an important difference. The question is, will the image start without proper NB support and will something be broken if NB is non-functional (apart from NB code itself, I mean high level normal stuff) ? Thx, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill |
Re: [Moose-dev] Re: where to report vm crashes? (while running Moose tests)
|
|
On 2013-03-12, at 10:17, Sven Van Caekenberghe <[hidden email]> wrote: > Camillo, > > On 12 Mar 2013, at 09:39, Camillo Bruni <[hidden email]> wrote: > >> from that point of view, it is just a warning. Unless you do some fancy >> new FileSystem stuff it will continue to work with 2.0 and for a while with >> 3.0. > > Is it not possible to clarify *exactly* what is missing and will not work well. > > Right now this is like a mystery. > > We are all developers and capable of understanding a technical explanation ;-) > > Which primitives are we talking about, how are they used and what end user effect do they have ? > > I know that NativeBoost is an important difference. The question is, will the image start without proper NB support and will something be broken if NB is non-functional (apart from NB code itself, I mean high level normal stuff) ? Well so far there is only some FileSystem primitives, and besides the tests nobody ever relied on getting the permissions or checks if a file is an symlink. But we can do that now. NativeBoost is shipped with 2.0 but not yet used in the Kernel, but this is going to change in 3.0 where we hope to rewrite the UI driver talking to Cairo using an NativeBoost-FFI binding. The thing is, I don't want to care and define which external VMs work with which Pharo version. (Still, yes you can run Pharo 20 on CogVM, we just don't like it :P ) Pharo ships and runs only with the Pharo and the PharoS VM. Currently the situation is not perfect with our VMs being unstable |
Re: [Moose-dev] Re: where to report vm crashes? (while running Moose tests)
|
|
On 12 Mar 2013, at 12:15, Camillo Bruni <[hidden email]> wrote: > On 2013-03-12, at 10:17, Sven Van Caekenberghe <[hidden email]> wrote: > >> Camillo, >> >> On 12 Mar 2013, at 09:39, Camillo Bruni <[hidden email]> wrote: >> >>> from that point of view, it is just a warning. Unless you do some fancy >>> new FileSystem stuff it will continue to work with 2.0 and for a while with >>> 3.0. >> >> Is it not possible to clarify *exactly* what is missing and will not work well. >> >> Right now this is like a mystery. >> >> We are all developers and capable of understanding a technical explanation ;-) >> >> Which primitives are we talking about, how are they used and what end user effect do they have ? >> >> I know that NativeBoost is an important difference. The question is, will the image start without proper NB support and will something be broken if NB is non-functional (apart from NB code itself, I mean high level normal stuff) ? Thanks for the answers, Camillo. First off: I am absolutely for a Pharo vm - we need to take maximal control over this crucial element. Incredible progress has been made the last year, year and a half, and that is fantastic and has to continue. The bin directory is cleaner and all the scripting is much better. > Well so far there is only some FileSystem primitives, and besides the tests nobody > ever relied on getting the permissions or checks if a file is an symlink. But we > can do that now. But you still did not answer exactly which primitives, which methods. I think this is important knowledge that has to be public and documented. > NativeBoost is shipped with 2.0 but not yet used in the Kernel, but this is going > to change in 3.0 where we hope to rewrite the UI driver talking to Cairo using > an NativeBoost-FFI binding. > > The thing is, I don't want to care and define which external VMs work with which > Pharo version. (Still, yes you can run Pharo 20 on CogVM, we just don't like it :P ) I agree that we should maximally use the same Pharo VM to get the best possible testing exposure and to improve the quality. But it is very important to be able to diagnose strange VM crashes by using different VM's. The JIT code is still under active development and we need Eliot in the loop. He needs the option that the large Pharo community uses/tests his work, we need his help. Maybe given a clear description of the primitives situation will result in enough users asking for them to be included in the standard Cog VM as well. > Pharo ships and runs only with the Pharo and the PharoS VM. > Currently the situation is not perfect with our VMs being unstable I was doing some more builds today with the headless Pharo VM on Linux and these went fine. I like the config handler more and more ! Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill |
Re: [Moose-dev] Re: where to report vm crashes? (while running Moose tests)
|
|
Yes, this headless thing is really building traction.
Phil 2013/3/12 Sven Van Caekenberghe <[hidden email]>: > > On 12 Mar 2013, at 12:15, Camillo Bruni <[hidden email]> wrote: > >> On 2013-03-12, at 10:17, Sven Van Caekenberghe <[hidden email]> wrote: >> >>> Camillo, >>> >>> On 12 Mar 2013, at 09:39, Camillo Bruni <[hidden email]> wrote: >>> >>>> from that point of view, it is just a warning. Unless you do some fancy >>>> new FileSystem stuff it will continue to work with 2.0 and for a while with >>>> 3.0. >>> >>> Is it not possible to clarify *exactly* what is missing and will not work well. >>> >>> Right now this is like a mystery. >>> >>> We are all developers and capable of understanding a technical explanation ;-) >>> >>> Which primitives are we talking about, how are they used and what end user effect do they have ? >>> >>> I know that NativeBoost is an important difference. The question is, will the image start without proper NB support and will something be broken if NB is non-functional (apart from NB code itself, I mean high level normal stuff) ? > > Thanks for the answers, Camillo. > > First off: I am absolutely for a Pharo vm - we need to take maximal control over this crucial element. Incredible progress has been made the last year, year and a half, and that is fantastic and has to continue. The bin directory is cleaner and all the scripting is much better. > >> Well so far there is only some FileSystem primitives, and besides the tests nobody >> ever relied on getting the permissions or checks if a file is an symlink. But we >> can do that now. > > But you still did not answer exactly which primitives, which methods. I think this is important knowledge that has to be public and documented. > >> NativeBoost is shipped with 2.0 but not yet used in the Kernel, but this is going >> to change in 3.0 where we hope to rewrite the UI driver talking to Cairo using >> an NativeBoost-FFI binding. >> >> The thing is, I don't want to care and define which external VMs work with which >> Pharo version. (Still, yes you can run Pharo 20 on CogVM, we just don't like it :P ) > > I agree that we should maximally use the same Pharo VM to get the best possible testing exposure and to improve the quality. > > But it is very important to be able to diagnose strange VM crashes by using different VM's. The JIT code is still under active development and we need Eliot in the loop. He needs the option that the large Pharo community uses/tests his work, we need his help. > > Maybe given a clear description of the primitives situation will result in enough users asking for them to be included in the standard Cog VM as well. > >> Pharo ships and runs only with the Pharo and the PharoS VM. >> Currently the situation is not perfect with our VMs being unstable > > I was doing some more builds today with the headless Pharo VM on Linux and these went fine. I like the config handler more and more ! > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > |
|
|
In reply to this post by Tudor Girba-2
Hi,
Doru, I just compiled a new version of the VM, that mixes a merge from latest Eliot sources with a lot of work in the optimization flags to prevent random crashes (yes, I hate C and its nondeterministic behavior for VMs :P). Moose tests are now not crashing in my machine (both in mac and unix... didn't tested in windows). Can you check if this solves the problem? cheers, Esteban On Mar 12, 2013, at 9:22 AM, Tudor Girba <[hidden email]> wrote:
|
Re: [Moose-dev] Re: where to report vm crashes? (while running Moose tests)
|
|
Great.
I ran the tests locally and it did not crash! I now switched the Jenkins job to use the new Pharo VM, but it did not work. Perhaps the VM did not make it all the way to the ZeroConf scripts. I used this: wget --quiet -qO - http://pharo.gforge.inria.fr/ci/script/ciPharo20NBCogVM.sh | bash Cheers, Doru On Mar 13, 2013, at 6:37 PM, Esteban Lorenzano <[hidden email]> wrote: > Hi, > > Doru, I just compiled a new version of the VM, that mixes a merge from latest Eliot sources with a lot of work in the optimization flags to prevent random crashes (yes, I hate C and its nondeterministic behavior for VMs :P). > Moose tests are now not crashing in my machine (both in mac and unix... didn't tested in windows). > > Can you check if this solves the problem? > > https://ci.inria.fr/pharo/view/VM/job/PharoVM/Architecture=32,Slave=vm-builder-mac/lastSuccessfulBuild/artifact/pharo-mac.zip > https://ci.inria.fr/pharo/view/VM/job/PharoVM/Architecture=32,Slave=vm-builder-linux/lastSuccessfulBuild/artifact/pharo-linux.zip > > cheers, > Esteban > > > On Mar 12, 2013, at 9:22 AM, Tudor Girba <[hidden email]> wrote: > >> It would be good to have a parallel job, but the problem is that you will get a message saying that the VM is too old for the Pharo 2.0 image. >> >> Cheers, >> Doru >> >> >> On Tue, Mar 12, 2013 at 9:05 AM, Usman Bhatti <[hidden email]> wrote: >> Doru, >> >> In the meantime, can we revert to CogVM because currently we cannot see the status of fixes and we cannot go any further with Moose 4.8 or may be create parallel jobs on Cog and Pharo vms ? >> >> >> >> On Mon, Mar 11, 2013 at 9:53 PM, Tudor Girba <[hidden email]> wrote: >> Hi, >> >> Where should I report Pharo VM crashes with Pharo 2.0? >> >> In particular, I wanted to report the problem related to running Moose tests from the command line: >> >> --- >> You can reproduce it on Mac, quite consistently: just run the attached script (you need to have wget installed), or do it manually: >> >> 1. download and unzip the latest Moose 4.8: >> https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastSuccessfulBuild/artifact/Moose-latest-dev-4.8.zip >> 2. download and unzip the latest Pharo VM: >> http://pharo.gforge.inria.fr/ci/vm/pharo/mac/pharo-mac-latest.zip >> 3. execute: >> ./Pharo.app/Contents/MacOS/Pharo ./Moose-latest-dev-4.8.image moosetest >> >> The VM crashes, but there is no trace of the error. >> --- >> >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "It's not what we do that matters most, it's how we do it." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > -- www.tudorgirba.com "Be rather willing to give than demanding to get." |
|
|
Cool!
there is not specific scripot for using the latest pharo vm. You should split the process in two: wget --quiet -qO - http://pharo.gforge.inria.fr/ci/script/ciPharo20.sh | bash wget --quiet -qO - http://pharo.gforge.inria.fr/ci/script/ciPharoVMLatest.sh | bash anyway, I will promote the new vms as "stable" tomorrow, then you will be able to use: wget --quiet -qO - http://pharo.gforge.inria.fr/ci/script/ciPharo20PharoVM.sh | bash (but that, tomorrow :) Esteban On Mar 13, 2013, at 9:45 PM, Tudor Girba <[hidden email]> wrote: > Great. > > I ran the tests locally and it did not crash! > > I now switched the Jenkins job to use the new Pharo VM, but it did not work. Perhaps the VM did not make it all the way to the ZeroConf scripts. I used this: > wget --quiet -qO - http://pharo.gforge.inria.fr/ci/script/ciPharo20NBCogVM.sh | bash > > > Cheers, > Doru > > > On Mar 13, 2013, at 6:37 PM, Esteban Lorenzano <[hidden email]> wrote: > >> Hi, >> >> Doru, I just compiled a new version of the VM, that mixes a merge from latest Eliot sources with a lot of work in the optimization flags to prevent random crashes (yes, I hate C and its nondeterministic behavior for VMs :P). >> Moose tests are now not crashing in my machine (both in mac and unix... didn't tested in windows). >> >> Can you check if this solves the problem? >> >> https://ci.inria.fr/pharo/view/VM/job/PharoVM/Architecture=32,Slave=vm-builder-mac/lastSuccessfulBuild/artifact/pharo-mac.zip >> https://ci.inria.fr/pharo/view/VM/job/PharoVM/Architecture=32,Slave=vm-builder-linux/lastSuccessfulBuild/artifact/pharo-linux.zip >> >> cheers, >> Esteban >> >> >> On Mar 12, 2013, at 9:22 AM, Tudor Girba <[hidden email]> wrote: >> >>> It would be good to have a parallel job, but the problem is that you will get a message saying that the VM is too old for the Pharo 2.0 image. >>> >>> Cheers, >>> Doru >>> >>> >>> On Tue, Mar 12, 2013 at 9:05 AM, Usman Bhatti <[hidden email]> wrote: >>> Doru, >>> >>> In the meantime, can we revert to CogVM because currently we cannot see the status of fixes and we cannot go any further with Moose 4.8 or may be create parallel jobs on Cog and Pharo vms ? >>> >>> >>> >>> On Mon, Mar 11, 2013 at 9:53 PM, Tudor Girba <[hidden email]> wrote: >>> Hi, >>> >>> Where should I report Pharo VM crashes with Pharo 2.0? >>> >>> In particular, I wanted to report the problem related to running Moose tests from the command line: >>> >>> --- >>> You can reproduce it on Mac, quite consistently: just run the attached script (you need to have wget installed), or do it manually: >>> >>> 1. download and unzip the latest Moose 4.8: >>> https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastSuccessfulBuild/artifact/Moose-latest-dev-4.8.zip >>> 2. download and unzip the latest Pharo VM: >>> http://pharo.gforge.inria.fr/ci/vm/pharo/mac/pharo-mac-latest.zip >>> 3. execute: >>> ./Pharo.app/Contents/MacOS/Pharo ./Moose-latest-dev-4.8.image moosetest >>> >>> The VM crashes, but there is no trace of the error. >>> --- >>> >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "It's not what we do that matters most, it's how we do it." >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > |
Re: [Moose-dev] Re: where to report vm crashes? (while running Moose tests)
|
|
Aha. I will do that and use PharoVMLatest for the Moose builds. Like that we can provide feedback faster. Cheers, Doru On Wed, Mar 13, 2013 at 9:54 PM, Esteban Lorenzano <[hidden email]> wrote: Cool! "Every thing has its own flow"
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |