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

Re: [Pharo-project] Morphic Cleanup Status

by Fernando Olivero

Differently from what i've shown you at ESUG, i didn't reify the events. The vm announces a new event to the GUserInterface, who dispatches the event to the mouse or the keyboard. Which in turn, according to its inner state (modeled using a fsm), sends a message to the user interface, such as #clickedAt: , #secondaryClickedAt: , #move: #moveDragging:, #keystroke: aGKeystroke, etc.. The following diagram depicts the scheme. Fernando On Fri, Nov 25, 2011 at 10:38 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Nov 25, 2011, at 11:08 AM, Fernando Olivero wrote: > >> Hi Sean, i got overwhelmed last year with the task of porting CUIS >> Morphic, to Pharo. There's just to much differences on several common >> classes, it's hard to fully understand how to merge both ui >> frameworks. >> >> Even though i believe Juan has a did an excellent work in simplifying >> Morphic, and adding simpler code, like for example his new layouts >> (download CUIS and try them out). >> >> But my overall impression , was that we need to stop being backward >> compatible in order to create a simple Morphic-like framework for >> Pharo, and start from scratch. Fixing current Morphic is also a >> humongous Â task, for example see Stef's nice work on cleaning the >> event handling mechanism. > > BTW you should be able to use the new event hierarchy: it is clean (no first secondâ¦..) and a nice support for double > dispatch. I hope that next week I can sit with igor and we finish our journey. > How do you deal with event in Gaucho. > > Stef >> >> Fernando >> >> On Fri, Nov 25, 2011 at 9:38 AM, Alain Plantec <alain.plantec(a)yahoo.com> wrote: >>> Le 25/11/2011 07:39, Sean P. DeNigris a Ã©crit : >>>> What's currently in progress? SimpleMorphic? CUIS related? Other? >>>> >>>> I was pulling my hair out with Morphic layouts yesterday and started to >>>> clean, but I don't want to duplicate efforts on things already being worked >>>> on. There are a bunch of open issues and discussions on the list. What's >>>> actively being done right now? >>> Hi Sean, >>> AFAIK, no deep cleaning action. nothing from my side for now. >>> I think they have done some refactoring around layout managing in CUIS >>> (SimpleMorphic). >>> btw, **thanks a lot** for all you are doing. >>> Cheers >>> Alain >>> >>>> >>>> Thanks. >>>> Sean >>>> >>>> -- >>>> View this message in context: http://forum.world.st/Morphic-Cleanup-Status-tp4106566p4106566.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>> >>> >> > >

Nov. 27, 2011

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

by David T. Lewis

On Sun, Nov 27, 2011 at 03:34:27PM -0300, Mariano Martinez Peck wrote: > > > > 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). > > > > > Excellent :) > Where can I get a "bleeding edge" Squeak image? The most recent update on the ftp server is <ftp://ftp.squeak.org/4.3alpha/Squeak4.3gamma-11793.zip> Run that image, then from the world menu (left click anywhere), select help... -> update code from server When the update is complete, you have a fully updated image. > > > 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). > > > > > To complete the instalation?? Can you remember why (the sender) it is > needing #mayor and #minor? > As far as I remember, it is only used by Fuel in FLBasicSerializationTest > >> expectedFailures > but that is not the installation, but running tests. I'm not sure, but for whatever reason it popped up as an error while I was installing. > > > > 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. > > > > Thanks, I didn't know. Is there a way to run the tests in the test runner > so that it doesn't take into account such timeouts? > or can I change the global preference? I ask so that to avoid changing > tests code (even if they would work for Pharo). I don't think that there is a preference for this. It's probably best to just provide the pragma for the specific tests, since this will not affect the tests themselves. > Thanks for the detailed answer. From what I can see, even if those tests > are wrong, "most cases" should work fine. Yes, it is working fine for me. I just changed RemoteTask to make use of Fuel for serializing objects between images, and it seems to work very well. Dave

Nov. 27, 2011

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

by Mariano Martinez Peck

On Sun, Nov 27, 2011 at 3:25 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > 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. > > Fuel is a binary serializer and you can find all the information in > > http://rmod.lille.inria.fr/web/pier/software/Fuel > > This is a project sponsored by ESUG SummerTalk and mainly developed by > > Martin Dias. > > Fuel seems to work fine in Squeak (despite some issues in the tests), so > I updated RemoteTask <http://wiki.squeak.org:8080/squeak/6176> to use Fuel > rather than ReferenceStream for returning the results of a remote task to > the supervisor image. If Fuel is not present in the image, ReferenceStream > will be used by default. This update is included in the latest CommandShell > on SqueakSource. > > Excellent. I am glad to hear that. Let us know if there are problems. > Fuel provides provides a noticable performance improvement when returning > a large result data set, and also avoids a problem in serializing large > integers <http://bugs.squeak.org/view.php?id=7679> . > Thanks. Indeed, the performance is one of the most important characteristic of Fuel. > > Pharo users should beware of this bug when running the RemoteTask examples > <https://code.google.com/p/pharo/issues/detail?id=4997>, because the > examples perform prime number searches in the remote tasks. > Ok, it seems the issue is being discussed. Cheers > > Dave > > > -- Mariano http://marianopeck.wordpress.com

Nov. 27, 2011

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

by Mariano Martinez Peck

> > 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). > > Excellent :) Where can I get a "bleeding edge" Squeak image? > 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). > To complete the instalation?? Can you remember why (the sender) it is needing #mayor and #minor? As far as I remember, it is only used by Fuel in FLBasicSerializationTest >> expectedFailures but that is not the installation, but running tests. > > 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. > Thanks, I didn't know. Is there a way to run the tests in the test runner so that it doesn't take into account such timeouts? or can I change the global preference? I ask so that to avoid changing tests code (even if they would work for 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. > > That's a good point. There must be something there for sure. > 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 > > > Thanks for the detailed answer. From what I can see, even if those tests are wrong, "most cases" should work fine. Cheers -- Mariano http://marianopeck.wordpress.com

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. > Fuel is a binary serializer and you can find all the information in > http://rmod.lille.inria.fr/web/pier/software/Fuel > This is a project sponsored by ESUG SummerTalk and mainly developed by > Martin Dias. Fuel seems to work fine in Squeak (despite some issues in the tests), so I updated RemoteTask <http://wiki.squeak.org:8080/squeak/6176> to use Fuel rather than ReferenceStream for returning the results of a remote task to the supervisor image. If Fuel is not present in the image, ReferenceStream will be used by default. This update is included in the latest CommandShell on SqueakSource. Fuel provides provides a noticable performance improvement when returning a large result data set, and also avoids a problem in serializing large integers <http://bugs.squeak.org/view.php?id=7679> . Pharo users should beware of this bug when running the RemoteTask examples <https://code.google.com/p/pharo/issues/detail?id=4997>, because the examples perform prime number searches in the remote tasks. Dave

Nov. 27, 2011

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