- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Failing Tests] Cleaned up failing test serialization

by Camillo Bruni

On 2013-02-16, at 14:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 16, 2013, at 2:30 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> >> >> On Sat, Feb 16, 2013 at 10:27 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> We should >>> >>> -> rename it "Fuel out stack" >>> -> set a post-dematerialization action >>> Because right now drag-and-drop does not lead to any result. >> >> >> >> that is strange.. since I remember Mariano added a post action >> that opens the debugger: >> >> >> But I think Marcus is talking about the button in the debugger, not the HDTestRunner sorry, right... if I were fully awake I'd have realized :D

Feb. 16, 2013

Re: [Pharo-project] Pharo vm builds restored

by Camillo Bruni

On 2013-02-16, at 14:30, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Well, this is the script from hell... > > newImage.sh doesn't executes the last line: > > # ---------------------------------------------------------------------------- > # try to open the image... > set -e > openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" > rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; > openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" > > > because openImage exits the script... > > Question: can't we run all of this headless? yes please ;) I guess I never fully tested it under unix/win and nobody really used it besides me. => run everything in headless mode => use the zeroconf scripts

Feb. 16, 2013

Re: [Pharo-project] Pharo vm builds restored

by Camillo Bruni

On 2013-02-16, at 14:25, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > I was looking in the image/ folder with the newImage.sh script as I > wanted to understand what was happening in there. > > So, this requires something like $PHAROVM to exist and be set to > something proper (added to my .profile) > Then, there is still ci.lille... in there, to be removed. > > Next, I wanted to make sense of the script itself. > > I commented out the part where the pregenerated image got downloaded > as I wanted to see things work from zero and not merely a prebuilt > image. > > So, I commented out the prebuilt part. > > # ---------------------------------------------------------------------------- > # echo -e "${YELLOW}LOADING PREBUILT IMAGE" $NO_COLOR > # echo " $PREBUILT_IMAGE_URL" > > # wget $WGET_CERTCHECK "$PREBUILT_IMAGE_URL" --output-document="image.zip" && \ > # unzip image.zip && \ > # rm image.zip && \ > # openImage "$PWD/generator.image" "$PWD/ImageConfiguration.st" && exit 1 > > And then, I got: > > [PhilMac:~/Documents/Smalltalk/2-MyWorkspaces/workspacePharoVMFebruary2013/buildarea/cog/image > philippeback$] ./newImage.sh > FETCHING FRESH IMAGE > https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Phar… > --2013-02-16 14:10:11-- > https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Phar… > > Which failed. > > The right URL is: > URL="https://ci.inria.fr/pharo/view/Pharo-1.4/job/Pharo-1.4/lastSuccessfulBuild/…" > > Also, it seems that the original contents of PharoVM do not contain > the .sources, and this generates a UI message one has to click, which > is annoying. > => use the urls from our file server and the new build scripts I didn't forgot to update the descriptions since we were out of builds for a while: #get a vm: wget http://files.pharo.org/script/ciPharoVM.sh bash ciPharoVM.sh #get an image: wget http://files.pharo.org/script/ciPharo14.sh bash ciPharo14.sh => to see what the scripts do run bash ciPharoVM.sh --help bash ciPharo14 --help => to run an image headlessly do ./vm.sh Pharo.image => you'll find a complete lists of images under http://files.pharo.org/image/14 I hope that helps?

Feb. 16, 2013

Re: [Pharo-project] [Failing Tests] Cleaned up failing test serialization

by Marcus Denker

On Feb 16, 2013, at 2:30 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sat, Feb 16, 2013 at 10:27 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > We should > > > > -> rename it "Fuel out stack" > > -> set a post-dematerialization action > > Because right now drag-and-drop does not lead to any result. > > > > that is strange.. since I remember Mariano added a post action > that opens the debugger: > > > But I think Marcus is talking about the button in the debugger, not the HDTestRunner yes! Marcus

Feb. 16, 2013

Re: [Pharo-project] Pharo vm builds restored

by phil＠highoctane.be

Well, this is the script from hell... newImage.sh doesn't executes the last line: # ---------------------------------------------------------------------------- # try to open the image... set -e openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" because openImage exits the script... Question: can't we run all of this headless? Phil 2013/2/16 Marcus Denker <marcus.denker(a)inria.fr>: > > On Feb 16, 2013, at 1:57 PM, Ben Coman <btc(a)openInWorld.com> wrote: > >> Marcus Denker wrote: >>> On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> >>>> Hi, >>>> >>>> Finally, with a lot of work, mana, power cards and jedi tricks, we made the pharo vm builds work again :) >>>> >>>> This builds are up-to-date with latest sources from Eliot's cog and adds pharo branding (AFAIK, this is the first time we are going to release something like that :) >>>> >>>> You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ >>>> >>>> >>> >>> Very good! >>> >>> So now we need to step by step.. >>> -> use the build in the one-click >>> -> link the VM zips on pharo-project.org >>> -> replace the VM we use for running jobs on jenkins with this. >>> >>> And of course: >>> -> test those builds on all three architectures automatically with a test image (e.g. current 2.0 with all failing tests removed) >>> The idea is that this image should not change frequently (the only variable is the VM) >>> >> Could the CI test new VMs against all previous "release" images eg Pharo 1.3, 1.4, 1.4 Summer, 2.0, 2.x >> or some subset, like the last release of each major version. While you may not want a very old release to fail a VM, at least the compatibility would be on record. > > One idea we had was to give up the "all VMs need to run all images", because this makes it very hard to moveâ¦ > > Marcus > > >

Feb. 16, 2013

Re: [Pharo-project] [Failing Tests] Cleaned up failing test serialization

by Mariano Martinez Peck

On Sat, Feb 16, 2013 at 10:27 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > We should > > > > -> rename it "Fuel out stack" > > -> set a post-dematerialization action > > Because right now drag-and-drop does not lead to any result. > > > > that is strange.. since I remember Mariano added a post action > that opens the debugger: > > But I think Marcus is talking about the button in the debugger, not the HDTestRunner > see HDTestReport>>#serializeTestFailureContext:toFileNamed: > ------------------------------------------------------------------- > ... > serializer addPostMaterializationAction: [:materialization | > Smalltalk tools debugger > openContext: materialization root > label: 'This is the new debugger!' > contents: nil > ]. > ... > ------------------------------------------------------------------- > so there must be something wrong with drag n'drop handler... > > -- Mariano http://marianopeck.wordpress.com

Feb. 16, 2013

Re: [Pharo-project] [Failing Tests] Cleaned up failing test serialization

by Camillo Bruni

> We should > > -> rename it "Fuel out stack" > -> set a post-dematerialization action > Because right now drag-and-drop does not lead to any result. that is strange.. since I remember Mariano added a post action that opens the debugger: see HDTestReport>>#serializeTestFailureContext:toFileNamed: ------------------------------------------------------------------- ... serializer addPostMaterializationAction: [:materialization | Smalltalk tools debugger openContext: materialization root label: 'This is the new debugger!' contents: nil ]. ... ------------------------------------------------------------------- so there must be something wrong with drag n'drop handler...

Feb. 16, 2013

Re: [Pharo-project] [Failing Tests] Cleaned up failing test serialization

by Mariano Martinez Peck

On Sat, Feb 16, 2013 at 10:16 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Feb 16, 2013, at 2:14 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > > > On 2013-02-16, at 14:11, Ben Coman <btc(a)openInWorld.com> wrote: > > > >> Marcus Denker wrote: > >>> Hi, > >>> > >>> To make it easy to explore why a test fails on the test server we > serialize the stack of falling tests. > >>> > >>> With two changes this has now gotten much easier: > >>> > >>> 1) Drag and Drop support for .fuel file > >>> Just drag the file to the Pharo Desktop --> Debugger opens > >>> > >> > >> Could you advise how to do this from an operational image (that is, not > a CI test image). I would like to use this to demonstrate Pharo's > outstanding development environment. A killer feature would be the > debugger having a <File out> button, that a user could use to mail to > support. Does any other programming system allow this ? > > > > > > you can just select "fileout / serialize stack" in the debugger > somewhere. > > The you get a local .fuel file with the serialized stack :) > > We should > > -> rename it "Fuel out stack" > +1 > -> set a post-dematerialization action > > Yes, you can copy it from the HDTestRunner that does exactly this :) > Because right now drag-and-drop does not lead to any result. > > Marcus > -- Mariano http://marianopeck.wordpress.com

Feb. 16, 2013

Re: [Pharo-project] Pharo vm builds restored

by phil＠highoctane.be

I was looking in the image/ folder with the newImage.sh script as I wanted to understand what was happening in there. So, this requires something like $PHAROVM to exist and be set to something proper (added to my .profile) Then, there is still ci.lille... in there, to be removed. Next, I wanted to make sense of the script itself. I commented out the part where the pregenerated image got downloaded as I wanted to see things work from zero and not merely a prebuilt image. So, I commented out the prebuilt part. # ---------------------------------------------------------------------------- # echo -e "${YELLOW}LOADING PREBUILT IMAGE" $NO_COLOR # echo " $PREBUILT_IMAGE_URL" # wget $WGET_CERTCHECK "$PREBUILT_IMAGE_URL" --output-document="image.zip" && \ # unzip image.zip && \ # rm image.zip && \ # openImage "$PWD/generator.image" "$PWD/ImageConfiguration.st" && exit 1 And then, I got: [PhilMac:~/Documents/Smalltalk/2-MyWorkspaces/workspacePharoVMFebruary2013/buildarea/cog/image philippeback$] ./newImage.sh FETCHING FRESH IMAGE https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Phar… --2013-02-16 14:10:11-- https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Phar… Which failed. The right URL is: URL="https://ci.inria.fr/pharo/view/Pharo-1.4/job/Pharo-1.4/lastSuccessfulBuild/…" Also, it seems that the original contents of PharoVM do not contain the .sources, and this generates a UI message one has to click, which is annoying. Phil 2013/2/16 Ben Coman <btc(a)openinworld.com>: > Marcus Denker wrote: >> >> On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> >>> >>> Hi, >>> >>> Finally, with a lot of work, mana, power cards and jedi tricks, we made >>> the pharo vm builds work again :) >>> >>> This builds are up-to-date with latest sources from Eliot's cog and adds >>> pharo branding (AFAIK, this is the first time we are going to release >>> something like that :) >>> >>> You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ >>> >>> >> >> >> Very good! >> >> So now we need to step by step.. >> -> use the build in the one-click >> -> link the VM zips on pharo-project.org >> -> replace the VM we use for running jobs on jenkins with this. >> >> And of course: >> -> test those builds on all three architectures automatically with >> a test image (e.g. current 2.0 with all failing tests removed) >> The idea is that this image should not change frequently (the >> only variable is the VM) >> > > Could the CI test new VMs against all previous "release" images eg Pharo > 1.3, 1.4, 1.4 Summer, 2.0, 2.x > or some subset, like the last release of each major version. While you may > not want a very old release to fail a VM, at least the compatibility would > be on record. > >> -> only when this is green the zip is updated in the archive >> >> > > >

Feb. 16, 2013

Re: [Pharo-project] [Failing Tests] Cleaned up failing test serialization

by Marcus Denker

On Feb 16, 2013, at 2:14 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-02-16, at 14:11, Ben Coman <btc(a)openInWorld.com> wrote: > >> Marcus Denker wrote: >>> Hi, >>> >>> To make it easy to explore why a test fails on the test server we serialize the stack of falling tests. >>> >>> With two changes this has now gotten much easier: >>> >>> 1) Drag and Drop support for .fuel file >>> Just drag the file to the Pharo Desktop --> Debugger opens >>> >> >> Could you advise how to do this from an operational image (that is, not a CI test image). I would like to use this to demonstrate Pharo's outstanding development environment. A killer feature would be the debugger having a <File out> button, that a user could use to mail to support. Does any other programming system allow this ? > > > you can just select "fileout / serialize stack" in the debugger somewhere. > The you get a local .fuel file with the serialized stack :) We should -> rename it "Fuel out stack" -> set a post-dematerialization action Because right now drag-and-drop does not lead to any result. Marcus

Feb. 16, 2013