November 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fuel bug: infinite recursion in "analyzer when:substituteBy:"

by Mariano Martinez Peck

> > In serialization, when you substitute an object by another, such >> substitution(*) is then serialized using the same rules, so you might >> need the guard condition to avoid the infinite loop. >> >> This was the simpler implementation, but maybe it's undesirable or it's >> too error prone. Do you think we should change this? >> > > Probably, the right answer is to allow a choice of whether or not the > substituted object(s) are subject to further substitution. And, no matter > which choice is made, no infinite loop should occur -- a tall order. But if the choice made is to let substituted objects to be substituted again, then a loop may happen, and Fuel cannot control/detect that. Maybe the default value should not allow substituting substituted objects? > > > *: note the substitution can be not just an object but a graph of >> objects, some of them able to be substituted too. >> > > Good to know this. > > > -- Mariano http://marianopeck.wordpress.com

Nov. 27, 2011

Re: [Pharo-project] class rename and Fuel

by Mariano Martinez Peck

> > > I want to support in fuel 1.8 some way of specifying that a class has >> been renamed. Something like: >> >> FLMaterializer newDefault >> classRenames: { #OldClass -> #NewClass } >> materializeFrom: aFile. >> >> Would this solve your problem? >> > > Yes it would, but the real issue for me is whether or not the migration > code stays forever in the code base, or should a one time migration step be > run (and keep no migration trail in the Fuel code). > > Sorry, I didn't understand your question/problem. THanks -- Mariano http://marianopeck.wordpress.com

Nov. 27, 2011

Re: [Pharo-project] class rename and Fuel

by Mariano Martinez Peck

Well, this is clearly something we must improve and provide :) On Sun, Nov 27, 2011 at 12:23 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 25/11/11 6:57 PM, Yanni Chiu wrote: > >> On 25/11/11 5:46 PM, Martin Dias wrote: >> >>> >>> This can be the problem. Can you update these references to point >>> NewClass? >>> >> >> Now that I know what's holding on to the class, I can figure out what to >> do. Ideally, I'd like to remove the reference to the class, and have the >> command list re-generated. This strategy is available for a Pier kernel, >> but not for the general migration problem for Fuel. >> > > FYI, the solution was: > > 1) Define the old class so Fuel will load the kernel: > > Object subclass: #OldCommand > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'ZZZImportExport'. > > N.B. Subclass from Object, not PRCommand, because Pier looks for all > subclasses of PRCommand. (This may not have been necessary, but was done > just in case). > > 2) Change the reference from OldClass to NewClass > > PUSecurity allInstances do: [ :each | > each otherPermissions do: [ :perm | > perm command = OldCommand ifTrue: [ perm setCommand: NewCommand ] ]. > each groupPermissions do: [ :perm | > perm command = OldCommand ifTrue: [ perm setCommand: NewCommand ] ]. > each ownerPermissions do: [ :perm | > perm command = OldCommand ifTrue: [ perm setCommand: NewCommand ] ]. > ]. > > 3) Re-serialize with Fuel > > 4) Remove the migration code > > > -- Mariano http://marianopeck.wordpress.com

Nov. 27, 2011

Re: [Pharo-project] fuel and a factory

by Mariano Martinez Peck

On Sun, Nov 27, 2011 at 7:44 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Just out of curiosity > is there a way to specify the class that should be used when loading a > fuel saved objects. > For example I would like to know if it is possible to save Booleans and > load them as instance of another class MBoolean > > Not a clean out-of-the-box hook that I can imagine. In fact, it seems exactly the same feature Yanni is missing: http://forum.world.st/class-rename-and-Fuel-td4108831.html. Right? > of course boolean is a bit extreme :) but for a bootstrap we may need that. > > Stef > -- Mariano http://marianopeck.wordpress.com

Nov. 27, 2011

Re: [Pharo-project] ProtoObject basicNew :)

by StÃ©phane Ducasse

On Nov 26, 2011, at 9:58 PM, Schwab,Wilhelm K wrote: > Stef, > > Attached are methods I clearly felt the need to add to ProtoObject. I vaguely recall much trial and even more error :) In my one meaningful (and very little used, due to changing priorities) subclass of ProtoObject, I added #= and #hash. I also customized #printOn:, but that *shouldnt'* be important - caveat emptor :) There are some other finalization related methods, and some "Dolphinization" of events, etc. Again, I don't think those things are crucial outside of my world. > > Speaking of Dolphin, two things come to mind. First is protocols, which Dolphin makes concrete and editable. One can define the methods that constitute a protocol, and impose protocols on any number of classes. Any class can implement any number of protocols too. The system then complains if changes cause one or more classes to not understand one or more methods in declared protocols. Pretty slick. yes this is a cool idea. This is the same as SmallInterfaces http://scg.unibe.ch/archive/papers/Sade02aDynamicInterfaces.pdf I would really like to see how we can use that. > > Another thing is the ability to assign multiple categories to any given method. I think that's something one has to have experienced in order to understand how completely useful it can be. No I can understand it ;) > > HTH. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Friday, November 25, 2011 4:19 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] ProtoObject basicNew :) > > On Nov 25, 2011, at 10:09 PM, Toon Verwaest wrote: > >> Ok, I guess I was confused by your initial question: "the methods that I should define in a subclass of ProtoObject so that I can use basicNew"... :) > > :) > > Yes it is more the methods that I should define to have a usable class (browse, doit, inspect it). I will probably have to do it by try and error. > > Stef > >> >> On 11/25/2011 10:05 PM, StÃ©phane Ducasse wrote: >>> I'm confused. >>> I'm not creating a class but an instance. >>> if it would be Behavior basicNew then yes I made sure that we could do Behavior new and not crashing the system back in Squeak. >>> >>> On Nov 25, 2011, at 9:45 PM, Toon Verwaest wrote: >>> >>>> With the magic number I mean the number that defines the object's structure. It's one of the first 3 instance variables of every class, encoding how many instance variables there are; what kind of object it is supposed to be (normal, array, bytes, words...). Every "class" basically needs 3 instance variables. 1 defines the structure, 1 the superclass, 1 the behavior (method dictionary). I don't know the other; but just look at some class to know what the order is. >>> Yes format, methodDict, superclass (probably in a different order). >>> And format is ugly because not explicit and coded in several place like instSpec (berk) >>> >>>> And yes, if you want to inspect the object, you'll need to support whatever protocol your inspector is using. >>>> >>>> The format is formed as follows: >>>> >>>> format >>>> | fieldSize sizeHiBits format | >>>> fieldSize := self fieldSize + 1. >>>> sizeHiBits := fieldSize // 64. >>>> format := sizeHiBits. >>>> format := (format bitShift: 5) + compactClassIndex. >>>> format := (format bitShift: 4) + self instanceSpecification. >>>> format := (format bitShift: 6) + (fieldSize \\ 64). >>>> format := (format bitShift: 1). >>>> ^ format >>>> >>>> If I read it correctly (just glancing), instance specification specifies if it's arrayed and if it has fields. 0 -> no fields, not arrayed, 1 -> fields, not arrayed, 2 -> arrayed no fields, 3 -> arrayed fields. >>>> >>>> >>>> HTH, >>>> Toon >>>> >>>> On 11/25/2011 09:31 PM, StÃ©phane Ducasse wrote: >>>>> Apparently I can do a doit I was naively doing an inspect ;) >>>>> >>>>> >>>>>> Don't you just need the basicNew primitive, and make sure that the "magic number" is set in the object that has the basicNew installed to something that makes sense? >>>>>> >>>>> I do not know what is the magic number. >>>>> I guess that my problem was that I have first to define what is the minimal behavior. >>>>> >>>>> >>>>>> If you want to send messages to the object, probably also best install some dictionary as the method dict instvar. >>>>>> >>>>> But I guess that ProtoObject has some behavior since I can browse the class with a browser. >>>>> >>>>> >>>>> >>>>>> Toon >>>>>> >>>>>> On 11/25/2011 09:26 PM, StÃ©phane Ducasse wrote: >>>>>> >>>>>>> Hi >>>>>>> I would like to know the methods that I should define in a subclass of ProtoObject so that I can use basicNew. >>>>>>> Does any of you have an idea? >>>>>>> >>>>>>> Stef >>>>>>> >>> >> >> > > > <ProtoObject-*dolphinCompatibility-idioms.st>

Nov. 27, 2011

Re: [Pharo-project] What happened to COTDC?

by StÃ©phane Ducasse

but somebody else can do it. Here I got three kids sick one after the otherâ¦ a real hospital. Stef On Nov 27, 2011, at 11:33 AM, laurent laffont wrote: > Thousands sorry. Chaotic life at the moment ..... > > Laurent > > On Sat, Nov 26, 2011 at 4:37 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > laurent got busy but somebody else can just do the same and it would be great. > > Stef > > On Nov 26, 2011, at 3:37 PM, Sean P. DeNigris wrote: > > > We seemed to be doing so well... > > > > -- > > View this message in context: http://forum.world.st/What-happened-to-COTDC-tp4110480p4110480.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > >

Nov. 27, 2011

[Pharo-project] fuel and a factory

by StÃ©phane Ducasse

Just out of curiosity is there a way to specify the class that should be used when loading a fuel saved objects. For example I would like to know if it is possible to save Booleans and load them as instance of another class MBoolean of course boolean is a bit extreme :) but for a bootstrap we may need that. Stef

Nov. 27, 2011

Re: [Pharo-project] ProtoObject basicNew :)

by StÃ©phane Ducasse

thanks noury! Stef On Nov 26, 2011, at 9:05 PM, Noury Bouraqadi wrote: > Stef, > > You can easily obtain the list by using a Ghost proxy. > 1) Install the package : > Gofer new > squeaksource: 'Marea'; > package: 'GhostProxies'; > package: 'GhostProxiesTests'; > load. > > 2) uncomment the body of method SimpleForwarderHandler>>log: aString > Transcript show: aString; cr. > > 3) open a transcript > > 4) create a proxy on any object and play with it > (ObjectProxy proxyFor: (Object new)) inspect > > 5) analyze the log on the transcript :-) > > > On 25 nov. 2011, at 22:19, StÃ©phane Ducasse wrote: > >> >> On Nov 25, 2011, at 10:09 PM, Toon Verwaest wrote: >> >>> Ok, I guess I was confused by your initial question: "the methods that I should define in a subclass of ProtoObject so that I can use basicNew"... :) >> >> :) >> >> Yes it is more the methods that I should define to have a usable class (browse, doit, inspect it). I will probably have to do it by try and error. >> >> Stef >> >>> >>> On 11/25/2011 10:05 PM, StÃ©phane Ducasse wrote: >>>> I'm confused. >>>> I'm not creating a class but an instance. >>>> if it would be Behavior basicNew then yes I made sure that we could do Behavior new and not crashing the system back in Squeak. >>>> >>>> On Nov 25, 2011, at 9:45 PM, Toon Verwaest wrote: >>>> >>>>> With the magic number I mean the number that defines the object's structure. It's one of the first 3 instance variables of every class, encoding how many instance variables there are; what kind of object it is supposed to be (normal, array, bytes, words...). Every "class" basically needs 3 instance variables. 1 defines the structure, 1 the superclass, 1 the behavior (method dictionary). I don't know the other; but just look at some class to know what the order is. >>>> Yes format, methodDict, superclass (probably in a different order). >>>> And format is ugly because not explicit and coded in several place like instSpec (berk) >>>> >>>>> And yes, if you want to inspect the object, you'll need to support whatever protocol your inspector is using. >>>>> >>>>> The format is formed as follows: >>>>> >>>>> format >>>>> | fieldSize sizeHiBits format | >>>>> fieldSize := self fieldSize + 1. >>>>> sizeHiBits := fieldSize // 64. >>>>> format := sizeHiBits. >>>>> format := (format bitShift: 5) + compactClassIndex. >>>>> format := (format bitShift: 4) + self instanceSpecification. >>>>> format := (format bitShift: 6) + (fieldSize \\ 64). >>>>> format := (format bitShift: 1). >>>>> ^ format >>>>> >>>>> If I read it correctly (just glancing), instance specification specifies if it's arrayed and if it has fields. 0 -> no fields, not arrayed, 1 -> fields, not arrayed, 2 -> arrayed no fields, 3 -> arrayed fields. >>>>> >>>>> >>>>> HTH, >>>>> Toon >>>>> >>>>> On 11/25/2011 09:31 PM, StÃ©phane Ducasse wrote: >>>>>> Apparently I can do a doit I was naively doing an inspect ;) >>>>>> >>>>>> >>>>>>> Don't you just need the basicNew primitive, and make sure that the "magic number" is set in the object that has the basicNew installed to something that makes sense? >>>>>>> >>>>>> I do not know what is the magic number. >>>>>> I guess that my problem was that I have first to define what is the minimal behavior. >>>>>> >>>>>> >>>>>>> If you want to send messages to the object, probably also best install some dictionary as the method dict instvar. >>>>>>> >>>>>> But I guess that ProtoObject has some behavior since I can browse the class with a browser. >>>>>> >>>>>> >>>>>> >>>>>>> Toon >>>>>>> >>>>>>> On 11/25/2011 09:26 PM, StÃ©phane Ducasse wrote: >>>>>>> >>>>>>>> Hi >>>>>>>> I would like to know the methods that I should define in a subclass of ProtoObject so that I can use basicNew. >>>>>>>> Does any of you have an idea? >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>> >>> >>> >> >> > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > > > > >

Nov. 27, 2011

Re: [Pharo-project] What happened to COTDC?

by laurent laffont

Thousands sorry. Chaotic life at the moment ..... Laurent On Sat, Nov 26, 2011 at 4:37 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > laurent got busy but somebody else can just do the same and it would be > great. > > Stef > > On Nov 26, 2011, at 3:37 PM, Sean P. DeNigris wrote: > > > We seemed to be doing so well... > > > > -- > > View this message in context: > http://forum.world.st/What-happened-to-COTDC-tp4110480p4110480.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > >

Nov. 27, 2011

Re: [Pharo-project] class rename and Fuel

by Yanni Chiu

On 25/11/11 6:57 PM, Yanni Chiu wrote: > On 25/11/11 5:46 PM, Martin Dias wrote: >> >> This can be the problem. Can you update these references to point >> NewClass? > > Now that I know what's holding on to the class, I can figure out what to > do. Ideally, I'd like to remove the reference to the class, and have the > command list re-generated. This strategy is available for a Pier kernel, > but not for the general migration problem for Fuel. FYI, the solution was: 1) Define the old class so Fuel will load the kernel: Object subclass: #OldCommand instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'ZZZImportExport'. N.B. Subclass from Object, not PRCommand, because Pier looks for all subclasses of PRCommand. (This may not have been necessary, but was done just in case). 2) Change the reference from OldClass to NewClass PUSecurity allInstances do: [ :each | each otherPermissions do: [ :perm | perm command = OldCommand ifTrue: [ perm setCommand: NewCommand ] ]. each groupPermissions do: [ :perm | perm command = OldCommand ifTrue: [ perm setCommand: NewCommand ] ]. each ownerPermissions do: [ :perm | perm command = OldCommand ifTrue: [ perm setCommand: NewCommand ] ]. ]. 3) Re-serialize with Fuel 4) Remove the migration code

Nov. 27, 2011