- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Error adding a Class instVar

by Camille Teruel

On 25 avr. 2014, at 09:13, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 25 Apr 2014, at 04:33, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> 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? > > This is this problem: > > https://pharo.fogbugz.com/f/cases/13028/Adding-ClassVariables-corrupts-clas… No I don't think so, 13028 is the subclass cache problem whereas Esteban's problem seems to be related to wrong slot scope problem. Esteban, is it the latest image? Can run this script in your image and tell us the content of toRebuild? all := Smalltalk allClasses flatCollect: [ :e | { e . e class } ]. candidates := all reject: [ :e | e superclass isNil or: [e layout slotScope isKindOf: LayoutEmptyScope ] ]. toRebuild := candidates reject: [ :e | e superclass layout slotScope == e layout slotScope parentScope ]. Does toRebuild contains your class or one class of its hierarchy? > >

April 25, 2014

Re: [Pharo-dev] Error adding a Class instVar

by Marcus Denker

On 25 Apr 2014, at 04:33, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 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? This is this problem: https://pharo.fogbugz.com/f/cases/13028/Adding-ClassVariables-corrupts-clas…

April 25, 2014

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

by Norbert Hartl

> Am 25.04.2014 um 01:19 schrieb "Esteban A. Maringolo" <emaringolo(a)gmail.com>: > > What % of CPU is it using? > On the old instance it is a stable 2% and on the new it is 1-1,3 %. That was the reason making me looking at it. I was so used to the 2 % I spotted the difference immediately. Norbert > 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 25, 2014

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

by Sven Van Caekenberghe

On 25 Apr 2014, at 01:19, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > What % of CPU is it using? > > My VM on idle state consumes about ~4-5% CPU. That is about what I am used to, here is a real view of an Amazon AWS EC2 Small Instance running 4 Pharo VMs: top - 05:25:09 up 413 days, 15:27, 1 user, load average: 0.88, 0.66, 0.49 Tasks: 73 total, 3 running, 70 sleeping, 0 stopped, 0 zombie Cpu(s): 0.6%us, 0.4%sy, 0.0%ni, 96.3%id, 0.2%wa, 0.0%hi, 0.0%si, 2.5%st Mem: 1706660k total, 1654928k used, 51732k free, 136692k buffers Swap: 0k total, 0k used, 0k free, 1006556k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31639 ubuntu 20 0 1030m 99m 1444 R 4.0 5.9 61:47.82 pharo 4314 ubuntu 20 0 1030m 162m 1504 S 2.0 9.7 140:28.55 pharo 8014 ubuntu 20 0 1030m 77m 1512 S 2.0 4.6 561:06.30 pharo 31647 ubuntu 20 0 1030m 92m 1444 R 2.0 5.6 63:31.80 pharo 1 root 20 0 3540 1392 732 S 0.0 0.1 0:58.61 init Sven > 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 25, 2014

Re: [Pharo-dev] Debugging in Production Servers

by Ben Coman

April 25, 2014

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 25, 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 25, 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