April 2014 - Pharo-dev - lists.pharo.org

Error adding a Class instVar

by Esteban A. Maringolo

I was adding a Class instance variable when I got this, admittedly, funny error. Any clues of why? The class has a Trait (which I plan to remove). Maybe that is causing this? â Esteban A. Maringolo

April 25, 2014

Re: [Pharo-dev] CPU usage change on newer OS

by Esteban A. Maringolo

What % of CPU is it using? My VM on idle state consumes about ~4-5% CPU. Esteban A. Maringolo 2014-04-24 15:43 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > I have a strange effect on my machines. I have a dedicated server and a lot of virtual instances using LXC. The last few days I migrated most projects of our projects from pharo2.0 to pharo3.0. And on the same time the images moved from an ubuntu 12.04. system to a ubuntu 14.04 system. Looking at the top command it appears the images/vms need noticable less CPU or better the tools report less. The monitored overall CPU usage also is much lesser than before. > > This is not proved by any measurement. Has anyone an idea why this could happen or appear differently? > > Norbert >

April 24, 2014

Modifications to be integrated in Pharo 3.0 VM

by Nicolas Cellier

I think this fix is essential and should be applied before releasing Pharo VM: https://github.com/pharo-project/pharo-vm/pull/31 Those are optionals but would be nice to have: https://github.com/pharo-project/pharo-vm/pull/32 https://github.com/pharo-project/pharo-vm/pull/33 https://github.com/pharo-project/pharo-vm/pull/34 https://github.com/pharo-project/pharo-vm/pull/42 Those can wait but are ready and not dangerous IMO: https://github.com/pharo-project/pharo-vm/pull/37 https://github.com/pharo-project/pharo-vm/pull/39 https://github.com/pharo-project/pharo-vm/pull/40 This one works perfectly for me but failed on the CI server I really wonder why... https://github.com/pharo-project/pharo-vm/pull/41 This one would be nice to have too but does not fully work on my mac. I really fail to understand why... The exact same code in Cog branch works perfectly with same compiler (slightly different options maybe?) I'd be curious to know if all Kernel-Number tests pass when compiled by someone else. https://github.com/pharo-project/pharo-vm/pull/35 And last, the compiler flags should be fixed on MacOSX for bug https://pharo.fogbugz.com/f/cases/11130 Or clang replaced by an older gcc...

April 24, 2014

Re: [Pharo-dev] Pharo crashes

by Nicolas Cellier

2014-04-24 22:43 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 24 Apr 2014, at 22:13, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2014-04-24 20:44 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Again, cc'ing vm-dev is courteous. >> >> >> On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel <camille.teruel(a)gmail.com >> > wrote: >> >>> Segfault!!!!! >>> >>> Could it be due to #become: or #valueUnpreemptively ? (see >>> PharoClassInstaller>>migrateClasses:to:using:) >>> >> >> I suspect the become. Thats the last primitive. I suspect it's >> something to do with become on machine code. I suspect some of my recent >> changes have not been integrated. e.g. VMMaker.oscog-eem.669. >> > > > Hi Eliot, > no, it is way behind ! > The https://github.com/pharo-project/pharo-vm/ master head is marked as > merged with VMMaker.oscog-eem.333 though the merge is very partial. > There are also some changes that have been picked from further MC > versions, quite randomly IMO (most are related to the Spur VM and are of no > value for COG!), but the MC versions are not marked as merged this time. > As for the platform sources, I have no idea what/when was the last merge > with your svn branch... > > As I already ranted about, there have been a lot of cosmetic changes (like > reformatting some methods) which now are a drag causing many conflicts at > each MC merge operation... > I've cancelled most of these in my > https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch > just to see a bit clearer. > It could be a better start for integrating your changes. > But synchronizing the svn changes with the MC changes is not that easy; > doing it manually is error prone, it should be automated. > For this reason, the all-in-one git repo is superior IMO, despite the > small MC-git complications. > > I think the fastest strategy for catching up with Spur would be to > re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather > than the opposite, but I'm not the maintainer. > Igor, Esteban and co may have a different idea about it. > > > no, I was thinking more or less the sameâ¦ but still did not looked at it > deeply :) > > btwâ¦ I do not know which randomly picked changes you are talking about. I > certainly stopped doing integrations when Eliot started to commit spur > stuff, to wait until is more or less ready (bah, with Clement we tried once > and it was not worthy, so we rolled back). > thenâ¦ other stuff: I also donât know about random methods reformatted. I > know I reformatted some, but those I worked on (usually not in VMMaker, > with minor exceptions). Of course, Iâm not the only one working on those > sources, but I certainly did many changes with the years. > > It's easy for me to say, because I did the job of tracing the differences when tracking bug https://pharo.fogbugz.com/f/cases/11130 And since git is a super tool, all is publicly traced. So here is the major source of cosmetic changes: the scripts for applying the transformation (self var: #foo ...) -> <var: #foo type: ... > have been applied separately in pharo branch, but with a different layout (space after :) like Dave did in interpreter VM, but unlike Eliot did in .oscog branch if I remember correctly. Then a few other formatting have been done manually. Normally after a merge they are not shown... But since the last merge wirth 333 was partial, we can't use merge from MC, we are forced to use changes that show all the diffs, otherwise we'll miss some of the changes not merged in further merges. Thoses changes can be cancelled by re-applying Eliot's version. You can check on my branch UndoBlankChanges https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/7ee237a851f2470… As for the random changes, they are all marked LucFabresse (I think an effect of older gitfiletree). I don't think they are really random: it's more like an aborted merge that was partially reverted. So logically, the things that were not reverted were harmless (the Spur related things). There was certainly a good reason for wanting to merge (like work on simulator maybe) And reverting was probably a good decision at that time because Spur introduction was wausing some Cog regressions. My point is not to denigrate Luc's or Esteban's work, maintaining a parallel branch is complex enough! But when you are searching for a specific bug like those differences appear as random and are parasiting... And when it's time to cancel the debt toward Eliot's branch, that can be disturbing : those methods conflict because of author and time stamp, as I said probably a former gitfiletree bug... You can check the changes in my branch revertLucFabresseAheadChanges https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/847c254168d0b24… Looking at history, the merge was with Eliot's 406: https://github.com/nicolas-cellier-aka-nice/pharo-vm/commits/a05cda7fb80d89… The last thing I did was to apply Eliot's changes that were not applied in last merge with 333. This is in fixMergeWithEliotVersion333. In fact, it's better to merge with 334, because 333 had some snafu... https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/8d97c34571adc30… ancestors... ------ But as I said, I would rather throw all that work away and proceed differently, starting from Spur and merging pharo-vm. So what are these changes? There are all the changes related to making VMMaker work in pharo. Pharo API is diverging a bit from squeak over time, especially for the simulator (graphics/forms) and the generator part (file system). IMO, the best would be for squeak to catch up file system changes, but it's only an opinion... For most of the rest, we could arrange to cooperate and integrate some changes for Pharo support / or just add a compatibility package in Pharo branch. Then there are the really essential changes: ephemerons (might be superseded by Spur?) and NB. These are relatively well delimited and should not be a major problem to integrate back. Then the changes of platform files... Most of them should be integrated back in Eliot's svn branch, but they are behind for now. Last, all the CMakeVMMaker work is huge but well separated for now - until tty integrate them back :) and PharoVMMaker, well, is for the pharo configuration obviously. I probably forgotten a few, but IMO, it's not a huge work this way around. > Finally: ok, vm shouldnât crashâ¦ but this bug was not vm related but a bad > integration (in the new class builder) we rollbacked. Thatâs why it was not > copied to vm-dev :) > > cheers, > Esteban > > Yes, since it's in the replacement for ClassBuilder, a danger zone... Maybe something like executing a method not correctly recompiled, while the receiver layout has changed? or vice versa... > > > >> -- >> best, >> Eliot >> > > >

April 24, 2014

Re: [Pharo-dev] What is forum (was Re: Pharo Crashes)

by Stephan Eggermont

Torsten wrote: >> FYI: Forum is available in the config browser. > >But does not load out of the box. Dependency to Glamour seems to >be missing. Forum uses quite a number of large packages that use different Metacello strategies. Stable loads 167 packages. I tend to just download from ci. If you just ignore the warnings and proceed, you get a usable image, with either stable or bleedingEdge. FOTutorial open FOBrowser open You are right that there is a configuration issue, as there are now two versions of neo-csv, grease and seaside loaded. Iâll check it out. Stephan

April 24, 2014

Re: [Pharo-dev] [Vm-dev] Linux Numeric Keyboard issue in Pharo-VM fix

by Eliot Miranda

Thanks Phil! On Thu, Apr 24, 2014 at 2:16 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > > Hello, > > As I am now working on a CentOS sytem with Pharo, I got into: > > https://pharo.fogbugz.com/default.asp?11352 > > So, I put back the fix that was done in Gitorious #2e6f231 and it now > works. > > May someone integrate that fix into the main Linux repo? > It's integrated into the Cog branch now at least. -- best, Eliot

April 24, 2014

Re: [Pharo-dev] Pharo crashes

by Eliot Miranda

On Thu, Apr 24, 2014 at 1:43 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > > On 24 Apr 2014, at 22:13, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2014-04-24 20:44 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Again, cc'ing vm-dev is courteous. >> >> >> On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel <camille.teruel(a)gmail.com >> > wrote: >> >>> Segfault!!!!! >>> >>> Could it be due to #become: or #valueUnpreemptively ? (see >>> PharoClassInstaller>>migrateClasses:to:using:) >>> >> >> I suspect the become. Thats the last primitive. I suspect it's >> something to do with become on machine code. I suspect some of my recent >> changes have not been integrated. e.g. VMMaker.oscog-eem.669. >> > > > Hi Eliot, > no, it is way behind ! > The https://github.com/pharo-project/pharo-vm/ master head is marked as > merged with VMMaker.oscog-eem.333 though the merge is very partial. > There are also some changes that have been picked from further MC > versions, quite randomly IMO (most are related to the Spur VM and are of no > value for COG!), but the MC versions are not marked as merged this time. > As for the platform sources, I have no idea what/when was the last merge > with your svn branch... > > As I already ranted about, there have been a lot of cosmetic changes (like > reformatting some methods) which now are a drag causing many conflicts at > each MC merge operation... > I've cancelled most of these in my > https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch > just to see a bit clearer. > It could be a better start for integrating your changes. > But synchronizing the svn changes with the MC changes is not that easy; > doing it manually is error prone, it should be automated. > For this reason, the all-in-one git repo is superior IMO, despite the > small MC-git complications. > > I think the fastest strategy for catching up with Spur would be to > re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather > than the opposite, but I'm not the maintainer. > Igor, Esteban and co may have a different idea about it. > > > no, I was thinking more or less the sameâ¦ but still did not looked at it > deeply :) > > btwâ¦ I do not know which randomly picked changes you are talking about. I > certainly stopped doing integrations when Eliot started to commit spur > stuff, to wait until is more or less ready (bah, with Clement we tried once > and it was not worthy, so we rolled back). > thenâ¦ other stuff: I also donât know about random methods reformatted. I > know I reformatted some, but those I worked on (usually not in VMMaker, > with minor exceptions). Of course, Iâm not the only one working on those > sources, but I certainly did many changes with the years. > > Finally: ok, vm shouldnât crashâ¦ but this bug was not vm related but a bad > integration (in the new class builder) we rollbacked. Thatâs why it was not > copied to vm-dev :) > At last for the core VM classes (ignore plugins) I wish you would integrate by integrating your ephemeron and NativeBoost changes into my tip. I think you're losing a lot of goodness coming form the continuous integration and testing my colleague Bob Westergaard does at Cadence. It worries me that the Pharo VM is buggy. I don't think it needs to be. And please don't take this as a criticism. It's more my anxiety. > cheers, > Esteban > cheers! > > > > >> -- >> best, >> Eliot >> > > > -- best, Eliot

April 24, 2014

Linux Numeric Keyboard issue in Pharo-VM fix

by phil＠highoctane.be

Hello, As I am now working on a CentOS sytem with Pharo, I got into: https://pharo.fogbugz.com/default.asp?11352 So, I put back the fix that was done in Gitorious #2e6f231 and it now works. May someone integrate that fix into the main Linux repo? Thx Phil

April 24, 2014

Re: [Pharo-dev] Pharo crashes

by Esteban Lorenzano

On 24 Apr 2014, at 22:13, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 2014-04-24 20:44 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Again, cc'ing vm-dev is courteous. > > > On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > Segfault!!!!! > > Could it be due to #become: or #valueUnpreemptively ? (see PharoClassInstaller>>migrateClasses:to:using:) > > I suspect the become. Thats the last primitive. I suspect it's something to do with become on machine code. I suspect some of my recent changes have not been integrated. e.g. VMMaker.oscog-eem.669. > > > Hi Eliot, > no, it is way behind ! > The https://github.com/pharo-project/pharo-vm/ master head is marked as merged with VMMaker.oscog-eem.333 though the merge is very partial. > There are also some changes that have been picked from further MC versions, quite randomly IMO (most are related to the Spur VM and are of no value for COG!), but the MC versions are not marked as merged this time. > As for the platform sources, I have no idea what/when was the last merge with your svn branch... > > As I already ranted about, there have been a lot of cosmetic changes (like reformatting some methods) which now are a drag causing many conflicts at each MC merge operation... > I've cancelled most of these in my https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch just to see a bit clearer. > It could be a better start for integrating your changes. > But synchronizing the svn changes with the MC changes is not that easy; doing it manually is error prone, it should be automated. > For this reason, the all-in-one git repo is superior IMO, despite the small MC-git complications. > > I think the fastest strategy for catching up with Spur would be to re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather than the opposite, but I'm not the maintainer. > Igor, Esteban and co may have a different idea about it. no, I was thinking more or less the sameâ¦ but still did not looked at it deeply :) btwâ¦ I do not know which randomly picked changes you are talking about. I certainly stopped doing integrations when Eliot started to commit spur stuff, to wait until is more or less ready (bah, with Clement we tried once and it was not worthy, so we rolled back). thenâ¦ other stuff: I also donât know about random methods reformatted. I know I reformatted some, but those I worked on (usually not in VMMaker, with minor exceptions). Of course, Iâm not the only one working on those sources, but I certainly did many changes with the years. Finally: ok, vm shouldnât crashâ¦ but this bug was not vm related but a bad integration (in the new class builder) we rollbacked. Thatâs why it was not copied to vm-dev :) cheers, Esteban > > > > > -- > best, > Eliot >

April 24, 2014

Re: [Pharo-dev] Pharo crashes

by Nicolas Cellier

2014-04-24 20:44 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Again, cc'ing vm-dev is courteous. > > > On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel <camille.teruel(a)gmail.com>wrote: > >> Segfault!!!!! >> >> Could it be due to #become: or #valueUnpreemptively ? (see >> PharoClassInstaller>>migrateClasses:to:using:) >> > > I suspect the become. Thats the last primitive. I suspect it's something > to do with become on machine code. I suspect some of my recent changes > have not been integrated. e.g. VMMaker.oscog-eem.669. > Hi Eliot, no, it is way behind ! The https://github.com/pharo-project/pharo-vm/ master head is marked as merged with VMMaker.oscog-eem.333 though the merge is very partial. There are also some changes that have been picked from further MC versions, quite randomly IMO (most are related to the Spur VM and are of no value for COG!), but the MC versions are not marked as merged this time. As for the platform sources, I have no idea what/when was the last merge with your svn branch... As I already ranted about, there have been a lot of cosmetic changes (like reformatting some methods) which now are a drag causing many conflicts at each MC merge operation... I've cancelled most of these in my https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch just to see a bit clearer. It could be a better start for integrating your changes. But synchronizing the svn changes with the MC changes is not that easy; doing it manually is error prone, it should be automated. For this reason, the all-in-one git repo is superior IMO, despite the small MC-git complications. I think the fastest strategy for catching up with Spur would be to re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather than the opposite, but I'm not the maintainer. Igor, Esteban and co may have a different idea about it. > -- > best, > Eliot >

April 24, 2014