- Pharo-dev - lists.pharo.org

Re: [Pharo-project] ProtoObject basicNew :)

by StÃ©phane Ducasse

It crashed my NBCog and Cog one vm. so I should probably upgrade. Stef On Nov 27, 2011, at 11:36 AM, StÃ©phane Ducasse wrote: > 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] fuel and a factory

by Yanni Chiu

On 27/11/11 8:31 AM, Mariano Martinez Peck wrote: > > > On Sun, Nov 27, 2011 at 7:44 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr > <mailto:stephane.ducasse@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? Not the same problem, since it was the class object itself that was being referenced in a Pier security permissions object.

Nov. 27, 2011

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

by Yanni Chiu

On 27/11/11 8:58 AM, Mariano Martinez Peck wrote: > > 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? I suppose a general solution would be a maximum substitution count, with a default of one. I have no idea, or use case, to know how useful it would be to substitute substituted objects - so just consider this idle ramblings.

Nov. 27, 2011

Re: [Pharo-project] class rename and Fuel

by Yanni Chiu

On 27/11/11 8:35 AM, Mariano Martinez Peck wrote: > > Sorry, I didn't understand your question/problem. The class rename feature would have solved my loading problem easily. The problem I'm talking about is not a Fuel feature, but how to use Fuel. At this point, I did a one time migration, and then threw away the migration code. I was sure I could get the migration done, whether or not Fuel had the class rename feature. I was just wondering what to do about future migrations. I dislike having all these migration code fragments cluttering the code base. I think Fuel just needs to have features that support various migration strategies, but it doesn't have to say how the migration code is structured.

Nov. 27, 2011

Re: [Pharo-project] [squeak-dev] [ANN] First try: Fuel for Squeak

by David T. Lewis

On Sat, Nov 26, 2011 at 05:06:17PM -0300, Mariano Martinez Peck wrote: > Hi guys. After a couple of efforts from Martin Dias and I, we have a > "working" Fuel serializer for Squeak. I used the quotes because all I could > do is to run tests. Cool! > > As always, we appreciate any feedback. > Hi Mariano, I loaded Fuel into my working Squeak image, which is an older image kept up to date with trunk via the update stream (i.e. it is "bleeding edge" with various additional packages loaded). I had to implement SystemVersion>>major and SystemVersion>>minor to complete the installation (these are Pharo idioms, so I just implemented them to answer 0 on Squeak). I did not encounter the timeout problem, but if you have a long running test, just add a pragma like <timeout: 30> to set the timeout to 30 seconds. This will increase the timeout when running on Squeak, and should not affect Pharo. Below are some notes that I took while running the tests. The most important issue would be the tests that fail in CompiledMethod comparison. I cannot say if this is a Fuel issue or just something about the way the tests are written, but I note significant differences in the implementation of CompiledMethod>>= between Squeak and Pharo, so it is definitely something worth checking. Notes on test issues in FuelTests: FLSequencedSerializationTest>>assertSequencedSerializationEqualityOf: is failing due to difference in CompiledMethod>>= between Pharo and Squeak. Not sure if this is a Fuel issue. FLBasicSerializationTest>>testGradientFillStyle fails because GradientFillStyle>>= is an identity test, whereas in Pharo it has been added from package '*PolyMorph-Widgets' (i.e. not part of base Pharo either). FLBasicSerializationTest>>testMethodDictionary fails due to compiled method #= (same issue as FLSequencedSerializationTest>>assertSequencedSerializationEqualityOf:) In FLBlockClosureSerializationTest, all tests fail with an assertion failure in MethodContext FLFullBasicSerializationTest>>testMethodDictionaries fails due to the compiled method equality check problem. FLMethodContextSerializationTest tests fail with assertion failure in MethodContext FLSortedCollectionSerializationTest tests fail with assertion failure in MethodContext FLCreateClassSerializationTest has errors due to DNU from ClassForTestToBeDeleted1 class>>basicLocalSelectors FLCompiledMethodSerializationTest>>testTwoCompiledMethodsReferencingSameClassVariable fails due to the compiled method equality check problem. FLCreateTraitSerializationTest>>testCreateBasic fails with DNU on Trait>>basicLocalSelectors

Nov. 27, 2011

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