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

Re: [Pharo-project] (no subject)

by StÃ©phane Ducasse

There are least two papers from ECOOP that points to some problems. But probably they are not frequent. Stef On Nov 24, 2009, at 6:08 PM, Damien Cassou wrote: > On Mon, Nov 23, 2009 at 7:53 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >>> I know the refactoring engine of Eclipse. It must be 20 years ahead of Smalltalk. >> >> Not sure because it is full of bugs because Java is complex. > > I use Eclipse and its refactorings everyday. They work quite well. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 24, 2009

Re: [Pharo-project] New version of OCompletion

by StÃ©phane Ducasse

> Tim and I have been working on improving OCompletion. > Personally, I feel these changes significant reduce the amount of > times that I do not want the completion of opposite characters, e.g., > $), $], $' > > Here is the comment of the version 40 of the Monticello Package: > > -=-=-=-=-=-=-=-=-= > This new version provides some important improvements of OCompletion: > - inserting a '(' before an alphanumeric character does not insert a > ')'. I not get this one. 0 -> (0 a -> (a a -> ( a) ???? > - inserting a '(' then removing it removes ')' if it was inserted > > These features have been pair programmed with Tim Mackinnon during the > Pharo sprint at Smalltalks'09, Buenos Aires > -=-=-=-=-=-=-=-=-= > > Let us know whether you are happy or not with these improvements. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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

Nov. 24, 2009

Re: [Pharo-project] Pharo by Example - chapter about Exception - Error - Notification - Abort?

by StÃ©phane Ducasse

> I enjoyed the chapter :-). It was very informative, and illustrated yet again how flexible Smalltalk can be. Is there any particular reason why this 'essential' chapter was not included in the first edition of Pharo by Example? - It was not written - we want to have a cool second volume and - pharo by example can already get out for other languages using squeak by example translation, so we do not want to force translater that already translate squeak by example to have to translate too many new chapters. > > I also have a question about the contents. In chapter '1.14 Catching sets of exceptions' it is explained how catch a set of exceptions but not how to define a different handler on each exception. For instance i want to handle a more specific FileDoesNotExistException in a different way than a more general FileStreamException, or even Exception. The way i can do this, i see, is to test which type of exception is coming into the do: block and execute appropriate code. This is a very bad solution. Or secondly, to create nested on: do: blocks with the most specific exception as inner block. This seems better, but is kind of verbose. > Is there another way to solve this problem? > > Kind regards, > > Bart > > 2009/11/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > Enjoy I had a lot of fun writing it when my family went to the swimming pool and I could concentrate :) > > Stef > > On Nov 23, 2009, at 9:05 AM, Bart Gauquie wrote: > > > Dear all, > > > > I've been searching the Pharo by Example book about how to handle Exception, Error, ... in Pharo. > > > > I've found some information about it in the SUnit chapter, in method 7.11: Catching test case errors and failures; this is only a small fragment however. > > > > Is there any chapter planned about this topic? It would be very useful i think, since it is an important topic, and I've read that Smalltalks exception handling is very powerful, but I don't know much about it and like to learn it. > > > > Kind Regards, > > > > Bart > > > > -- > > imagination is more important than knowledge - Albert Einstein > > Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein > > Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein > > The true sign of intelligence is not knowledge but imagination. - Albert Einstein > > Gravitation is not responsible for people falling in love. - Albert Einstein > > _______________________________________________ > > 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 > > > > -- > imagination is more important than knowledge - Albert Einstein > Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein > Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein > The true sign of intelligence is not knowledge but imagination. - Albert Einstein > Gravitation is not responsible for people falling in love. - Albert Einstein > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 24, 2009

Re: [Pharo-project] Some comments about Filesystem

by StÃ©phane Ducasse

I'm not sure that colin reads the pharo mailing-list. Stef On Nov 24, 2009, at 4:19 PM, Alexandre Bergel wrote: > Some comments about Filesystem: > > I am trying to use your library for file processing. I had the > following: > (FileStream fileNamed: 'inc.c.xml' ) readStream next > => $< > > With Filesystem, I obtain the following: > (FSDiskFilesystem current referenceTo: 'inc.c.xml') readStream next > => 60 > > The problem is that the XML library does the #next, which expects a > character, and not integer. I do instead: > (FSDiskFilesystem current referenceTo: filenameString) readStreamDo: > [:stream | . > document := self parse: (ReadStream on: stream contents asString). > ... > But there should be a nicer way to obtain a character stream from a > file. > > > Another comment, why not to have FSReference>>files and > FSReference>>directories? Although the visitors are convenient, I feel > it will be useful to add #files and #directories. > > Cheers, > 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

Nov. 24, 2009

Re: [Pharo-project] PackageInfo>>classes does not distinguish traits from classes (issue?)

by StÃ©phane Ducasse

What is strange adrian is that before we did not encounter this problem in moose. May be something changes and we did not notice it. Stef On Nov 23, 2009, at 10:31 PM, Adrian Lienhard wrote: > Hi Simon, > > There is no such method. But it would be easy to add (just send > "aPackage classes select: #isTrait"). The reason for returning traits > with the classes is that clients of PackageInfo typically expect > "compilation units", i.e., a collection including traits. The naming, > of course, is not optimal, and should be fixed in the long run. The > problem is to do so without breaking the clients of PackagInfo. > > Cheers, > Adrian > > On Nov 23, 2009, at 16:28 , Simon Denier wrote: > >> Hi there >> >> When I run PackageInfo>>classes, I get both classes and traits defined >> in the package. So I can understand the need for a method retrieving >> all 'compilation units' (or behaviors) from a package, but is there no >> method to just retrieve the regular classes? Especially since there is >> a #externalTraits method. >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> 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

Nov. 24, 2009

Re: [Pharo-project] settings integration

by StÃ©phane Ducasse

On Nov 23, 2009, at 10:07 PM, Lukas Renggli wrote: >> but lukas this is not because systemSetting: >> >> does not refer to setting classes that there is no dependency. >> newSetting and all the rest will introduce a dependency. > > Sure, that's a dependency too, but not one that prevents clean loading. > > Hard dependencies in Smalltalk that prevent from loading are missing > super classes, missing classes that are extended, missing traits > imports, and missing class references. Pharo can somehow handle the > last dependency gracefully, but it shows up as an error in the > transcript and causes an undeclared variable to be defined in the > system. Other Smalltalk don't allow to load such code (VAST). > > Personally I don't consider sending a non-existing message in a method > that is never called that much of a problem. I see. So what I would do is to have a builder and also introduce most of the time a separate package because this is really cleaner. > > 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

Nov. 24, 2009

[Pharo-project] Pharo Sprint

by Alexandre Bergel

Aldo and I seat down during the Pharo Sprint on Saturday. We had fun. Below what we did. ISSUE #262 (fixed) Doits are now executed by primtive. This means, a doit method is *never* installed in a class. We removed all now unnecessary checks of isDoit - Behavior>>allLocalCallsOn: - ChangeSet>>atSelector: selector class: class put: changeType - MethodReference>>isValid - PCCByCompilation>>methodsWithDisabledCall - PackageInfo>>methods - SystemNavigation>>browseAllCallsOn: aLiteral localTo: aClass Pair programmed with Aldo Mettini Slice_262_isDoIt-Alexandre_Bergel.1 in Pharo Inbox -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ISSUE #1486 (fixed) Added BehaviorTest>>testAllLocalCallsOn Pair programmed with Aldo Mettini during the Pharo Sprint @ Smalltalks 2009 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ISSUE #1488 (new) Dictionary is not a superclass of SmallDictionary, and SmallDictionary is not a subclass of Dictionary. The only common superclass of these two classes is Collection. Putting unreferencedKeys in Collection does not look too good as well. Therefore, unreferencedKeys looks like to be a good candidate for being shared by a trait. Pair programmed with Aldo Mettini during the Pharo Sprint @ Smalltalks 2009 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ISSUE #261 (fix) Even though allCallsOn: implies something about "calls" which seems to be related to sends, it actually even is used for references to classes. We added a SystemNavigation>>allReferencesTo: aLiteral that returns the list of methods referencing aLiteral. We simplified allCallsOn: since now it acts on symbols only. It raises a deprecation warning if a binding is provided to allCallsOn:. We refactored all callers of allCallsOn: and wrote some tests (for the one that was easy to write): BehaviorTest>>testAllCallsOn Pair programmed with Aldo Mettini during the Pharo Sprint @ Smalltalks 2009 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 24, 2009

Re: [Pharo-project] (no subject)

by csrabak＠bol.com.br

OK, So it is the 'ergonomics' of the tool that makes you feel it is years ahead... Usability is a very difficult thing to measure and/or evaluate. Regards, -- Cesar Rabak Em 24/11/2009 15:55, Lukas Renggli <renggli(a)gmail.com> escreveu: > Is there a kind of comparison table of the features available in Eclipse versus the Smalltalks' RBs? I was not talking about feature completeness, I was more talking about the usability of the editor and how the different tools integrate. It is impressive that you see the renaming happening live in Eclipse while you type a new class/variable/method name. I don't know of a single refactoring in Eclipse that is not available in Smalltalk, of course excluding some of the refactorings that mangle with types, packages or inner-class and that do not make sense in the context of Smalltalk. Furthermore the Smalltalk refactoring engine provides an universal code transformation engine that allows one to script new transformations (refactorings) within seconds. This is something that I have not yet seen in any other language with that sophistication. 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

Nov. 24, 2009

[Pharo-project] New version of OCompletion

by Alexandre Bergel

Dear List, Tim and I have been working on improving OCompletion. Personally, I feel these changes significant reduce the amount of times that I do not want the completion of opposite characters, e.g., $), $], $' Here is the comment of the version 40 of the Monticello Package: -=-=-=-=-=-=-=-=-= This new version provides some important improvements of OCompletion: - inserting a '(' before an alphanumeric character does not insert a ')'. - inserting a '(' then removing it removes ')' if it was inserted These features have been pair programmed with Tim Mackinnon during the Pharo sprint at Smalltalks'09, Buenos Aires -=-=-=-=-=-=-=-=-= Let us know whether you are happy or not with these improvements. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 24, 2009

Re: [Pharo-project] (no subject)

by Lukas Renggli

> Is there a kind of comparison table of the features available in Eclipse versus the Smalltalks' RBs? I was not talking about feature completeness, I was more talking about the usability of the editor and how the different tools integrate. It is impressive that you see the renaming happening live in Eclipse while you type a new class/variable/method name. I don't know of a single refactoring in Eclipse that is not available in Smalltalk, of course excluding some of the refactorings that mangle with types, packages or inner-class and that do not make sense in the context of Smalltalk. Furthermore the Smalltalk refactoring engine provides an universal code transformation engine that allows one to script new transformations (refactorings) within seconds. This is something that I have not yet seen in any other language with that sophistication. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 24, 2009