- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Problem with TransformationMorph

by Lukas Renggli

Yeah, it is the same bug in Pharo 1.0 and 1.1 Lukas On 26 March 2010 09:31, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > lukas > > did you check in the latest version of squeak because I saw some fixes about put Morph in TextMorph? > Also in Cuis 2.0 because I imagine that juan got the same transformation. Now it seems that he changed that. > > Stef > On Mar 26, 2010, at 8:58 AM, Lukas Renggli wrote: > >> I noticed a problem with transformation morphs and created a bug report: >> >> Â http://code.google.com/p/pharo/issues/detail?id=2207 >> >> The problem seems to be that the transformation morph creates a black >> rectangle on the rotated clipping bounds. I does not only happen with >> TextMorphs but also with (some) other morphs. I tried to convert the >> TextMorph to a SketchMorph and the same happens there. I have no idea >> how to fix that problem. I need a solution because eCompletion rotates >> some text by 90, which is currently not possible. >> >> | stringMorph transformationMorph | >> stringMorph := 'vertical text' asMorph. >> transformationMorph := TransformationMorph new asFlexOf: stringMorph. >> transformationMorph angle: Float pi / 2. >> transformationMorph position: 5@5. >> transformationMorph openInWorld. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

March 26, 2010

Re: [Pharo-project] Help system question / monticello

by StÃ©phane Ducasse

Excellent idea. I do not know where is the story about the help system. I would like something extremely simple. Published in the pharo inbox and I will merge it. On Mar 25, 2010, at 7:40 PM, Michael Roberts wrote: > Hi, based on Lukas' recent blog post about Monticello merging, I > created some help system classes for this content. What is the best > way to integrate this? We have our own version of Monticello in the > Pharo repository. Which package, would we add it to? Or do we want to > add it upstream somewhere? > > Also, has anyone thought or spiked some simple formatting? that would > be really nice. > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 26, 2010

Re: [Pharo-project] Stateful Traits Literature

by StÃ©phane Ducasse

> >> Alex >> >> the context in which the solution were made is as important as the solution.... >> >>> I agree. Most of our extensions are really complex. >>> >>> In my opinion, traits must define variable. Else it defeats the whole purpose of having a better modularity. Each time I use traits, I need variables. >>> >>> The solution of Visualworks was quite simple, and I think it makes sense in most of the practical cases: when you compose traits, you simply concatenate the variables defined in the composed traits with the variables defined in the class. Duplicated names are then removed. Easy. >> >> you can only do that if you recompile the complete method so that offsets are aligned between the class format >> and the instance variable use in the method and you have one method per trait usage. >> >> So what I like in the first trait model is that methods were share so you got reuse for FREE. >> >> > So I wonder if we should not think about late-binding ivar names to offsets... yes that would be cool > The thing is that this can only change when you change class structure, which does not happen often. > > For Reflectivity, we did an experimental "in Image" AST->BC "JIT", where things like that happend automatically. > (you can just invalidate the CM cache on any change in the class hierarchy). > > I guess one could come up with a more low-level story that would be less intrusive but nevertheless would > allow for late-binding the offsets. For me I would like to play with that with first class instance variables. >

March 26, 2010

Re: [Pharo-project] Problem with TransformationMorph

by StÃ©phane Ducasse

lukas did you check in the latest version of squeak because I saw some fixes about put Morph in TextMorph? Also in Cuis 2.0 because I imagine that juan got the same transformation. Now it seems that he changed that. Stef On Mar 26, 2010, at 8:58 AM, Lukas Renggli wrote: > I noticed a problem with transformation morphs and created a bug report: > > http://code.google.com/p/pharo/issues/detail?id=2207 > > The problem seems to be that the transformation morph creates a black > rectangle on the rotated clipping bounds. I does not only happen with > TextMorphs but also with (some) other morphs. I tried to convert the > TextMorph to a SketchMorph and the same happens there. I have no idea > how to fix that problem. I need a solution because eCompletion rotates > some text by 90, which is currently not possible. > > | stringMorph transformationMorph | > stringMorph := 'vertical text' asMorph. > transformationMorph := TransformationMorph new asFlexOf: stringMorph. > transformationMorph angle: Float pi / 2. > transformationMorph position: 5@5. > transformationMorph openInWorld. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 26, 2010

Re: [Pharo-project] Stateful Traits Literature

by Marcus Denker

On Mar 26, 2010, at 9:23 AM, StÃ©phane Ducasse wrote: > Alex > > the context in which the solution were made is as important as the solution.... > >> I agree. Most of our extensions are really complex. >> >> In my opinion, traits must define variable. Else it defeats the whole purpose of having a better modularity. Each time I use traits, I need variables. >> >> The solution of Visualworks was quite simple, and I think it makes sense in most of the practical cases: when you compose traits, you simply concatenate the variables defined in the composed traits with the variables defined in the class. Duplicated names are then removed. Easy. > > you can only do that if you recompile the complete method so that offsets are aligned between the class format > and the instance variable use in the method and you have one method per trait usage. > > So what I like in the first trait model is that methods were share so you got reuse for FREE. > > So I wonder if we should not think about late-binding ivar names to offsets... The thing is that this can only change when you change class structure, which does not happen often. For Reflectivity, we did an experimental "in Image" AST->BC "JIT", where things like that happend automatically. (you can just invalidate the CM cache on any change in the class hierarchy). I guess one could come up with a more low-level story that would be less intrusive but nevertheless would allow for late-binding the offsets. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 26, 2010

Re: [Pharo-project] Stateful Traits Literature

by StÃ©phane Ducasse

Exact and you can have real problems! Stef > Hi Alexandre: > > > On 25 Mar 2010, at 23:26, Alexandre Bergel wrote: >> The solution of Visualworks was quite simple, and I think it makes sense in most of the practical cases: when you compose traits, you simply concatenate the variables defined in the composed traits with the variables defined in the class. Duplicated names are then removed. Easy. > Ehm, what does that exactly mean? > > The resulting class will have a set of instance variables where the name is the identity criterion of the set? > > A PHP example would look like: > > class Base{ > var $a; > } > > trait T1 { > var $a; > var $b; > } > > trait T2 { > var $a; > var $c; > } > > class Composite extends Base { > use T1, T2; > } > > and Composite would have the instance variables $a, $b, $c. > The problem would be of course that Base, T1, and T2 could use $a for completely different things. > > Simple, but at the cost of composability/safety. > This semantics is also that of my proposal for PHP. > > Best regards > Stefan > >> >> Cheers, >> Alexandre >> >> >> On 25 Mar 2010, at 17:19, Stefan Marr wrote: >> >>> Hi Alexandre: >>> >>> >>> Thanks. >>> I have read all these papers already, but kind of hoped that there is something I missed so far. >>> >>> On 25 Mar 2010, at 23:00, Alexandre Bergel wrote: >>>> "Stateful Traits and their Formalization" http://scg.unibe.ch/scgbib?_k=OiaJOIuA&query=Berg08e&display=abstract >>>> => It describes stateful traits >>>> >>>> "User-Changeable Visibility: Resolving Unanticipated Name Clashes in Traits" http://scg.unibe.ch/scgbib?_k=NNRwidu5&query=freezable+traits&display=abstr… >>>> =>Freezable traits >>>> >>>> "Adding State and Visibility Control to Traits using Lexical Nesting" http://scg.unibe.ch/scgbib?_k=J-wbMltV&query=tom+cutsem+bergel >>>> => Traits for a class-less language >>> My problem is, that these proposals involve a lot additional complexity. >>> And, Tom's paper is not really applicable to PHP. PHP just does not have a real notion of lexical context. >>> >>> Thanks >>> Stefan >>> >>> >>> >>> -- >>> Stefan Marr >>> Software Languages Lab >>> Vrije Universiteit Brussel >>> Pleinlaan 2 / B-1050 Brussels / Belgium >>> http://soft.vub.ac.be/~smarr >>> Phone: +32 2 629 2974 >>> Fax: +32 2 629 3525 >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 26, 2010

Re: [Pharo-project] Stateful Traits Literature

by StÃ©phane Ducasse

Alex the context in which the solution were made is as important as the solution.... > I agree. Most of our extensions are really complex. > > In my opinion, traits must define variable. Else it defeats the whole purpose of having a better modularity. Each time I use traits, I need variables. > > The solution of Visualworks was quite simple, and I think it makes sense in most of the practical cases: when you compose traits, you simply concatenate the variables defined in the composed traits with the variables defined in the class. Duplicated names are then removed. Easy. you can only do that if you recompile the complete method so that offsets are aligned between the class format and the instance variable use in the method and you have one method per trait usage. So what I like in the first trait model is that methods were share so you got reuse for FREE. Now if you remove this constraint (which is a huge one) and you recompile the method then you can get variable. Now the next important question which is not solve in any of the work is how to initialize traits state in an elegant way. Now in pharo since we duplicate the methods use by traits we can have variable without problem (but we need to recompile the method at composition time). Stef

March 26, 2010

Re: [Pharo-project] Pharo book looking for editors and a Pier guy :)

by StÃ©phane Ducasse

Thanks. Doru is helping making sure that we will get a pier in good shape. After we give some editors accounts and everybody is welcome with its own time constraints. Stef On Mar 25, 2010, at 11:36 PM, GermÃ¡n Arduino wrote: > Hi: > > I could help a bit with Pier, being that I already maintain other Pier > sites, but of course I'm not good at graphics and so :) > > I mean I can help installing, administering (persistency/users/server > stuff/etc), checking that it works and doing some other techie work. > > Also I did several things on 2007 compiling the VM of Squeak (for > Windoze) to a specific customer, I can revise my notes of such moment > and try to help also with this stuff. > > But not sure on what time frame, so if you can wait my free times, > count me to some of the things mentioned before.... > > Cheers. > GermÃ¡n. > > > 2010/3/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi all >> >> Gemstone nicely offered to host the equivalent of http://book.seaside.st for Pharo. >> A not well-skinned version is available at http://book.pharo-project.org >> >> The idea is that we do not want to have 100% open wiki but we want to have a web site >> that the community can use to build a living documentation that can be turned into a book. >> For that we will need some editors ie people willing to write and take into accounts >> comments made other on certain topics. >> >> I can be one of these but we need more :) >> You do not have to enroll for everything >> >> I dream to have a presentation on how to compile the vm :) for example >> on mac >> on linux >> on Windows >> >> >> Now since I'm bad with pier (Pier is out of my reach) I need people to take over. >> I succeeded to break the current installation but I would say that this is not my fault :) >> >> Stef >> >> >> >> _______________________________________________ >> 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

March 26, 2010

Re: [Pharo-project] How to easily intercept messages sent to ALL objects ?

by Marcus Denker

On Mar 25, 2010, at 5:50 PM, Mariano Martinez Peck wrote: > Hi folks. I want to intercept (and do something) for all objects. I know few approaches, for example: > > 1) using method wrappers (implementing run: aSelector with: arguments in: aReceiver) I can wrap all compiled methods of all classes and there I have the receiver. > > 2) become all objects to some kind of hacky object that stores the original object and that redefines the doesNotUnderstand: > > But in 1) I need to change all CompiledMehtod of all classes. > in 2) I have to become all the objects to another object > > Then my question is, is there an easier way to intercept all messages send to all objects from the image side (not going to vm) and with a lower cost ? No. So the MOP (meta object protocol), the "reflective API" of Smalltalk does not allow for "reifying" message receive. Historically, after Reflection was discovered and people started to generalize it, of cource they added that. For example, there is CODA: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108.6885&rep=rep1&… which made the whole "message send" explicit and interceptable. This means it is decomposed into Send, Receive, Lookup, Apply. Very nice. Very general. One can override Lookup when one wants to do e.g. Multiple inheritance. Or Apply, when the language of the method is not smalltalk. Or Receive, if you want to hook into "does an object get a message?". Futures, non-blocking messages. All easy to be done. But: it's slow. Dog slow. So people started to think about: how to speed up? Sadly the idea of optimizing at runtime (partially evaluating the MOP) has seen not much work. What was done is "partial reflection": only reifiy those opereation at exactly those spots that one is interested in. This was done in MetaClassTalk (it checks if the MetaClass overrides message sending, else it uses normal bytecodes) and to the extreme in Reflex. Now if you want to change reflective behavior *per object* the other important thing is that you need to be able to define changed behavior at the level of Objects vs. Classes. CLOS style MOPS like MetaClassTalk allow *only* for a per-Class-change. Enter Eric Tanter's Relex. Reflex generalized the MOP idea to not be bound to classes/metaclasses but you can select *per instruction* what to reify. And that reification is only done when needed, keeping the code you are not interested in fast. (Reflex is what happens when you bring the lessons of AOP back into MOPs. That is, the good parts of AOP). http://portal.acm.org/citation.cfm?id=949309 Of course, message receive is not easy to achive other than reifying method-execute on all methods+doesNotUnderstand. This can be made a bit more efficient for all the objects of the class you are not interested in by using Object-specific Behavior (the anonymous subclass trick). Phillippe did that in TreeNurse... But all in all, this is more of a hack. Now for message receive, one could imagine a partial reification scheme: a tag bit on the object header, if it is there, the VM calls a receive method instead of the method that would originally be called. So you would pay, in all casses, one bit-check on message send *and* you need space to put this flag. Would anyone want to pay that? In general, I would like to experiment with a MOP that can reify message receive in a meaningful *and efficient* way. But the current VM can't do it. In addition, there is always the problem that reflection leads to loops (your code will use the code it will used on). http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf Wich needs to be solved, too, if you ever want to be able to use reflection on everything (even the things you implement reflectively). Alternatively, one could use a proxy. Now if you don't use a subclass of ProtoObject, but something with VM support int the Style of Adrian Lienhard's Aliases: http://scg.unibe.ch/archive/papers/Lien08bBackInTimeDebugging.pdf or the Handle (we need a better word!!!) stuff that JB is working on, maybe this would not be too bad. The Alias is *hidden*, you can put it (eventually, after all engineering done) on any object (even Integers)... and than, after you swap out something, you need a proxy anyway for the "outpointer". > And if going to vm, how ? The OOPSLA paper of 2008 on tolerating memory leaks has scheme where they use the GC of Jikes. So compared to LOOM, they have a modern GC without an object table, and it seems much simpler. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 26, 2010

[Pharo-project] Problem with TransformationMorph

by Lukas Renggli

I noticed a problem with transformation morphs and created a bug report: Â http://code.google.com/p/pharo/issues/detail?id=2207 The problem seems to be that the transformation morph creates a black rectangle on the rotated clipping bounds. I does not only happen with TextMorphs but also with (some) other morphs. I tried to convert the TextMorph to a SketchMorph and the same happens there. I have no idea how to fix that problem. I need a solution because eCompletion rotates some text by 90, which is currently not possible. | stringMorph transformationMorph | stringMorph := 'vertical text' asMorph. transformationMorph := TransformationMorph new asFlexOf: stringMorph. transformationMorph angle: Float pi / 2. transformationMorph position: 5@5. transformationMorph openInWorld. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 26, 2010