- Pharo-dev - lists.pharo.org

Re: [Pharo-project] in 14379...

by Marcus Denker

On Mar 6, 2012, at 12:08 PM, StÃ©phane Ducasse wrote: > Hi guys > > when I try to load > > MCSqueaksourceRepository > location: 'http://squeaksource.com/Games' > user: '' > password: '' > > load MorphicGames-md.1.mcz > > I get a DNU > > isPostMortem > "return whether we're inspecting a frozen exception without a process attached" > |selectedContext| > selectedContext := self selectedContext. > (interruptedProcess suspendedContext == selectedContext) > ifTrue: [ ^ false ]. > ^ (interruptedProcess suspendedContext findContextSuchThat: [:c | c sender == selectedContext]) isNil > > ^^^^^^ DNU findContextSuchThat: > > > interruptedProcess suspendedContext is a MethodContext > > Now I do not understand since find findContextSuchThat: is defined in ContextPart the super class of MethodContext. > This is related to the startup changes we integrated yesterday. (there is no change that has no side effect...) Marcus -- Marcus Denker -- http://marcusdenker.de

March 6, 2012

Re: [Pharo-project] in 14379...

by StÃ©phane Ducasse

On Mar 6, 2012, at 12:08 PM, StÃ©phane Ducasse wrote: > Hi guys > > when I try to load > > MCSqueaksourceRepository > location: 'http://squeaksource.com/Games' > user: '' > password: '' > > load MorphicGames-md.1.mcz > > I get a DNU > > isPostMortem > "return whether we're inspecting a frozen exception without a process attached" > |selectedContext| > selectedContext := self selectedContext. > (interruptedProcess suspendedContext == selectedContext) > ifTrue: [ ^ false ]. > ^ (interruptedProcess suspendedContext findContextSuchThat: [:c | c sender == selectedContext]) isNil > > ^^^^^^ DNU findContextSuchThat: > > > interruptedProcess suspendedContext is a MethodContext > > Now I do not understand since find findContextSuchThat: is defined in ContextPart the super class of MethodContext. > self class superclass selectors includes: #findContextSuchThat: -> true :( process stuff happening? > Stef

March 6, 2012

[Pharo-project] in 14379...

by StÃ©phane Ducasse

Hi guys when I try to load MCSqueaksourceRepository location: 'http://squeaksource.com/Games' user: '' password: '' load MorphicGames-md.1.mcz I get a DNU isPostMortem "return whether we're inspecting a frozen exception without a process attached" |selectedContext| selectedContext := self selectedContext. (interruptedProcess suspendedContext == selectedContext) ifTrue: [ ^ false ]. ^ (interruptedProcess suspendedContext findContextSuchThat: [:c | c sender == selectedContext]) isNil ^^^^^^ DNU findContextSuchThat: interruptedProcess suspendedContext is a MethodContext Now I do not understand since find findContextSuchThat: is defined in ContextPart the super class of MethodContext. Stef

March 6, 2012

Re: [Pharo-project] Fuel - class loading issue when superclass changed inst vars

by Henrik Johansen

On Mar 6, 2012, at 12:03 PM, Henrik Johansen wrote: >> > > Parcels > - Check a hash based on class layout vs equivalent hash for the stored method's class (stored with the method). > If different: > 1) check for existence of a backwards-compatability reader method, hand the old instance to it, and expect the old instance to be #become'd into something current, > 2) raise an error if no such method exists. > > Now, the main problem with this scheme is it's left as an exercise to the user to come up with a procedure to ensure said backwards-compat reader method stays up to date as additional changes are made. > > Is it a big problem? > Depends on your tests, and programmer diligence at any given day. > > Added inst vars are not a big deal, as if you forget them, there will usually be a nil #DNU somewhere down the line. (or you use lazy initialization, and everything works as expected even for existing instances) > > Removals/reorderings are a bigger issue, as the detection of failure (inst vars in wrong slots) are often far removed from the source of problems (forgetting to update the reader method), > If seldomly used, it may even go unnoticed until the instance is next saved, at which time you're in real trouble (especially if saved alongside newly created ones, in which case there is no consistency). > > In general I think it's an ok scheme, but would like to see a solution more resilient to user-error. > How to achieve that is an interesting topic, which I haven't yet found time to think through as thoroughly as I had wished/intended some months ago. :( Errr, BOSS, not Parcels. My bad. Cheers, Henry

March 6, 2012

Re: [Pharo-project] Fuel - class loading issue when superclass changed inst vars

by Henrik Johansen

On Mar 6, 2012, at 4:06 AM, Martin Dias wrote: > Hello, > > I'd like to discuss about a problem found when loading classes with Fuel (for people who don't know it: http://rmod.lille.inria.fr/web/pier/software/Fuel) > > Fuel can serialize a class either as a global or as a "regular" object. In the latter case, it saves the class with its compiled methods, including their bytecodes. (This was demonstrated in http://marianopeck.wordpress.com/2011/09/24/importing-and-exporting-package…) > > Well, the issue I want to talk about happens when loading a class with a method that uses an inherited instance variable. In a short example: > > - define class A with instVars 'x' > - define class B with a method that uses 'x'. > - serialize B in a file > - remove B from system > - redefine A with instVars 'y x' > - materialize B from the file > > -----> the bytecodes of B's method, that should refer to 'x', instead refer to 'y' (because inst vars are encoded in bytecodes just as indexes) > > Of course, there are variations of this problem: the variable was whether removed or renamed. > > > Some solutions: > 1) detect the change in a superclass and then: > a) just raise an error > b) compile based on attached source > c) decompile parse tree from bytecodes, fix it, and generate the method. > 2) serialize the parse tree *instead* of bytecodes, and always generate the method when materializing. > > I am thinking on the use case of package sharing, like Parcels. Note that since Fuel supports multiple strategies for serializing the same object, it is not necessary to choose just one option to fit in every use case. > > - I'm not sure, but I guess Parcels makes something like 1c). > - The alternative 1a) doesn't require any compiler (in a bootstrap image is good) > - I am tempted to explore 2), but not sure if that makes sense. > > I am curious about your opinions. > > Best regards, > MartÃn > Parcels - Check a hash based on class layout vs equivalent hash for the stored method's class (stored with the method). If different: 1) check for existence of a backwards-compatability reader method, hand the old instance to it, and expect the old instance to be #become'd into something current, 2) raise an error if no such method exists. Now, the main problem with this scheme is it's left as an exercise to the user to come up with a procedure to ensure said backwards-compat reader method stays up to date as additional changes are made. Is it a big problem? Depends on your tests, and programmer diligence at any given day. Added inst vars are not a big deal, as if you forget them, there will usually be a nil #DNU somewhere down the line. (or you use lazy initialization, and everything works as expected even for existing instances) Removals/reorderings are a bigger issue, as the detection of failure (inst vars in wrong slots) are often far removed from the source of problems (forgetting to update the reader method), If seldomly used, it may even go unnoticed until the instance is next saved, at which time you're in real trouble (especially if saved alongside newly created ones, in which case there is no consistency). In general I think it's an ok scheme, but would like to see a solution more resilient to user-error. How to achieve that is an interesting topic, which I haven't yet found time to think through as thoroughly as I had wished/intended some months ago. :( Cheers, Henry

March 6, 2012

[Pharo-project] Colored Stdout/Stderr logging with headless images

by Sven Van Caekenberghe

This is so cool and beautiful, this new addition where errors with headless images are printed directly to stout or stderr with coloring ! I just saw it the first time today. Really helpful. Thanks a lot Camillo ! Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 6, 2012

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

by Marcus Denker

On Mar 6, 2012, at 11:08 AM, Pavel Krivanek wrote: > I created a fix > > http://code.google.com/p/pharo/issues/detail?id=5438 > Thanks! I will have a look this evening. -- Marcus Denker -- http://marcusdenker.de

March 6, 2012

[Pharo-project] [update 1.4] #14379

by Marcus Denker

14379 ----- Issue 5321: DataStreamTest creates files that are not deleted http://code.google.com/p/pharo/issues/detail?id=5321 Issue 5285: HostWindowTests>>testOne (workaround) http://code.google.com/p/pharo/issues/detail?id=5285 Issue 5153: warningAllowed does not work with undefined selectors http://code.google.com/p/pharo/issues/detail?id=5153 -- Marcus Denker -- http://marcusdenker.de

March 6, 2012

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

by Pavel Krivanek

I created a fix http://code.google.com/p/pharo/issues/detail?id=5438 -- Pavel On Sun, Mar 4, 2012 at 12:42 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > 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 6, 2012

Re: [Pharo-project] looking for Morphic-Games package

by Edgar J. De Cleene

On 3/6/12 7:12 AM, "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I'm looking for the package containing tetris, free cell, Â > does any of you know where it is? > > Stef Just for you I remade for Pharo File in for the repository. Load MorphicGames-edc.3.mcz Evaluate (Tetris new) openInWorld Maybe not all Games work , but is a start. What about a FunPharo ? Like the idea or no old stuff into Pharo ? By the way gracias a Mariano y a Esteban. I using Nautilus 1.4 and last CogVM for doing this. Edgar

March 6, 2012