October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] ClassOrganizer oddities

by Alain Plantec

Igor Stasenko wrote: > 2009/10/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > well, my initial idea is to enable a package developer to establish own policy > for his package. > A policy get notified of any change before it made and of course > doesn't cares if there's anyone > who listens for notifications of changes, after they applied. > The open question, is how to allow developer to not only use > predefined set of flags for policy, > but also introduce own custom rules. For example, one might want check > the submitted method against lint rules, > and prevent method from being installed if rules not satisfied :) > > You defined a set of announcement classes, each one is for a particular kind of event. So, no need for #changeKind and #parameters dictionary instance variable (please no!). The action which is applied is simply implemented by the announce sender. Before a system event occurs, an announce is sent saying that the event is about to occur. Then declared listeners could decide if the event can really occur (if a listener is in a state which forbid the event then it can change the announce which was sent). If the sent announce is not change (recall that this is an object), then it means that a consensus about the feasibility of the event is obtained. Then the particular event can occur. After, an announce indicating that the event has occurred is sent. I'm not sure but I think that seaside is already using announcements with such kind of consensus protocol. Alain

Oct. 28, 2009

Re: [Pharo-project] ClassOrganizer oddities

by Igor Stasenko

2009/10/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> Any change to system should be captured _before_ it applied. >> This allows us to introduce a policy which can validate the change >> and decide >> whether it allowed to be made or not. >> >> I made the SystemChangeEvent class, which having following state: >> - changeKind - a symbol, which identifies the change >> - parameters - a dictionary , which holding different parameters, >> important for change >> - subject - the object which is going to be changed (or taking a main >> role in change) >> - action - a block closure which , if evaluated, will apply the >> change to system > > why not using announcement? sure, why not :) > >> For example, here the method which creates & populates the system >> change event: >> >> classify: element under: heading suppressIfDefault: aBoolean >> >> Â Â Â (self subject newSystemEvent: #changeSelectorCategory) >> Â Â Â Â Â Â Â subject: element; >> Â Â Â Â Â Â Â param: #behavior->self subject; >> Â Â Â Â Â Â Â param: #category->heading asSymbol; >> Â Â Â Â Â Â Â param: #suppressIfDefault->aBoolean; >> Â Â Â Â Â Â Â action: [ super classify: element under: heading suppressIfDefault: >> aBoolean ]; >> Â Â Â Â Â Â Â signal. >> --------- >> >> The event handling procedure is following: >> >> - first of all, an event passed to a system arbiter object >> - a system arbiter checking with the policy >> - if everything ok, change is applied by evaluating action. >> - and finally, change is announced to any interesting parties >> >> I want to make each package to hold own policy (a set of flags >> identified by name, to ease fileout). > > Why only easing fileout it seems to me that this is not related to > notification of changes? > well, my initial idea is to enable a package developer to establish own policy for his package. A policy get notified of any change before it made and of course doesn't cares if there's anyone who listens for notifications of changes, after they applied. The open question, is how to allow developer to not only use predefined set of flags for policy, but also introduce own custom rules. For example, one might want check the submitted method against lint rules, and prevent method from being installed if rules not satisfied :) >> Then, any event could be validated by policy by issuing: >> package policy validate: change >> >> For example, lets see , what validations we could introduce for method >> recategorization event. >> >> Â - lets take most interesting case, when we want to recategorize the >> method in ClassA, which belongs to PackageA, >> Â and putting it into extension category, like *PackageB >> >> Â - check, if we allow any changes to ClassA (policy of PackageA) >> Â - check if PackageA allows method extensions (policy of PackageA) >> Â - check if PackageB allows extending the classes of another packages >> (policy of PackageB) >> Â - check if extension overrides existing method >> Â - and of course, we should check that given extension does not >> creates a circular dependency between the packages. > > I would like to understand why do we want package to get a policy? > Simple. a) In case of any changes, the class environment should be notified, NOT some global. b) in a future, i want to change the class environment to be a package, to which it belongs to. Hence, the package could have own, unique policy, or refer to system-wide one. But it is package, who receiving notifications first, and should be first who in control how to handle them. >> There, of course, some problems which arising. >> - changes nesting. >> Â Some changes is complex ones, and even a simple method >> recategorization could lead to another event - creating a new >> Â category in class. Â Optimally, it would be cool to have only most >> basic events, which can't be nested. And any action which may lead to >> multiple changes, should be split on a number of basic ones. >> A SystemChangeNotifier solving this by allowing doing things silently: >> Â SystemChangeNotifier uniqueInstance doSilently: [ ... ]. >> so, any changes within the block , if any, won't be announced. >> >> - atomicity support. To support the bulk model updating, i can imagine >> the framework, which capturing any changes without applying them, by >> building/collecting all changes in parallel, and then applying them by >> a single mass-become. This is what SystemEditor does. >> >> - metaprogramming. There should be a means to leave a room for >> metaprogramming. We wouldn't want to signal a system change for >> anonymous classes, and many other things, which can be tricky here. >> >> P.S. as you can see , the plans is quite bold, and will require >> numerous refactorings :) So, the more people is interested in that, >> the better. > > > My gut feeling is to say: > Â Â Â Â - let us study what is there > Â Â Â Â - can we migrate to announcement Yes, we can (c) Its good that you remind me about announcements framework. And you are right, that implementing this using announcements is good idea. But i feel a bit uncomfortable facing the need to spawn a lot of (sub)classes for that purpose. Obviously, the kernel should handle all of system events without exceptions, hence a kernel doesn't really needs to know such finely defined subclasses. While other subscribers may want to selectively listen for different things, which happening in a system. So, i want to hear what you and others think about it. > Â Â Â Â - slowly move from there. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 28, 2009

Re: [Pharo-project] ClassOrganizer oddities

by StÃ©phane Ducasse

> > Any change to system should be captured _before_ it applied. > This allows us to introduce a policy which can validate the change > and decide > whether it allowed to be made or not. > > I made the SystemChangeEvent class, which having following state: > - changeKind - a symbol, which identifies the change > - parameters - a dictionary , which holding different parameters, > important for change > - subject - the object which is going to be changed (or taking a main > role in change) > - action - a block closure which , if evaluated, will apply the > change to system why not using announcement? > For example, here the method which creates & populates the system > change event: > > classify: element under: heading suppressIfDefault: aBoolean > > (self subject newSystemEvent: #changeSelectorCategory) > subject: element; > param: #behavior->self subject; > param: #category->heading asSymbol; > param: #suppressIfDefault->aBoolean; > action: [ super classify: element under: heading suppressIfDefault: > aBoolean ]; > signal. > --------- > > The event handling procedure is following: > > - first of all, an event passed to a system arbiter object > - a system arbiter checking with the policy > - if everything ok, change is applied by evaluating action. > - and finally, change is announced to any interesting parties > > I want to make each package to hold own policy (a set of flags > identified by name, to ease fileout). Why only easing fileout it seems to me that this is not related to notification of changes? > Then, any event could be validated by policy by issuing: > package policy validate: change > > For example, lets see , what validations we could introduce for method > recategorization event. > > - lets take most interesting case, when we want to recategorize the > method in ClassA, which belongs to PackageA, > and putting it into extension category, like *PackageB > > - check, if we allow any changes to ClassA (policy of PackageA) > - check if PackageA allows method extensions (policy of PackageA) > - check if PackageB allows extending the classes of another packages > (policy of PackageB) > - check if extension overrides existing method > - and of course, we should check that given extension does not > creates a circular dependency between the packages. I would like to understand why do we want package to get a policy? > There, of course, some problems which arising. > - changes nesting. > Some changes is complex ones, and even a simple method > recategorization could lead to another event - creating a new > category in class. Optimally, it would be cool to have only most > basic events, which can't be nested. And any action which may lead to > multiple changes, should be split on a number of basic ones. > A SystemChangeNotifier solving this by allowing doing things silently: > SystemChangeNotifier uniqueInstance doSilently: [ ... ]. > so, any changes within the block , if any, won't be announced. > > - atomicity support. To support the bulk model updating, i can imagine > the framework, which capturing any changes without applying them, by > building/collecting all changes in parallel, and then applying them by > a single mass-become. This is what SystemEditor does. > > - metaprogramming. There should be a means to leave a room for > metaprogramming. We wouldn't want to signal a system change for > anonymous classes, and many other things, which can be tricky here. > > P.S. as you can see , the plans is quite bold, and will require > numerous refactorings :) So, the more people is interested in that, > the better. My gut feeling is to say: - let us study what is there - can we migrate to announcement - slowly move from there. Stef

Oct. 28, 2009

Re: [Pharo-project] Strange behavior of #printString method

by StÃ©phane Ducasse

Ok can you open a ticket on the bugtracker with a description because this can be fixed easily isSelf... ^ self isKindOf: Color? > The problem is in the Transparent color element of the my bad array. > Transparent color class implements #isSelfEvaluating of that way... > > isSelfEvaluating > ^ self class == Color > > That condition dont works in the first element of my bad array. > > Regards, and thanks for the help :| > > > > > 2009/10/27 StÃ©phane Ducasse [via Smalltalk] <[hidden email]> > Apparently you find a problem in self evaluating on color or related. > Let me explain: > > The idea of printing an object is that in some case > anObject printString let you recreate the object > example > > 1 > true > #(1) > #(1 2) > 10@50 > > this means that either you get the same object or when you executed > its printed representation you get it back. > This is handy when playing with an inspector or in a workspace > > now for array if you get an array of points in the past > printing it would return > #(10 #@ 50 20 #@ 50) > > which is different from what is was really > {10@50 . 20@50} > or Array new: 2 at:1 put: 10@50 ; at:2 put: 20@50 > > So when an object is selfevaluating it measn that its printed > representation can be used to recreate it > When an array contains only self evaluating objects then it is printed > with { } since it can also be recreated > now if you get an object inside an array taht is not self evaluating > then your collection cannot be self evaluating. > so we say it anarray of ... instead of a #( 10 # @ 20....) > > But in your case something went wrong because color and others are > self evaluating. > could you provide with a snippet of code that we can check where the > problem is coming from? > > Stef > > > On Oct 27, 2009, at 10:58 PM, nullPointer wrote: > > > > > I donÂ´t understand the behavior of printString method. > > > > in a class I define a method #style , which returns an array... > > > > style > > > > style notNil ifTrue:[ ^style ] > > ifFalse:[ ^{ self borderColor . self borderWidth . self color . > > self > > gradientColor . (self cornerStyle = #rounded) . true }]. > > > > That method returns many times an Array. If #printString of that > > array is > > called the result is... > > '{Color black. 0. (Color r: 0.892 g: 0.887 b: 0.879). nil. false. > > true}' > > > > > > Well i have another method with same name in another class > > > > style > > > > ^{ self borderColor . self borderWidth . self color . self > > gradientColor . > > (self cornerStyle = #rounded) . true } > > > > > > but in that case when i call #printString of the Array result ... > > 'an Array(Color transparent 0 (Color r: 0.827 g: 0.827 b: 0.827) nil > > true > > true)'. > > > > I donÂ´t understand nothing :| Both are instances of Array, and both > > is > > declared of same way. > > > > > > Regards > > > > > > -- > > View this message in context: http://n2.nabble.com/Strange-behavior-of-printString-method-tp3902051p39020… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > View this message in context: Re: [Pharo-project] Strange behavior > of #printString method > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 28, 2009

Re: [Pharo-project] issue 496: Morph>>heading

by Laval Jannik

So, Is anyone use the rotation in pharo-Core ? If not, I will remove it. And I will try to put it in another package, which will be loaded after. Jannik On Oct 26, 2009, at 19:11 , StÃ©phane Ducasse wrote: > jannik > > you ask the right question > And this is ugly. Now we could think about possible usecases. > If we build a image processing system: we need it but in that case we > can copy it. > > Stef > > >> Yes, Marcus is right. >> >> But are there some behaviors that we want to keep and integrate in >> Core ? >> For example, the Rotate functionality in the halo. >> >> Cheers, >> Jannik >> >> >> On Oct 26, 2009, at 16:22 , Marcus Denker wrote: >> >>> >>>> >>>>> However, it would be a good idea to put all the interesting eToy >>>>> stuff in an external package so that those who want to load that >>>>> stuff, are able to do it. >>>> >>>> >>>> >>>> Because, make an external package of it needs a big work... >>>> >>>> I don't think so. >>> >>> Etoy is more complex than you think. It would be (nearly) >>> impossible. >>> >>> >>>> You just need to create the package. And then, instead of removing >>>> code, you move it to that package. What can be a lot of work is to >>>> keep that package up to date and working, but that's not Pharo >>>> responsibility. >>>> >>> Nope. Etoy is programed in a way that makes things like this *a >>> lot* of work. >>> >>> >>> Marcus >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 28, 2009

[Pharo-project] Linux FFI question: library given function name?

by Schwab,Wilhelm K

Hello all, In the short term, I'm looking for where I might find syslog() and friends, but a fishing lesson would be even better. How does one figure out in which library a named function lives? Bill

Oct. 27, 2009

Re: [Pharo-project] NewCompiler for pharo?

by Michael van der Gulik

On Mon, Oct 26, 2009 at 10:37 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Hi > > I would really like to know the status of the newcompiler for pharo? > > - when do you think we will be able to use it? > - what is left to do? > - how can people help? > - is there a way to get something compiled in between? > > so I go back to preclosure or just hack the old compiler? > Stef > Hi Stef. I'll be a user of the NewCompiler (for SecureSqueak) so I have an interest in it, to the point of fixing it if it doesn't work. This will probably happen in 6 months time or so. In particular, I am planning to use the IR (in NewCompiler-IR) as a format for sending code across a network connection in my projects. This will be part of SecureSqueak's core architecture and stored with classes, so it must be perfect. Gulik. -- http://gulik.pbwiki.com/

Oct. 27, 2009

Re: [Pharo-project] Strange behavior of #printString method

by nullPointer

The problem is in the Transparent color element of the my bad array. Transparent color class implements #isSelfEvaluating of that way... isSelfEvaluating ^ self class == Color That condition dont works in the first element of my bad array. Regards, and thanks for the help :| 2009/10/27 StÃ©phane Ducasse [via Smalltalk] < ml-node+3902115-101729205(a)n2.nabble.com<ml-node%2B3902115-101729205(a)n2.nabble.com> > > Apparently you find a problem in self evaluating on color or related. > Let me explain: > > The idea of printing an object is that in some case > anObject printString let you recreate the object > example > > 1 > true > #(1) > #(1 2) > 10@50 > > this means that either you get the same object or when you executed > its printed representation you get it back. > This is handy when playing with an inspector or in a workspace > > now for array if you get an array of points in the past > printing it would return > #(10 #@ 50 20 #@ 50) > > which is different from what is was really > {10@50 . 20@50} > or Array new: 2 at:1 put: 10@50 ; at:2 put: 20@50 > > So when an object is selfevaluating it measn that its printed > representation can be used to recreate it > When an array contains only self evaluating objects then it is printed > with { } since it can also be recreated > now if you get an object inside an array taht is not self evaluating > then your collection cannot be self evaluating. > so we say it anarray of ... instead of a #( 10 # @ 20....) > > But in your case something went wrong because color and others are > self evaluating. > could you provide with a snippet of code that we can check where the > problem is coming from? > > Stef > > > On Oct 27, 2009, at 10:58 PM, nullPointer wrote: > > > > > I donÂ´t understand the behavior of printString method. > > > > in a class I define a method #style , which returns an array... > > > > style > > > > style notNil ifTrue:[ ^style ] > > ifFalse:[ ^{ self borderColor . self borderWidth . self color . > > self > > gradientColor . (self cornerStyle = #rounded) . true }]. > > > > That method returns many times an Array. If #printString of that > > array is > > called the result is... > > '{Color black. 0. (Color r: 0.892 g: 0.887 b: 0.879). nil. false. > > true}' > > > > > > Well i have another method with same name in another class > > > > style > > > > ^{ self borderColor . self borderWidth . self color . self > > gradientColor . > > (self cornerStyle = #rounded) . true } > > > > > > but in that case when i call #printString of the Array result ... > > 'an Array(Color transparent 0 (Color r: 0.827 g: 0.827 b: 0.827) nil > > true > > true)'. > > > > I donÂ´t understand nothing :| Both are instances of Array, and both > > is > > declared of same way. > > > > > > Regards > > > > > > -- > > View this message in context: > http://n2.nabble.com/Strange-behavior-of-printString-method-tp3902051p39020… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email]<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3902115&i=0> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email]<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3902115&i=1> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ------------------------------ > View message @ > http://n2.nabble.com/Strange-behavior-of-printString-method-tp3902051p39021… > To unsubscribe from Strange behavior of #printString method, click here< (link removed) >. > > > -- View this message in context: http://n2.nabble.com/Strange-behavior-of-printString-method-tp3902051p39023… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 27, 2009

Re: [Pharo-project] Making packages shipped with Pharo ready for 1.0

by StÃ©phane Ducasse

On Oct 27, 2009, at 10:45 PM, Schwab,Wilhelm K wrote: > Stef, > > I do not yet use Nile, but after learning a little more about the > existing file streams, my first thought was "Nile is installed, > right?" It would be a shame to see it removed. Yes but we should fix the tests. Stef

Oct. 27, 2009

Re: [Pharo-project] Strange behavior of #printString method

by StÃ©phane Ducasse

Apparently you find a problem in self evaluating on color or related. Let me explain: The idea of printing an object is that in some case anObject printString let you recreate the object example 1 true #(1) #(1 2) 10@50 this means that either you get the same object or when you executed its printed representation you get it back. This is handy when playing with an inspector or in a workspace now for array if you get an array of points in the past printing it would return #(10 #@ 50 20 #@ 50) which is different from what is was really {10@50 . 20@50} or Array new: 2 at:1 put: 10@50 ; at:2 put: 20@50 So when an object is selfevaluating it measn that its printed representation can be used to recreate it When an array contains only self evaluating objects then it is printed with { } since it can also be recreated now if you get an object inside an array taht is not self evaluating then your collection cannot be self evaluating. so we say it anarray of ... instead of a #( 10 # @ 20....) But in your case something went wrong because color and others are self evaluating. could you provide with a snippet of code that we can check where the problem is coming from? Stef On Oct 27, 2009, at 10:58 PM, nullPointer wrote: > > I donÂ´t understand the behavior of printString method. > > in a class I define a method #style , which returns an array... > > style > > style notNil ifTrue:[ ^style ] > ifFalse:[ ^{ self borderColor . self borderWidth . self color . > self > gradientColor . (self cornerStyle = #rounded) . true }]. > > That method returns many times an Array. If #printString of that > array is > called the result is... > '{Color black. 0. (Color r: 0.892 g: 0.887 b: 0.879). nil. false. > true}' > > > Well i have another method with same name in another class > > style > > ^{ self borderColor . self borderWidth . self color . self > gradientColor . > (self cornerStyle = #rounded) . true } > > > but in that case when i call #printString of the Array result ... > 'an Array(Color transparent 0 (Color r: 0.827 g: 0.827 b: 0.827) nil > true > true)'. > > I donÂ´t understand nothing :| Both are instances of Array, and both > is > declared of same way. > > > Regards > > > -- > View this message in context: http://n2.nabble.com/Strange-behavior-of-printString-method-tp3902051p39020… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 27, 2009