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

Re: [Pharo-project] problem: nautilus forked moose-algos

by Tudor Girba

Hi, I saw that you removed the problematic parts, but now CofigurationOfNautilus throws a loading error, because MonticelloAnnouncer is not present when NautilusMCBindings gets loaded. Could you take a look? Cheers, Doru On 3 Mar 2012, at 23:42, Benjamin wrote: > I will remove that and push it into another repo. > > It was a plugin started by Jannik, but never finished :) > > Thanks for report :) > > Ben > > On Mar 3, 2012, at 9:41 PM, Tudor Girba wrote: > >> Hi, >> >> Nautilus includes NautilusCommon and this in turn includes NautilusCommon-Plugin-JannikAlgo which copies verbatim a part of the classes from the Moose-Algos-Graph package from http://www.squeaksource.com/MooseAlgos. >> >> These classes are used in a plugin. Because of this, we cannot use Nautilus in Moose. >> >> So, I would suggest one of these: >> - remove the plugin, at least from the default configuration >> - load Moose-Algos-Graph properly >> - fork with a different name >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Yesterday is a fact. >> Tomorrow is a possibility. >> Today is a challenge." >> >> >> >> > > -- www.tudorgirba.com "Obvious things are difficult to teach."

March 4, 2012

Re: [Pharo-project] Pharo Kernel break...

by Pavel Krivanek

On Sun, Mar 4, 2012 at 11:27 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Mar 4, 2012, at 10:32 AM, Pavel Krivanek wrote: > >> Hi, >> >> I shortly looked at it. To reproduce the key problem without need to >> start shrinking process we may use this expression. >> >> Behavior removeCategory: '*Deprecated14' > > Strange... a workaroung would do to just unload it > with Monticello instead. This should remove everything including Monticello so the extra step would be necessary. However the problem lies in the fact that this category is placed in the trait TPureBehavior. I will look at it. -- Pavel > We should merge the shrinking of #cleanUpForProduction with > the one of the Kernel... > > Â Â Â Â Marcus > > -- > Marcus Denker -- http://marcusdenker.de >

March 4, 2012

Re: [Pharo-project] pharo-seed and pharo

by Pavel Krivanek

On Fri, Mar 2, 2012 at 2:44 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Mar 2, 2012, at 2:38 PM, Tudor Girba wrote: >> >> That is even better. But, even without, I think that the current image >> can be loaded quite fast if we work on it. >> >> So, how can I find/obtain a seed image? >> > > https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%201.4/ > > reload worked last time in september, though... > > https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Reload/ > > ??? all a bit broken right now, because keeping shrink scripts current > is nearly impossible. One problem is that the reloading job is at the very end of process so if you cannot shrink to kernel because of some upgrade or load gofer, you are not able to run this job for a long time and it is very probable that when you will be finally able to run it again, it will be broken somehow too. If we will tell that the modular system is one of our priorities and we will immediately reject all updates that will as side effect break this jobs or will lower quality of the images, then we may do a big progress in this area very quickly. But this rule must be applied without exceptions. -- Pavel > > Â Â Â Â Marcus > > -- > Marcus Denker -- http://marcusdenker.de > >

March 4, 2012

Re: [Pharo-project] Pharo Kernel break...

by Marcus Denker

On Mar 4, 2012, at 10:32 AM, Pavel Krivanek wrote: > Hi, > > I shortly looked at it. To reproduce the key problem without need to > start shrinking process we may use this expression. > > Behavior removeCategory: '*Deprecated14' Strange... a workaroung would do to just unload it with Monticello instead. We should merge the shrinking of #cleanUpForProduction with the one of the Kernel... Marcus -- Marcus Denker -- http://marcusdenker.de

March 4, 2012

Re: [Pharo-project] Pharo Kernel break...

by Pavel Krivanek

Hi, I shortly looked at it. To reproduce the key problem without need to start shrinking process we may use this expression. Behavior removeCategory: '*Deprecated14' It fails but for any other category with methods it passes without errors. So this class has simply some special organization structure that uncovered an unknown error. The failure of the Pharo Kernel shrinking is not result of content of this patches. I currently have no time to find out more. Cheers, -- Pavel Behavior removeCategory: '*Deprecated14' On Fri, Mar 2, 2012 at 11:44 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > thank you. I was on vacation this week. I will look at the the issues > at weekend. > > Cheers, > -- Pavel > > On Thu, Mar 1, 2012 at 8:54 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Build broken: >> #314 Â Â Feb 28, 2012 9:32:45 PM >> Build ok: >> #313 Â Â Feb 28, 2012 8:48:31 PM >> >> >> This means that I broke it with this update: >> >> >> 14366 >> ----- >> >> Issue 5418: Â Â compressedSourceCodeAt: is not used >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5418 >> >> Issue 5414: Â Â class FormStub is unused and undocumented >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5414 >> >> Issue 5417: Â Â FlatMessageListBrowser error on method removal >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5417 >> >> Issue 5160: Â Â sourceCodeAt: vs. sourceMethodAt: >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5160 >> >> >> strange.... >> >> -- >> Marcus Denker -- http://marcusdenker.de >>

March 4, 2012

[Pharo-project] [update 1.4] #14373

by Marcus Denker

14373 ----- Issue 4902: deprecated: users should be rewritten into deprecated:on:in: http://code.google.com/p/pharo/issues/detail?id=4902 Issue 5429: clean: Monticello #updateInstVars http://code.google.com/p/pharo/issues/detail?id=5429 Issue 5430: Move some extension methods from Polymorph to morpic http://code.google.com/p/pharo/issues/detail?id=5430 -- Marcus Denker -- http://marcusdenker.de

March 4, 2012

Re: [Pharo-project] problem: nautilus forked moose-algos

by Benjamin

I will remove that and push it into another repo. It was a plugin started by Jannik, but never finished :) Thanks for report :) Ben On Mar 3, 2012, at 9:41 PM, Tudor Girba wrote: > Hi, > > Nautilus includes NautilusCommon and this in turn includes NautilusCommon-Plugin-JannikAlgo which copies verbatim a part of the classes from the Moose-Algos-Graph package from http://www.squeaksource.com/MooseAlgos. > > These classes are used in a plugin. Because of this, we cannot use Nautilus in Moose. > > So, I would suggest one of these: > - remove the plugin, at least from the default configuration > - load Moose-Algos-Graph properly > - fork with a different name > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > >

March 3, 2012

[Pharo-project] Cog VM binaries as per VMMaker.oscog-eem.152/r2538.

by Eliot Miranda

Cog VM binaries as per VMMaker.oscog-eem.152/r2538<http://www.mirandabanda.org/files/Cog/VM/VM.r2538/> . Fix tricky context state bug that can cause crashes in the GC. Contextpart>runUntilErrorOrReturnFrom: may pop the last argument. Hence if a frame is married in this state its spouse context won't have its last argument slot initialized. If later the frame is divorced and the arguments are not updated the last argument slot can be left with this uninitialized slot and ... bang. The solution is to update arguments as well as stack contents when divorcing. This is good also because it removes the VM's assumption that method arguments are read-only, and that's only enforced by the Smalltalk bytecode compiler, not by the bytecode. -- best, Eliot

March 3, 2012

Re: [Pharo-project] ConfigurationOfRefactoringBrowser fails

by Tudor Girba

Lukas took care of it, and now it's back online. Thanks, Doru On 3 Mar 2012, at 21:28, Tudor Girba wrote: > Hi, > > The problem comes from the url with the spelling info: > http://www.lukas-renggli.ch/smalltalk/rb-spelling.dat > > being unresolvable. > > > Cheers, > Doru > > > > On 3 Mar 2012, at 21:17, Tudor Girba wrote: > >> Hi, >> >> Something is strange. It works on my Mac, but it fails in headless mode on the server (the moose build). I will take a closer look. >> >> Cheers, >> Doru >> >> >> On 3 Mar 2012, at 07:09, Benjamin wrote: >> >>> In the method >>> >>> postLoadRBSpelling >>> "We want to initialize and download the dictionary file so that tests can be run without internet." >>> Smalltalk at: #RBInternalSpellChecker ifPresent: [:cl | cl new ]. >>> >>> the new invocation leads to Error: Improper store into indexable object. >>> >>> And due to that, Nautilus builds fail. >>> >>> >>> I have to go to bed now, but if someone could have a look, I will appreciate :) >>> >>> >>> Thanks in advance, >>> >>> >>> Ben >> >> -- >> www.tudorgirba.com >> >> "Problem solving efficiency grows with the abstractness level of problem understanding." >> >> >> > > -- > www.tudorgirba.com > > "Obvious things are difficult to teach." > > > -- www.tudorgirba.com "Value is always contextual."

March 3, 2012

Re: [Pharo-project] Looking for a package to do some statistics in Pharo

by GastÃ³n Dall' Oglio

El 3 de marzo de 2012 03:24, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>escribiÃ³: > Stef, > > I think our banned troll is back :( > hehe, no no, I lack the intelligence to be a good troll :) I misunderstood what Stef said, I understood that he wanted to make statistics about Pharo, more specifically on the development of Pharo. Anyway, if you're interested, this tool allows you to create funny animations log from a source repository. I made a simple animation with the repository build pharo, with those commands: $ git clone git://gitorious.org/pharo-build/pharo-build.git $ gource -800x600 pharo-build and this is the generated video: http://vimeo.com/37856284 Regards.

March 3, 2012