[Pharo-project] Problem with TransformationMorph
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] How to easily intercept messages sent to ALL objects ?
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.6885rep=rep1type=pdf 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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo book looking for editors and a Pier guy :)
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.duca...@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Stateful Traits Literature
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Stateful Traits Literature
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=OiaJOIuAquery=Berg08edisplay=abstract
= It describes stateful traits
User-Changeable Visibility: Resolving Unanticipated Name Clashes in
Traits
http://scg.unibe.ch/scgbib?_k=NNRwidu5query=freezable+traitsdisplay=abstract
=Freezable traits
Adding State and Visibility Control to Traits using Lexical Nesting
http://scg.unibe.ch/scgbib?_k=J-wbMltVquery=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@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@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@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Stateful Traits Literature
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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Problem with TransformationMorph
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Stateful Traits Literature
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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Problem with TransformationMorph
Yeah, it is the same bug in Pharo 1.0 and 1.1 Lukas On 26 March 2010 09:31, Stéphane Ducasse stephane.duca...@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Problem with TransformationMorph
It's not fixed in Squeak. WarpBlt does not work with alpha 0 1. Another example is rotating a systemwindow (from the halo menu), its dropshadow will be pure black. (i.e. all non-transparent pixels are rendered with their pure RGB component) Cheers, Henry (TransformationMorph is removed in Cuis 2.3, rotate halo button is there, but not working) On Mar 26, 2010, at 9:31 39AM, Stéphane Ducasse 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Problem with TransformationMorph
Hmmm, are you running on the latest VM's? With Pharo 1.1 and squeak 4.1, on both OSX and Windows I do not get black rectangles, but expanded black areas like attached. Cheers, Henry inline: verticalText.png On Mar 26, 2010, at 10:41 42AM, Lukas Renggli wrote: It's not fixed in Squeak. WarpBlt does not work with alpha 0 1. Another example is rotating a systemwindow (from the halo menu), its dropshadow will be pure black. (i.e. all non-transparent pixels are rendered with their pure RGB component) Ok, but what does this mean exactly? Previously it was possible to have rotated text. When rotating text it now shows the complete bounding box in black, not just the aliased borders. Lukas Cheers, Henry (TransformationMorph is removed in Cuis 2.3, rotate halo button is there, but not working) On Mar 26, 2010, at 9:31 39AM, Stéphane Ducasse 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Problem with TransformationMorph
2010/3/26 Henrik Johansen henrik.s.johan...@veloxit.no: Hmmm, are you running on the latest VM's? I am using the Squeak4.2.2beta1 VM on OS X. The vertical text example looks like in the attached file. Lukas -- Lukas Renggli http://www.lukas-renggli.ch attachment: vertical-text.png___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Problem with TransformationMorph
Ahh, with Squeak4.2.3beta1 I get the same as you. Not perfect, but already better. Any idea how the ugly expanded areas can be fixed? Lukas On 26 March 2010 11:06, Lukas Renggli reng...@gmail.com wrote: 2010/3/26 Henrik Johansen henrik.s.johan...@veloxit.no: Hmmm, are you running on the latest VM's? I am using the Squeak4.2.2beta1 VM on OS X. The vertical text example looks like in the attached file. Lukas -- Lukas Renggli http://www.lukas-renggli.ch -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.1] #11296
On Mar 26, 2010, at 10:27 34AM, Alain Plantec wrote: Stéphane Ducasse a écrit : 11296 - Issue 2208: Preferences setting * range setting: bad widget height in the SettingBrowser * improve TimeProfiler (MorphTreeMorph example) Few words about that: TimeProfiler is a improvement of the current TimeProfileBrowser. just try it: TimeProfiler new openOnBlock: [ 10 timesRepeat: [Transcript show: 'n' asString, String cr]]. or simply TimeProfiler new open and then type-in the code you want to profile. For now, it is in the Morphic-MorphTreeWidget-Examples sys cat, maybe it can replace TimeProfileBrowser in the core. what do you think ? Cheers Alain Absolutely 3 it! How about a Start profiling (Stop profiling when clicked) button as well, providing functionality equal to the Start profiling... options from the debug menu? I'd replace it in a heartbeat already tbh, with that extra button, we could reduce it to a single entry for profiling in the debug menu :) Cheers, Henry PS. Anyone know a better naming for Start drawing again ? I always wondered how you are supposed to access that if you've stopped drawing, afaik it resets the drawError property of the World (aka. PasteUpMorph) so it starts drawing normally again instead of something crossed out red. It is not done for submorphs, so it's not a convenient way of resetting all drawstates, do we really get drawErrors often enough in the PasteUpMorph itself to warrant this item?? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Problem with TransformationMorph
On Mar 26, 2010, at 11:11 47AM, Lukas Renggli wrote: Ahh, with Squeak4.2.3beta1 I get the same as you. Not perfect, but already better. Any idea how the ugly expanded areas can be fixed? Lukas If the text background color is consistent, it should be fakeble in image. Otherwise I'd reckon it requires more BitBlt fixes. Look at the text in a rotated browser first, that's the result you can expect. Basic way would be to instead of rendering the text glyphs rotated, render the glyphs on top of a bitmap of the proper rotated background, then rotate that opaque bitmap instead. Not a perfect solution by any means, but it can be done if you're desperate enough... waiting for VM fixes can take a long time :( Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.1] #11296
gorgeous! Stef Stéphane Ducasse a écrit : 11296 - Issue 2208: Preferences setting * range setting: bad widget height in the SettingBrowser * improve TimeProfiler (MorphTreeMorph example) Few words about that: TimeProfiler is a improvement of the current TimeProfileBrowser. just try it: TimeProfiler new openOnBlock: [ 10 timesRepeat: [Transcript show: 'n' asString, String cr]]. or simply TimeProfiler new open and then type-in the code you want to profile. For now, it is in the Morphic-MorphTreeWidget-Examples sys cat, maybe it can replace TimeProfileBrowser in the core. what do you think ? Cheers Alain Time profiler.png___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Problem with TransformationMorph
On Mar 26, 2010, at 11:37 27AM, Lukas Renggli wrote: If the text background color is consistent, it should be fakeble in image. Otherwise I'd reckon it requires more BitBlt fixes. Ok, converting the string morph to a bitmap works indeed. The text is readable. However the transparency does not work. I hope the VM gets fixed :-) Look at the text in a rotated browser first, that's the result you can expect. Basic way would be to instead of rendering the text glyphs rotated, render the glyphs on top of a bitmap of the proper rotated background, then rotate that opaque bitmap instead. Not a perfect solution by any means, but it can be done if you're desperate enough... waiting for VM fixes can take a long time :( Are there any examples for that? Lukas CornerRounder works this way. These are the basic steps (performed in method roundCornersOf: on: in: displayBlock: borderWidth: corners: ) 1. copy bits below to a bitmap. 2. render normal corner to bitmap 2. 3. mask out the rounded bits in bitmap 2. 4. render bitmap2 on top of bitmap1. 5. display the composite on screen. You'd probably skip 2 and 3 for text, replace 4 with render text, and add: 2. rotate bits -X degrees 4.5 rotate bits X degrees. Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Hello squeakers
Hi guys I decided to send this mail with my name because I believe that. I asked marcus and adrian to look at it but it only engage me and not you. I thought that it was important for me to say something :) Stef On Mar 26, 2010, at 12:17 PM, stephane ducasse wrote: Dear Squeakers I want to send you a message because I estimate Squeakers and I want to open the door to see how new relationship can be build. So consider that as an open hand - even if my english may let you think otherwise. First, Pharo is not against Squeak. We forked because we believed that we could not make Squeak move in any coherent direction. We are sure that you understand our reasons. Just think a moment about the amount of time and energy we invested in Squeak in the past (I wrote more than anybody else books on squeak, build tutorials, lecture support, videos- with esug over the years we spent more than 30 kEuros in Squeak related actions) so deciding to go for Pharo was not an easy choice but a necessary one: At one point I was thinking to quit Smalltalk and go to see Ruby and Python for real. Pharo is the only way that I get back my fun in Smalltalk. So what are my dreams? For Pharo == We want a clean, lean and fast Smalltalk. An implementation that makes other dynamic language jealous. We want a place where we/you can innovate. We want people to be able to invent THEIR future. We want a place where people can make money with it and build robust applications. Being able to experiment fast is important but for that the system should be clean, robust and flexible. Having a platform for experimentation requires that the platform is not experimental. About innovation I mean in no order: Support for multitouch screen, bootstrappable Smalltalk, immutability bit and its impact, ephemerons, new module system?, first class instance variables, using traits for real (like in ruby where any class can be a model without inheriting from model), VAT-like system?, event system like in AmbiantTalk?, I put ? because some of these should be implemented assessed tested... and understood deeply. About clean Clean network, clean event system, clean object kernel, better compiler (open - we got first class instance variable with no runtime penalties in one afternoon). Clean class builder... Now enough about Pharo. http://www.pharo-project.org/ About Etoys I love Etoys (we translated the book and did more presentations of etoys than most squeakers) but I do not like its implementation. Why? Because it is bad. Any body that looks at it knows it. When I removed Etoys part from Pharo I'm sad but there is no other choices. Now it does not mean that I'm against Etoys and Etoys has the Etoys 40 image (note that we collected in 3.9 most of the etoys fixes with little support from Etoyers which forked way before, we did the same with the fixes of diego of Smalltalk). But again you can judge otherwise. About the ranting or the little war between Squeak and Pharo == Frankly I'm tired about us ranting against Squeak/andreas/... and the inverse. For example Traits are cool, Javascript and PHP will probably have them as Perl-6, Scala, Fortress. Now Squeak can remove them. I have no problem with that. Seriously this is your decision. People in squeak-dev can freely say negative points about me if this helps. I decided that I will not rant nor get negative feelings about that. I found the red pill :) *I* decided that I want to head to the future. So we will not rant nor make any bad statement about the past anymore. Not even report history or on old facts: if you were there you should remember, else there is the archive :). This is my last mail on the past. Frankly I have the best job I can dream about. I'm lucky just check my h-index for the fun, I have more than most researchers I know. In addition, I loved working and learning from people like lukas, adrian, nicolas, levente, marcus, . The next 10 years should be the best of my life and I will take advantage of that. I want to have **10/15** years of pure fun and I will do it. I want and will create positive energy. Look at ESUG we are doing a great job. About cross dialect energy = Now the key point of this mail. I **deeply** appreciate the attitude of people like nicolas, levente, and igor that do not bash us and help Pharo but also Squeak. I sent this message mainly because of their attitude. I'm sad to see all this (their) energy duplicated. We cleaned and improved a lot Pharo over the last two years (more than you may
Re: [Pharo-project] Hello squeakers
Hi Stef, i totally agree with the purpose and contents of the email. Just a remark, i don't know when you sent it. But i'm subscribed to the squeak-dev list and don't see your email posted. Maybe it's a problem with my account, but i think its worth asking if anyone else has received it. Fernando On Mar 26, 2010, at 12:19 PM, Stéphane Ducasse wrote: Hi guys I decided to send this mail with my name because I believe that. I asked marcus and adrian to look at it but it only engage me and not you. I thought that it was important for me to say something :) Stef On Mar 26, 2010, at 12:17 PM, stephane ducasse wrote: Dear Squeakers I want to send you a message because I estimate Squeakers and I want to open the door to see how new relationship can be build. So consider that as an open hand - even if my english may let you think otherwise. First, Pharo is not against Squeak. We forked because we believed that we could not make Squeak move in any coherent direction. We are sure that you understand our reasons. Just think a moment about the amount of time and energy we invested in Squeak in the past (I wrote more than anybody else books on squeak, build tutorials, lecture support, videos- with esug over the years we spent more than 30 kEuros in Squeak related actions) so deciding to go for Pharo was not an easy choice but a necessary one: At one point I was thinking to quit Smalltalk and go to see Ruby and Python for real. Pharo is the only way that I get back my fun in Smalltalk. So what are my dreams? For Pharo == We want a clean, lean and fast Smalltalk. An implementation that makes other dynamic language jealous. We want a place where we/you can innovate. We want people to be able to invent THEIR future. We want a place where people can make money with it and build robust applications. Being able to experiment fast is important but for that the system should be clean, robust and flexible. Having a platform for experimentation requires that the platform is not experimental. About innovation I mean in no order: Support for multitouch screen, bootstrappable Smalltalk, immutability bit and its impact, ephemerons, new module system?, first class instance variables, using traits for real (like in ruby where any class can be a model without inheriting from model), VAT-like system?, event system like in AmbiantTalk?, I put ? because some of these should be implemented assessed tested... and understood deeply. About clean Clean network, clean event system, clean object kernel, better compiler (open - we got first class instance variable with no runtime penalties in one afternoon). Clean class builder... Now enough about Pharo. http://www.pharo-project.org/ About Etoys I love Etoys (we translated the book and did more presentations of etoys than most squeakers) but I do not like its implementation. Why? Because it is bad. Any body that looks at it knows it. When I removed Etoys part from Pharo I'm sad but there is no other choices. Now it does not mean that I'm against Etoys and Etoys has the Etoys 40 image (note that we collected in 3.9 most of the etoys fixes with little support from Etoyers which forked way before, we did the same with the fixes of diego of Smalltalk). But again you can judge otherwise. About the ranting or the little war between Squeak and Pharo == Frankly I'm tired about us ranting against Squeak/andreas/... and the inverse. For example Traits are cool, Javascript and PHP will probably have them as Perl-6, Scala, Fortress. Now Squeak can remove them. I have no problem with that. Seriously this is your decision. People in squeak-dev can freely say negative points about me if this helps. I decided that I will not rant nor get negative feelings about that. I found the red pill :) *I* decided that I want to head to the future. So we will not rant nor make any bad statement about the past anymore. Not even report history or on old facts: if you were there you should remember, else there is the archive :). This is my last mail on the past. Frankly I have the best job I can dream about. I'm lucky just check my h-index for the fun, I have more than most researchers I know. In addition, I loved working and learning from people like lukas, adrian, nicolas, levente, marcus, . The next 10 years should be the best of my life and I will take advantage of that. I want to have **10/15** years of pure fun and I will do it. I want and will create positive energy. Look at ESUG we are doing a great job. About cross dialect energy = Now the key point of this
Re: [Pharo-project] [update 1.1] #11296
Very nice! Alexandre On 26 Mar 2010, at 06:47, Stéphane Ducasse wrote: gorgeous! Stef Stéphane Ducasse a écrit : 11296 - Issue 2208: Preferences setting * range setting: bad widget height in the SettingBrowser * improve TimeProfiler (MorphTreeMorph example) Few words about that: TimeProfiler is a improvement of the current TimeProfileBrowser. just try it: TimeProfiler new openOnBlock: [ 10 timesRepeat: [Transcript show: 'n' asString, String cr]]. or simply TimeProfiler new open and then type-in the code you want to profile. For now, it is in the Morphic-MorphTreeWidget-Examples sys cat, maybe it can replace TimeProfileBrowser in the core. what do you think ? Cheers Alain Time profiler.png___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Useless Netwoking classes?
On Mar 26, 2010, at 12:03 PM, Bouraqadi Noury wrote: On 24 mars 10, at 16:51, Marcus Denker wrote: On Mar 24, 2010, at 4:45 PM, Bouraqadi Noury wrote: InternetConfiguration this one is in the startup list, on Macos. It is then strange (bug) that I get an empty references set for it, especially that I'm on Mac too. The problem is that the class as an Object is registered with the startup logic. (someone called Smalltalk addToStartUpList: at some point in the past). This could be detected, a safe delete would check for: References, subclasses, instances and and known pointers like this. But in general, using reflection will give you situations where static analyis fails. e.g. (Smalltalk classNamed: 'Obj', 'ect') is a use of Object, but hard to detect, especially if the string is the result of some real computation. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Hello squeakers
Fernando olivero wrote: Hi Stef, i totally agree with the purpose and contents of the email. Just a remark, i don't know when you sent it. But i'm subscribed to the squeak-dev list and don't see your email posted. Maybe it's a problem with my account, but i think its worth asking if anyone else has received it. It came through: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147697.html regards, Göran ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Useless Netwoking classes?
On 24 mars 10, at 16:51, Marcus Denker wrote: On Mar 24, 2010, at 4:45 PM, Bouraqadi Noury wrote: InternetConfiguration this one is in the startup list, on Macos. It is then strange (bug) that I get an empty references set for it, especially that I'm on Mac too. Noury The idea is that it sets to proxy automatically considering that this is needed as SCG, just imagine how much good this class did for Squeak and Smalltalk (and Research! Humanity!) over the last 4 years... When I added it, people mentioned that it's not perfect and thus it should not be added to 3.9, but, as one can imagine, nothing better has been ever proposed. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Hello squeakers
Dear Squeakers I want to send you a message because I estimate Squeakers and I want to open the door to see how new relationship can be build. So consider that as an open hand - even if my english may let you think otherwise. First, Pharo is not against Squeak. We forked because we believed that we could not make Squeak move in any coherent direction. We are sure that you understand our reasons. Just think a moment about the amount of time and energy we invested in Squeak in the past (I wrote more than anybody else books on squeak, build tutorials, lecture support, videos- with esug over the years we spent more than 30 kEuros in Squeak related actions) so deciding to go for Pharo was not an easy choice but a necessary one: At one point I was thinking to quit Smalltalk and go to see Ruby and Python for real. Pharo is the only way that I get back my fun in Smalltalk. So what are my dreams? For Pharo == We want a clean, lean and fast Smalltalk. An implementation that makes other dynamic language jealous. We want a place where we/you can innovate. We want people to be able to invent THEIR future. We want a place where people can make money with it and build robust applications. Being able to experiment fast is important but for that the system should be clean, robust and flexible. Having a platform for experimentation requires that the platform is not experimental. About innovation I mean in no order: Support for multitouch screen, bootstrappable Smalltalk, immutability bit and its impact, ephemerons, new module system?, first class instance variables, using traits for real (like in ruby where any class can be a model without inheriting from model), VAT-like system?, event system like in AmbiantTalk?, I put ? because some of these should be implemented assessed tested... and understood deeply. About clean Clean network, clean event system, clean object kernel, better compiler (open - we got first class instance variable with no runtime penalties in one afternoon). Clean class builder... Now enough about Pharo. http://www.pharo-project.org/ About Etoys I love Etoys (we translated the book and did more presentations of etoys than most squeakers) but I do not like its implementation. Why? Because it is bad. Any body that looks at it knows it. When I removed Etoys part from Pharo I'm sad but there is no other choices. Now it does not mean that I'm against Etoys and Etoys has the Etoys 40 image (note that we collected in 3.9 most of the etoys fixes with little support from Etoyers which forked way before, we did the same with the fixes of diego of Smalltalk). But again you can judge otherwise. About the ranting or the little war between Squeak and Pharo == Frankly I'm tired about us ranting against Squeak/andreas/... and the inverse. For example Traits are cool, Javascript and PHP will probably have them as Perl-6, Scala, Fortress. Now Squeak can remove them. I have no problem with that. Seriously this is your decision. People in squeak-dev can freely say negative points about me if this helps. I decided that I will not rant nor get negative feelings about that. I found the red pill :) *I* decided that I want to head to the future. So we will not rant nor make any bad statement about the past anymore. Not even report history or on old facts: if you were there you should remember, else there is the archive :). This is my last mail on the past. Frankly I have the best job I can dream about. I'm lucky just check my h-index for the fun, I have more than most researchers I know. In addition, I loved working and learning from people like lukas, adrian, nicolas, levente, marcus, . The next 10 years should be the best of my life and I will take advantage of that. I want to have **10/15** years of pure fun and I will do it. I want and will create positive energy. Look at ESUG we are doing a great job. About cross dialect energy = Now the key point of this mail. I **deeply** appreciate the attitude of people like nicolas, levente, and igor that do not bash us and help Pharo but also Squeak. I sent this message mainly because of their attitude. I'm sad to see all this (their) energy duplicated. We cleaned and improved a lot Pharo over the last two years (more than you may think) and we will continue. Squeak could have benefitted from it. Nicolas luckily for you pushed a lot of our fixes in Squeak already. I'm getting the fixes of Squeak that are interesting for Pharo. Now depending on the Squeak vision we could share some common things. May be we can build
Re: [Pharo-project] [update 1.1] #11296
On Mar 26, 2010, at 1:19 53PM, Stéphane Ducasse wrote: Absolutely 3 it! DNU??? 3 = Heart As in, I 3 Huckabees How about a Start profiling (Stop profiling when clicked) button as well, providing functionality equal to the Start profiling... options from the debug menu? I'd replace it in a heartbeat already tbh, with that extra button, we could reduce it to a single entry for profiling in the debug menu :) :) We will have to think in terms of architecture and dependencies but it will be present. A few thoughts: - MessageTally is the model. Ditch opening CodeHolders and crap as a result of calling spyAllOn: and friends, return the raw instance after collection. - TimeProfile(r)(Browser) is the view. Convenience methods for opening browsers. Ditch constructing with report:cutoff; use the tally directly as model. - Define the menu item in TimeProfiler class. Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: [squeak-dev] Hello squeakers
Sorry, forgot reply-all -- Forwarded message -- From: Germán Arduino gardu...@gmail.com Date: 2010/3/26 Subject: Re: [squeak-dev] Hello squeakers To: The general-purpose Squeak developers list squeak-...@lists.squeakfoundation.org Hi Stef: I'm one of the guys being in both lists and trying to follow the two things and appreciating things of both and your mail is really very very good on my pov. I also appreciate the effort of people contributing with a positive attitude on Squeak AND Pharo, as the guys you mentioned. And don't forget Dale doing the same and several others. The Smalltalk community itself is so little, more little is the squeak/pharo and I think we can't afford not cooperate among us. I also vote for a long period of fun ahead, doing Squeak/Pharo or Pharo/Squeak :) Germán. 2010/3/26 Bert Freudenberg b...@freudenbergs.de: On 26.03.2010, at 12:17, stephane ducasse wrote: Dear Squeakers I want to send you a message because I estimate Squeakers and I want to open the door to see how new relationship can be build. So consider that as an open hand - even if my english may let you think otherwise. First, Pharo is not against Squeak. We forked because we believed that we could not make Squeak move in any coherent direction. We are sure that you understand our reasons. Just think a moment about the amount of time and energy we invested in Squeak in the past (I wrote more than anybody else books on squeak, build tutorials, lecture support, videos- with esug over the years we spent more than 30 kEuros in Squeak related actions) so deciding to go for Pharo was not an easy choice but a necessary one: At one point I was thinking to quit Smalltalk and go to see Ruby and Python for real. Pharo is the only way that I get back my fun in Smalltalk. So what are my dreams? For Pharo == We want a clean, lean and fast Smalltalk. An implementation that makes other dynamic language jealous. We want a place where we/you can innovate. We want people to be able to invent THEIR future. We want a place where people can make money with it and build robust applications. Being able to experiment fast is important but for that the system should be clean, robust and flexible. Having a platform for experimentation requires that the platform is not experimental. About innovation I mean in no order: Support for multitouch screen, bootstrappable Smalltalk, immutability bit and its impact, ephemerons, new module system?, first class instance variables, using traits for real (like in ruby where any class can be a model without inheriting from model), VAT-like system?, event system like in AmbiantTalk?, I put ? because some of these should be implemented assessed tested... and understood deeply. About clean Clean network, clean event system, clean object kernel, better compiler (open - we got first class instance variable with no runtime penalties in one afternoon). Clean class builder... Now enough about Pharo. http://www.pharo-project.org/ About Etoys I love Etoys (we translated the book and did more presentations of etoys than most squeakers) but I do not like its implementation. Why? Because it is bad. Any body that looks at it knows it. When I removed Etoys part from Pharo I'm sad but there is no other choices. Now it does not mean that I'm against Etoys and Etoys has the Etoys 40 image (note that we collected in 3.9 most of the etoys fixes with little support from Etoyers which forked way before, we did the same with the fixes of diego of Smalltalk). But again you can judge otherwise. About the ranting or the little war between Squeak and Pharo == Frankly I'm tired about us ranting against Squeak/andreas/... and the inverse. For example Traits are cool, Javascript and PHP will probably have them as Perl-6, Scala, Fortress. Now Squeak can remove them. I have no problem with that. Seriously this is your decision. People in squeak-dev can freely say negative points about me if this helps. I decided that I will not rant nor get negative feelings about that. I found the red pill :) *I* decided that I want to head to the future. So we will not rant nor make any bad statement about the past anymore. Not even report history or on old facts: if you were there you should remember, else there is the archive :). This is my last mail on the past. Frankly I have the best job I can dream about. I'm lucky just check my h-index for the fun, I have more than most researchers I know. In addition, I loved working and learning from people like lukas, adrian, nicolas, levente, marcus, . The next 10 years should be the best of my life and I will take advantage
Re: [Pharo-project] [squeak-dev] Hello squeakers
Hi guys! I for one am very glad to see Steph's post and appreciate both Pharo and Squeak. Sometimes Pharo seems to have lots of good stuff going, and sometimes Squeak does, especially lately. ESUG is probably my new personal yearly conference and it was great in Brest. I really love the whole energy around Pharo/ESUG. At the same time I am a long time squeak.org-er and will never leave, so I really like this open hand and I also like all efforts of sharing between the forks (including other forks, like Cobalt, Cuis, Teleplace etc). I alsp hope that we all, on *all* forks, know when to say Hey, perhaps we should check and sync this with the other forks?. At least *some* of our mechanisms are *very* important to try to keep in sync - like say Monticello and/or event mechanisms etc. Hopefully I will get time to spend on a new SqueakMap and Deltastreams - although I make no promises, but if and when I do, all forks are included as targets in my book :) regards, Göran PS. Super thanks to the people that currently work as bridges between trunk and Pharo - you know who you are! ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Student internships at INRIA
Hi, Besides Postdocs, PhDs and Engineers, we are looking for student interns. INRIA has a program for Students to work in a research group as an Intern. Application is open now. http://www-direction.inria.fr/international/PROGRAMMES/internship/indexAPPEL10.html More information in english: http://www-direction.inria.fr/international/Page_Programmes_en.php?prog=internships Subjects: http://www-direction.inria.fr/international/PHP/Internship/CandidatsII.php The ones of RMoD are: - Flexible Modules for Dynamic Languages - Layer Identification and Diagnotics - Trait-based Remodularisation - Minimal Smalltalk Runtime Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] How to easily intercept messages sent to ALL objects ?
On Fri, Mar 26, 2010 at 1:15 AM, Marcus Denker marcus.den...@inria.frwrote: 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.6885rep=rep1type=pdf 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? Perhaps we can be cleverer. What could we do if we introduced delegation into the language? Then we can add wrappers around objects and put the interception into the wrappers. This way there is no additional check. If one wants to intercept references to an object one creates a DNU wrapper and becomes the two objects. An execution model of delegation is that there are two slots for the receiver in a context, a state slot through which inst vars are accessed, and a self slot to which messages are sent. Normal sends merely duplicate the receiver into both slots. Delegating sends take state as an additional argument. An alternative model is to dispense with direct inst var access (assuming the JIT will inline simple accessors in PICs, or simply by virtue of the use of machine code render accessors affordable) and provide accessors for delegators that indirect through the delegate. 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:
Re: [Pharo-project] Stateful Traits Literature
On Mar 26, 2010, at 11:40 AM, Simon Denier wrote: On 25 mars 2010, at 23:26, Alexandre Bergel wrote: 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. Funny, I also need state when I use traits, but in a more conservative approach: by default, I prefer states to be separated and possibly duplicated. I think it's easier to notice that state needs to be shared than to notice a weird bug happens because state is shared in a wrong way. If you need state to be shared, it's easy to refactor the accessors to access the same state. But it's my completely insubstantial opinion Come on I like it. This is a cool remark. I will think about that. (it's a deal between sharing states to have easy consistency and having compatible constraints (pre/post conditions) on shared state) As for the argument with recompiling methods, it's the same deal right now because required methods need to be overridden right? The rule of thumb is that you should not access state directly, but only through pure accessors. So only pure accessors need to be recompiled. But the stuff discussed by Markus could be helpful. As for traitInitialization, I have my ideas but I guess there is no silver bullet. 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=OiaJOIuAquery=Berg08edisplay=abstract = It describes stateful traits User-Changeable Visibility: Resolving Unanticipated Name Clashes in Traits http://scg.unibe.ch/scgbib?_k=NNRwidu5query=freezable+traitsdisplay=abstract =Freezable traits Adding State and Visibility Control to Traits using Lexical Nesting http://scg.unibe.ch/scgbib?_k=J-wbMltVquery=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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green
Hi, Finally I've managed to build squeak vm rev. 2135 (current stable) with FT2Plugin which makes all tests green on Pharo 1.0 rc3 image on my machine :) If some Linux users can test it on their distro, thanks. The clean binary archive: http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-bin.tar.gz The generated source archive: http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-src.tar.gz PharoCore-1.0 + configured VMMaker 1.2 image (for new vm builders, to have a known working base): http://lolgzs.free.fr/pharo/squeak-vm/PharoCore-1.0-VMMaker-1.2.tar.gz To build from source archive: === wget http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-src.tar.gz tar -xvzf Squeak-3.11.3.2135-pharo-src.tar.gz cd Squeak-3.11.3.2135-pharo-src/ mkdir build cd build ../unix/cmake/configure make sudo make install Internal plugins: == UUIDPlugin External plugins: == ADPCMCodecPlugin AioPlugin AsynchFilePlugin B2DPlugin B3DAcceleratorPlugin BMPReadWriterPlugin BitBltPlugin CroquetPlugin DSAPrims DropPlugin FFTPlugin FT2Plugin FileCopyPlugin FilePlugin FloatArrayPlugin FloatMathPlugin GeniePlugin HostWindowPlugin JPEGReadWriter2Plugin JPEGReaderPlugin JoystickTabletPlugin Klatt LargeIntegers LocalePlugin MIDIPlugin Matrix2x3Plugin MiscPrimitivePlugin Mpeg3Plugin QuicktimePlugin RePlugin SecurityPlugin SerialPlugin SocketPlugin SoundCodecPrims SoundGenerationPlugin SoundPlugin Squeak3D SqueakFFIPrims StarSqueakPlugin SurfacePlugin UnixOSProcessPlugin XDisplayControlPlugin ZipPlugin Fun story: if you don't have SecurityPlugin, LocaleTesttestFontFullName deletes your image :) testFontFullName self debug: #testFontFullName | env dir | env := (Locale isoLanguage: 'ja') languageEnvironment. dir := FileDirectory on: SecurityManager default untrustedUserDirectory. [dir recursiveDelete] -- Cool !! on: Error do: [:e | e]. env fontFullName. self assert: dir exists Cheers, Laurent Laffont ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Error parsing XML File
Hi Fabrizo, I think you're in the right place to talk about that. I haven't been able to reproduce your error. I added a test: XMLParserTesttestNonUTF8Characters self shouldnt: [XMLDOMParser parseDocumentFrom: 'fooBean BLABLABLA Eidgenössisches Institut für BLABLALBLA/foo' readStream] raise: Error. It goes green in my image. Do you have a different way to get the readStream from the String? Cheers, Alexandre On 26 Mar 2010, at 12:14, Fabrizio Perin wrote: Hi, I was parsing an XML File with the last version of XML Parser (XML- Parser-JAAyer.68) and i get an error related to a not UTF-8 character that the parser found into the document. The XML document contains some german character: ![CDATA[SES: Bean BLABLABLA Eidgenössisches Institut für BLABLALBLA]] Actually i'm not sure if the error is which is in the UTF8TextConverter or something is wrong in the invokation from the parser. Anyway i parse several time the same document with older versions of the XML-Parser (XML-Parser-JAAyer.57) and it always works well. I'm not sure if the mailing list of Pharo is the right place to report this problem in the case i'm i'm sorry. Here the trace from the log: Error: Invalid utf8 input detected 26 March 2010 4:14:07 pm VM: Mac OS - intel - 1062 - Squeak3.8.1 of '28 Aug 2006' [latest update: #6747] Squeak VM 4.2.2b1 Image: Pharo-1.0-10515-rc3 [Latest update: #10515] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /Users/fabrizioperin/development/Pharo/WORKINGONNOW/ MooseJEE_64 Trusted Dir /foobar/tooBar/forSqueak/bogus Untrusted Dir /Users/fabrizioperin/Library/Preferences/Squeak/ Internet/My Squeak UTF8TextConverter(Object)error: Receiver: an UTF8TextConverter Arguments and temporary variables: aString:'Invalid utf8 input detected' Receiver's instance variables: an UTF8TextConverter UTF8TextConvertererrorMalformedInput Receiver: an UTF8TextConverter Arguments and temporary variables: Receiver's instance variables: an UTF8TextConverter UTF8TextConverternextFromStream: Receiver: an UTF8TextConverter Arguments and temporary variables: aStream: MultiByteFileStream: '/Users/fabrizioperin/development/ Pharo/WORKINGON...etc... character1: $¶ value1: 182 character2: $s value2: 115 unicode:nil character3: $s value3: 115 character4: nil value4: nil Receiver's instance variables: an UTF8TextConverter MultiByteFileStreamnext Receiver: MultiByteFileStream: '/Users/fabrizioperin/development/ Pharo/WORKINGONNOW/MooseJEE_64/src/...etc... Arguments and temporary variables: char: nil secondChar: nil state: nil Receiver's instance variables: XMLStreamReaderbasicNext Receiver: a XMLStreamReader Arguments and temporary variables: nextChar: nil Receiver's instance variables: stream: MultiByteFileStream: '/Users/fabrizioperin/development/ Pharo/WORKINGONN...etc... nestedStreams: nil peekChar: nil buffer: a WriteStream 'SES: Bean zum Einlesen und updaten der Stako relevanten ...etc... XMLStreamReadernext Receiver: a XMLStreamReader Arguments and temporary variables: nextChar: nil Receiver's instance variables: stream: MultiByteFileStream: '/Users/fabrizioperin/development/ Pharo/WORKINGONN...etc... nestedStreams: nil peekChar: nil buffer: a WriteStream 'SES: Bean zum Einlesen und updaten der Stako relevanten ...etc... XMLStreamReaderupToAll: Receiver: a XMLStreamReader Arguments and temporary variables: aDelimitingString: ']]' Receiver's instance variables: stream: MultiByteFileStream: '/Users/fabrizioperin/development/ Pharo/WORKINGONN...etc... nestedStreams: nil peekChar: nil buffer: a WriteStream 'SES: Bean zum Einlesen und updaten der Stako relevanten ...etc... SAXDriver(XMLTokenizer)nextCDataContent Receiver: a SAXDriver Arguments and temporary variables: cdata: nil Receiver's instance variables: streamReader: a XMLStreamReader streamWriter: a XMLStreamWriter entities: nil externalEntities: nil parameterEntities: nil isValidating: false parsingMarkup: false saxHandler: an OPOpaxHandler openTags: ejb-jar, enterprise-beans, session, description
[Pharo-project] Recovering lost changes
Hello all, I had some type of melt-down today and ended up with an image that won't load. I have a backup from a few days ago, but a lot has happened since then. Recent change logs seem to be readable, but the Recover lost changes GUI has not been terribly helpful. Is there a way to filter to things like most recent versions of a any given methods, and/or sort on the types of chunks? One surprising weakness I noted was that many do-it chunks involve things that were in context in the debugger, are now nil and ended up breaking the file-in command. I put an error handler around the evaluatations which helped, but things are still somewhat slow thanks to other do-its that do a LOT of work. I might start chipping away from the most recent chunks until it recovers enough that I can cut my loses. Ian Bartholomew's Chunk Browser for Dolphin would be an ideal tool to emulate. With what we have now, any workarounds for the things above would be greatly appreciated. Is there a way to do extended selection (e.g. shift-select to select a range of chunks)? Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
