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

Re: [Pharo-project] Fwd: Pharo and scaled decimals

by jannik laval

Hi, Should we already use the new tracker ? Is it possible to update the page: http://www.pharo-project.org/community/issue-tracking It redirect to the google code issue tracker. Jannik 2013/3/14 Marcus Denker <marcus.denker(a)inria.fr> > I added this as issue 10016 to the new tracker. > > Begin forwarded message: > > *From: *David Gorisek <david.gorisek(a)e-racuni.com> > *Subject: **Re: Pharo and scaled decimals* > >> >> Hello all, >> >> I am testing Pharo and I have noticed that the Pharo compiler does not >> treat ScaledDecimals the same way they are treated in other Smalltalk >> dialects (e.g. VW, VAST, Dolphin, STX, etc.). >> >> For example the following is a valid code representing an instance of >> ScaledDecimal/FixedPoint in all other dialect. >> >> 1.0s + 2.0s >> >> In Phare the code above wont compile, it has to be written as: >> >> 1.0s1 + 2.0s1 >> >> So I have made the following quick change to make Pharo compatible with >> other Smalltalk dialects. Maybe this change could be included in the next >> version of Pharo? >> >> SqNumberParser>>#readScale >> "read the scale if any (stored in instVar). >> Answer true if found, answer false if none. >> If scale letter is not followed by a digit, this is not considered as >> an error. >> Scales are always read in base 10, though i do not see why..." >> >> scale := 0. >> sourceStream atEnd >> ifTrue: [ ^ false ]. >> (sourceStream peekFor: $s) >> ifFalse: [ ^ false ]. >> scale := self nextUnsignedIntegerOrNilBase: 10. >> scale >> ifNil: [ >> scale := 0. >> (sourceStream peek ifNil: [false] ifNotNil: [ :nextChar | >> nextChar isLetter]) >> ifTrue: [ >> sourceStream skip: -1. "ungobble the s" >> ^ false ] >> ifFalse: [ ^ true ] ]. >> ^ true >> >> >> >> >> >> > > -- ~~Dr. Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu

March 14, 2013

[Pharo-project] Fwd: Pharo and scaled decimals

by Marcus Denker

I added this as issue 10016 to the new tracker. Begin forwarded message: > From: David Gorisek <david.gorisek(a)e-racuni.com> > Subject: Re: Pharo and scaled decimals >> >> Hello all, >> >> I am testing Pharo and I have noticed that the Pharo compiler does not treat ScaledDecimals the same way they are treated in other Smalltalk dialects (e.g. VW, VAST, Dolphin, STX, etc.). >> >> For example the following is a valid code representing an instance of ScaledDecimal/FixedPoint in all other dialect. >> >> 1.0s + 2.0s >> >> In Phare the code above wont compile, it has to be written as: >> >> 1.0s1 + 2.0s1 >> >> So I have made the following quick change to make Pharo compatible with other Smalltalk dialects. Maybe this change could be included in the next version of Pharo? >> >> SqNumberParser>>#readScale >> "read the scale if any (stored in instVar). >> Answer true if found, answer false if none. >> If scale letter is not followed by a digit, this is not considered as an error. >> Scales are always read in base 10, though i do not see why..." >> >> scale := 0. >> sourceStream atEnd >> ifTrue: [ ^ false ]. >> (sourceStream peekFor: $s) >> ifFalse: [ ^ false ]. >> scale := self nextUnsignedIntegerOrNilBase: 10. >> scale >> ifNil: [ >> scale := 0. >> (sourceStream peek ifNil: [false] ifNotNil: [ :nextChar | nextChar isLetter]) >> ifTrue: [ >> sourceStream skip: -1. "ungobble the s" >> ^ false ] >> ifFalse: [ ^ true ] ]. >> ^ true >> >> >> >> > >

March 14, 2013

Re: [Pharo-project] rpackage transition

by Igor Stasenko

On 14 March 2013 08:00, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > When we started with RPackage there was a debate as to the strategy regarding the mapping. I advocated 1-to-1 mapping of categories to RPackage, and it seems this is what we now have. > > The detailed plan looked as follow: > > --- > Stage 1: Get RPackage in the image and pretend that it acts like a smart cache for categories. Everything is expressed in terms of categories and mirrored in RPackages. Tools can now be built on top of RPackage. At this stage, no modification is needed and the new tools will work next to the old ones. > > Stage 2: Leave the logic of Monticello loading as it is now (n-to-1 Categoeies-to-MonticelloPackage), but modify Monticello publishing to rely on 1-to-1 RPackage-to-MonticelloPackage. This will basically force people to start changing the configurations. > .. and rewriting a working code. Why i cannot have 1 package with 2 categories 'Foo-Core' and 'Foo-Core-Bar'? Why we need such requirement? why developer cannot choose what categories going into package? Now i will be forced to fold all classes back into single category if i want to not end up with 20 little packages (which cannot be loaded, btw , because of dependency ..) To reflect, how bad it sounds to me, let me propose different publishing order: - all classes with same first two letters in name should go to same package. Do you like it? No? Not matters.. we will force you to obey to it, starting from tomorrow. > Stage 3: Change the Monticello loading to only allow 1-to-1 RPackage-to-MonticelloPackage. At this point, we can safely remove the Categories. > --- > > Now we passed Stage 1 which is great. At this point, everyone can work like before, but are encouraged to create explicit Monticello packages out of categories. Next, I would like to propose that for Pharo 3.0 we go for Stage 2 and modify slightly Monticello publishing. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Quality cannot be an afterthought." > > -- Best regards, Igor Stasenko.

March 14, 2013

Re: [Pharo-project] WhatsUp from: 2013-03-11 until: 2013-03-24

by stephane ducasse

Alex did you get a real look on the profiler of Andreas? Did it help? I would like to understand when it is really better? Stef On Mar 13, 2013, at 3:26 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! > > Cool idea! > >> ### Here's what I've been up to since the last WhatsUp: >> >> - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS > > - Fixing many bugs in Roassal > - Writing the chapter on Roassal > - Working on the Loom thread profiler > >> ### What's next, until 2013-03-24 (*): >> >> - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION > > - Reviewing the ZeroConf chapter > - Working on the Rizel profiler > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

March 14, 2013

[Pharo-project] rpackage transition

by Tudor Girba

Hi, When we started with RPackage there was a debate as to the strategy regarding the mapping. I advocated 1-to-1 mapping of categories to RPackage, and it seems this is what we now have. The detailed plan looked as follow: --- Stage 1: Get RPackage in the image and pretend that it acts like a smart cache for categories. Everything is expressed in terms of categories and mirrored in RPackages. Tools can now be built on top of RPackage. At this stage, no modification is needed and the new tools will work next to the old ones. Stage 2: Leave the logic of Monticello loading as it is now (n-to-1 Categoeies-to-MonticelloPackage), but modify Monticello publishing to rely on 1-to-1 RPackage-to-MonticelloPackage. This will basically force people to start changing the configurations. Stage 3: Change the Monticello loading to only allow 1-to-1 RPackage-to-MonticelloPackage. At this point, we can safely remove the Categories. --- Now we passed Stage 1 which is great. At this point, everyone can work like before, but are encouraged to create explicit Monticello packages out of categories. Next, I would like to propose that for Pharo 3.0 we go for Stage 2 and modify slightly Monticello publishing. Cheers, Doru -- www.tudorgirba.com "Quality cannot be an afterthought."

March 14, 2013

Re: [Pharo-project] [Moose-dev] Re: where to report vm crashes? (while running Moose tests)

by Tudor Girba

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 <estebanlm(a)gmail.com>wrote: > 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 <tudor(a)tudorgirba.com> 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 <estebanlm(a)gmail.com> > 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-buil… > >> > https://ci.inria.fr/pharo/view/VM/job/PharoVM/Architecture=32,Slave=vm-buil… > >> > >> cheers, > >> Esteban > >> > >> > >> On Mar 12, 2013, at 9:22 AM, Tudor Girba <tudor(a)tudorgirba.com> 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 <usman.bhatti(a)gmail.com> > 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 <tudor(a)tudorgirba.com> > 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/arti… > >>> 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 > >>> Moose-dev(a)iam.unibe.ch > >>> 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." > > > > > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 14, 2013

Re: [Pharo-project] working moose build

by Tudor Girba

Hi, The idea is to eliminate Mondrian altogether, but as long as it is part of Moose, its tests are important, so they will remain in the build. But, in the meantime, I found the reason why the PetitSmalltalk tests were not ran, and I fixed the problem (we are now running 3350 tests and have 19 failures): https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastCompletedBuild/testR… The issue was that I only considered the packages that are mentioned in the configuration. However, the Monticello PetitSmalltalk package contains two sub-categories and this resulted in 3 RPackages (one for the root category, and two for the children), and thus, triggering the tests only from the root did not work. Cheers, Doru On Mar 13, 2013, at 12:12 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > 11 failures (-17) > https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastCompletedBuild/testR… > > :-) > > Doru, if Mondrian tests are not really important, we can exclude it from the build report? > And may be include petit-parser tests in the report or we can create a different job for it? > > usman > > > On Tue, Mar 12, 2013 at 10:29 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > The Moose build including running tests now works based on the NBCog VM and the latest Pharo 2.0 (built on Ubuntu): > https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastCompletedBuild/testR… > > There are 27 test failures. > > I also tried on OS X using NBCog VM and the there is no crash. This scenario was also confirmed by Stephan although he reported more failures. > > For reference, we are using the following script on Jenkins: > > wget --quiet -qO - http://pharo.gforge.inria.fr/ci/script/ciPharo20NBCogVM.sh | bash > wget http://pharo.gforge.inria.fr/ci/image/PharoV20.sources > ./vm.sh Pharo.image save $JOB_NAME > REPO=http://smalltalkhub.com/mc/Moose/Moose/main > ./vm.sh $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development > ./vm.sh $JOB_NAME.image moosetest --junit-xml-output > zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources > > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "From an abstract enough point of view, any two things are similar." > > > > > -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

March 14, 2013

Re: [Pharo-project] [Pharo-users] [squeak-dev] GSoC13: Google Summer of Code started, your ideas please!

by Guillermo Polito

And another one: Level: intermediate Possible mentor: Santiago Bragagnolo Possible second mentor: Guillermo Polito Description: Gamification is becoming more and more popular in a lot of applications. What about gamify the pharo development process? You get points by adding comments, fixing bugs or answering questions. You can be a comment healer, a bug slayer, a Zinc magician. The intend of this project is to build an application that integrates with the Pharo development process tools (issue tracker, smalltalkhub, stack overflow) and provides a gamified experience, so we get more and more motivated to code. Technical Details: This project implies the creation of an application which communicates with different applications APIs and perform some analysis on them such as running source code Lint rules. Additionally, this application should have a web frontend. Benefits to the Student - Use a highly reflective dynamic language - Learn to develop a complex application architecture with several communicating components - Learn about ramification concepts - Learn about an open source project development and integration process, such as Pharo - Learn web application development techniques Benefits to the Community - have a platform to organize activities and events around the Pharo development - be more motivated to participate into the development for rewards such as experience, badges and abilities On Wed, Mar 13, 2013 at 4:40 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi Janko! > > We have this: > > Level: intermediate > Possible mentor: Guillermo Polito > > Possible second mentor: Esteban Lorenzano > > Description: DBXTalk database driver nowadays uses a native library > called OpenDBX. This library stands as an adaptor between different > database drivers, implemented in C. This native library supposes many > problems: > - it should be normally compiled for each different platform (Windows, > *nix, macosx) and database vendor > - each of its bugs should be fixed in a C source code base > - OpenDBX do not expose the particular behavior of each database vendor, > but their common denominator > - difficulty for distribution, and problems to locate libraries. > This project proposes to use NativeBoost bindings to remove the > necessity of the native openDBX library, simplifying the deployment of > applications using relational databases, and moving all the code base to > Smalltalk. > > Technical Details: This project supposes the replacement of openDBX old > FFI bindings by direct nativeBoost bindings to the database drivers. The > new drivers should be completely written in Smalltalk, and take care of > platform and library resolution in the image side. These drivers should be > polymorphic while also enabling the access to specific API provided by > database vendors. > > Benefits to the Student > - Use a highly reflective dynamic language > - Learn the basics of foreign function interface (and its exponent > NativeBoost) > - Learn how to manage external resources and platform specific native > code > - Put into usage its object design skills to transform a structured > designed library into an object oriented one > > Benefits to the Community > - A more malleable and full smalltalk implementation of relational > database drivers > - Easier deploy for applications using relational databases > - Database divers exposing their particular apis, providing access to > features not available before > > Guille > > On Sat, Mar 9, 2013 at 2:16 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si>wrote: > >> Hi Stef, >> >> Post on the mailing list for each project idea by following this template: >> >> Level: (beginner, intermediate, advanced) >> >> Possible mentor: >> >> Possible second mentor: >> >> Description >> >> Technical Details >> >> Benefits to the Student >> >> Benefits to the Community >> >> Best regards >> Janko >> >> Dne 09. 03. 2013 13:46, piÅ¡e stephane ducasse: >> > Hi janko >> > >> > How do you want to proceed for the topics? >> > I have a list of topics now where do we write them. >> > >> > - tool support rewrite rules >> > - new generation debugger >> > - new change model and session manager (with martin dias) >> > - improving roassal (with alexandre bergel et vanessa pena) >> > - improving eyesee (with alexandre bergel et vanessa pena) >> > - support touch event >> > - UIPainter (with esteban lorenzano) >> > - New widgets >> > >> > >> > Stef >> > >> > >> >> Dear Smalltalkers, >> >> >> >> Time for your cool project ideas on this year Smalltalk GSoC! >> >> >> >> For now just express any idea you have here on the mailing list. Later >> >> we will together develop it to be in complete format together with two >> >> mentors needed. Deadline is end of Mart, so we have three weeks of >> time. >> >> To see how fully developed ideas look like please look at 2012 ones at: >> >> http://gsoc2012.esug.org/ideas. >> >> >> >> Note also that students yourselves can propose a GSoC project. So if >> you >> >> like to be a student on this year GSoC and have a nice idea, don't be >> >> shy and propose it here! The community will listen you and guide to the >> >> really nicely proposed project. Last year 6 student proposed projects >> >> were accepted and finished successfully! >> >> >> >> For the community, start looking around for students. Think about how >> to >> >> approach the universities near by you, do you know who to contact >> >> there, etc. >> >> >> >> We are namely preparing an application to this year Smalltalk Google >> >> Summer of Code under ESUG umbrella, as last year. If accepted, Google >> >> will pay few stipendiums to students on our Smalltalk projects. >> >> >> >> More on our special Smalltalk GSoC 2013 website: >> >> >> >> http://gsoc2013.esug.org >> >> >> >> I'm specially inviting mentors of all past GSoCs to rejoin the mentors >> >> mailing list, where we discuss all details about this year GSoC: >> >> >> >> http://groups.google.com/group/smalltalk-gsoc-mentors >> >> >> >> While students interested on GSoC please join a special Smalltalk GSoC >> >> mailing list for you: >> >> >> >> http://groups.google.com/group/smalltalk-gsoc-students >> >> >> >> Best regards >> >> Janko >> >> >> >> >> >> -- >> >> Janko MivÅ¡ek >> >> Aida/Web >> >> Smalltalk Web Application Server >> >> http://www.aidaweb.si >> >> >> > >> > >> > >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> >> >

March 13, 2013

Re: [Pharo-project] [Moose-dev] Re: where to report vm crashes? (while running Moose tests)

by Esteban Lorenzano

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 <tudor(a)tudorgirba.com> 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 <estebanlm(a)gmail.com> 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-buil… >> https://ci.inria.fr/pharo/view/VM/job/PharoVM/Architecture=32,Slave=vm-buil… >> >> cheers, >> Esteban >> >> >> On Mar 12, 2013, at 9:22 AM, Tudor Girba <tudor(a)tudorgirba.com> 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 <usman.bhatti(a)gmail.com> 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 <tudor(a)tudorgirba.com> 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/arti… >>> 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 >>> Moose-dev(a)iam.unibe.ch >>> 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." > > > >

March 13, 2013

Re: [Pharo-project] [Moose-dev] Re: where to report vm crashes? (while running Moose tests)

by Tudor Girba

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 <estebanlm(a)gmail.com> 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-buil… > https://ci.inria.fr/pharo/view/VM/job/PharoVM/Architecture=32,Slave=vm-buil… > > cheers, > Esteban > > > On Mar 12, 2013, at 9:22 AM, Tudor Girba <tudor(a)tudorgirba.com> 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 <usman.bhatti(a)gmail.com> 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 <tudor(a)tudorgirba.com> 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/arti… >> 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 >> Moose-dev(a)iam.unibe.ch >> 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."

March 13, 2013