March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] A new Smalltalk mailing-list

by Serge Stinckwich

No, we can keep the archive for historical purpose ;-) On Fri, Mar 26, 2010 at 6:02 AM, Ken Causey <ken(a)kencausey.com> wrote: > Does that mean the old list > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr > > should now be deleted? > > Ken > > On Thu, 2010-03-25 at 22:16 +0700, Serge Stinckwich wrote: >> Hi all, >> french Smalltalkers (Squeakers, Pharoers, VWers, GnuSTers, ...) have >> now a new mailing list: http://groups.google.com/group/smalltalk-fr >> >> The archive of the mailing-list is available on nabble : >> http://n3.nabble.com/smalltalk-fr-f471484.html >> >> This mailing-list replace the old Squeak-fr mailing list. >> >> Best regards, > > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

March 26, 2010

Re: [Pharo-project] Stateful Traits Literature

by Alexandre Bergel

>> 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? I read the description some times ago. I might not be accurate on this. > 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. I think this is the VW solution. > The problem would be of course that Base, T1, and T2 could use $a > for completely different things. Indeed. We were not able to find a better and simple model. > Simple, but at the cost of composability/safety. > This semantics is also that of my proposal for PHP. Interesting. You designed the same model than the VW guys. Maybe this tells about its simplicity. 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 26, 2010

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

by GermÃ¡n Arduino

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 >

March 25, 2010

Re: [Pharo-project] Stateful Traits Literature

by Alexandre Bergel

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. 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 25, 2010

Re: [Pharo-project] New profiler for Pharo: tester wanted!

by Alexandre Bergel

A longer description of the profiler may be found on http://www.bergel.eu/download/papers/Berg10aProfiling.pdf We recently got this paper accepted. Cheers, Alexandre On 19 Jan 2010, at 22:03, Alexandre Bergel wrote: > Dear List, > > Over the last few months I put some effort on a new profiler for > Pharo. It has been used on a number of projects. Time has come to > share it with you. > To install it, just doit the following expression in a workspace > (Mondrian will also be installed): > -=-=-=-=-=-=-=-=-=-=-=-= > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfSpy'; > load. > (Smalltalk at: #ConfigurationOfSpy) perform: #loadDefault > -=-=-=-=-=-=-=-=-=-=-=-= > > To invoke the profiler, use the following template: > ProfilingPackageSpy viewProfiling: [ "YOUR CODE" ] inPackage: > 'YourPackageName' > ProfilingPackageSpy viewProfiling: [ "YOUR CODE" ] > inPackagesMatching: 'PackageName*' > > Replace "YOUR CODE" by an expression. Some examples are provided in > the class ProfilingPackageSpy (method category 'example'). You can > find profilings of Mondrian, Glamour, Moose/CAnalyzer, O2. > The profiling of Mondrian looks like this: > -=-=-=-=-=-=-=-=-=-=-=-= > ProfilingPackageSpy > viewProfiling: [ > | view | > view := MOViewRenderer new. > view nodes: (1 to: 100) forEach: [:each | view nodes: (1 to: 100)]. > view root applyLayout > ] > inPackage: 'Mondrian' > -=-=-=-=-=-=-=-=-=-=-=-= > > There are two things you should keep in mind: > - "YOUR CODE" will be executed twice. The first time with message > Tally, then the second time with the full instrumentation. The second > execution should not be impacted by the first execution. > - You cannot instrument the whole image. I need more time to make this > happens. Therefore, you cannot provide '*' to inPackagesMatching: > > How to read the picture: > - big rectangle are classes > - edges represent class inheritance > - inner rectangles are methods: > * height = total time that the method has been executed > * width = number of time the method has been executed > * color = number of different receiver: white = the method has > been executed on 1 receiver. black = many receivers > > You can do a right-click on a method, and select viewInvocation. This > opens a second view that show the execution flow. A different mapping > of metrics is used: > - rectangle = methods > - edges = invocation (upper invokes below) > - gray color = method that always return 'self'. It corresponds to > void methods in Java or C++. It is therefore likely that the method > performs a side effect > - yellow color = method that always returns the same value for a > particular object > - width and height are as in the first visualization > > Keep in mind that you mind encounter a freeze of your image if you > instrument sensitive methods. > > I would be sincerely delighted to have experience report on this. > > Regards, > Alexandre > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 25, 2010

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

by Alexandre Bergel

> I also noticed this too. There are some methods or classes that are > so "kernel" that cannot be wrapped. And of course, the class wrapper > in itself. > > So...do you have a list to share of the classes/methods that should > not be wrapped ? > > In my case, for example: > #new #changed #initialize #drawOn: #doesNotUnderstand: For my particular case, I do not instrument the packages coming with a core image. I tried to identify the dangerous subset of it, but apparently I run into some not easy-to-reproduce problem: running twice the image instrumentation block on a method different from the previous try. > I didn't understand you here. What I don't understand is how > MessageTally may be of help here. In order to avoid a complete image instrumentation, I instrument only what is necessary: what is actually executed for a particular scenario. Message tally is handy because you can easily infer what are the involved packages when executing a piece of code. I use this when profiling code: I do a message tally on the code to profile before doing a full-fledged instrumentation. > Sure. I have been playing (no more than 2 days) and analyzing an > implementation of MethodWrappers, the TestCoverage and CUIS' > Protocol catcher. > I just wrote some notes for myself in a simple text file. Actually > to write down what I understood and not to loose it. I attached just > in case you are interested. > > Ahhh I forgot. I am putting all these little tools here: http://www.squeaksource.com/ObjectMetaTools > in case you want to take a look. This was on my todo list. I will have a look at it soon. Cheers, Alexandre NB: Mail apparently cannot recognize your answer and I reply to your email. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 25, 2010

Re: [Pharo-project] Stateful Traits Literature

by Alexandre Bergel

Probably the most relevant publications are: "Traits: A Mechanism for fine-grained Reuse" http://scg.unibe.ch/scgbib?_k=tiFtww66&query=toplas+trait+ducasse&display=a… => it describes the original trait model "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 "Applying Traits to the Smalltalk Collection Hierarchy" http://scg.unibe.ch/scgbib?_k=NgYx7ipJ&query=Blac03a&display=abstract => Nice application of traits (I know this is not what you're asking for, but this is still a good and relevant paper" Numerous papers have been written on type systems, meta-object protocols, programming environment, all related to traits. scg.unibe.ch will help you find your way. There is small taxonomy in Stef's keynote, given at SC'09. I have also one in some of my presentations if necessary. happy reading, Alexandre On 25 Mar 2010, at 16:32, Stefan Marr wrote: > Hi: > > A bit off-topic but I think the experts are here, so: > > Is there somewhere an overview of all traits proposal related to the > handling of state? > > Possibly with a nice taxonomy and visualization? > > > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 25, 2010

Re: [Pharo-project] Stateful Traits Literature

by Stefan Marr

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

March 25, 2010

Re: [Pharo-project] Stateful Traits Literature

by Stefan Marr

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

March 25, 2010

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

by John M McIntosh

On 2010-03-25, at 9:50 AM, Mariano Martinez Peck wrote: > And if going to vm, how ? > > Thanks. See http://bugs.squeak.org/view.php?id=4882 setVMStatsTraceMessageSendLevels Some user VM assembly is required. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 25, 2010