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

Re: [Pharo-project] Pharo-beginner mailing list ?

by Adrian Kuhn

HernÃ¡n Morales Durand <hernan.morales@...> writes: > Besides, there are a lot of people which doesn't like mailing lists. > They simply won't subscribe and IMHO it has nothing to do with the > technical quality of individuals, this is a matter of customs (check > out all of those .Net/Java/SQL forums out there like codeguru.com or > db4o.com) Maybe in the middle or long term, having a web forum would > be a good idea. Good point. For example, one thing we could do is pushing Stackoverflow. They have a large userbase and excellent google ranks. When you ask a question on SO, it appears *immediately* on google! For Phexample we already tell folks to go and ask questions on SO. No one has done sofar, but that is mainly due to the limited usebase (just me, Niko and Cami sofar). You can follow all questions with one tag on SO as an RSS feed http://stackoverflow.com/questions/tagged/smalltalk http://stackoverflow.com/questions/tagged/squeak http://stackoverflow.com/questions/tagged/pharo --AA

Dec. 30, 2009

Re: [Pharo-project] Pharo-beginner mailing list ?

by HernÃ¡n Morales Durand

Hi Stef, More than beginners, I would like mailing list for non-developers, i.e. bussines people, project managers/leaders, for discussing project feasibility with Pharo, sharing work experiences, etc. This mailing list would not contain discussions about the deep internals of Pharo (we cannot hide forever inside those technical details which nobody understands :). It is important for people with bussines or marketing vocabulary to know how to sell a product like Pharo to his coleagues or inside a company. Besides, there are a lot of people which doesn't like mailing lists. They simply won't subscribe and IMHO it has nothing to do with the technical quality of individuals, this is a matter of customs (check out all of those .Net/Java/SQL forums out there like codeguru.com or db4o.com) Maybe in the middle or long term, having a web forum would be a good idea. Regards, and happy new year. HernÃ¡n 2009/12/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi all > > I remember that the squeak-beginner mailing-list (our ideas) was a huge success > since it enabled people to ask questions and have less mails. > So a question to you: do you think that it would be good to have a pharo-beginner mailing list? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 30, 2009

[Pharo-project] I have a problem with 11126

by StÃ©phane Ducasse

hi igor up to 11125 it works well and after when I was trying to do the last two cs using MC in 11125 I get new ^ self trailerClass basicNew initialize trailerClass ^ TrailerClass ifNil: [ OldMethodTrailer ] in 11126 when I try to load these packages. I get CompiledMethodTrailer new does understand trailerClass Stef (now I have to run downtown with my boys and I will come back in 2hours or so). CompiledMethodTrailer class(Object)>>doesNotUnderstand: #trailerClass CompiledMethodTrailer class>>new CompiledMethod>>trailer CompiledMethod>>getSourceFor:in: Metaclass(Behavior)>>sourceCodeAt:ifAbsent: Metaclass(Behavior)>>ultimateSourceCodeAt:ifAbsent: Browser(CodeHolder)>>sourceStringPrettifiedAndDiffed Browser>>selectedMessage Browser>>contents PluggableTextMorph>>getText PluggableTextMorph>>update: [] in Browser(Object)>>changed: DependentsArray>>do: Browser(Object)>>changed: Browser(Object)>>contentsChanged Browser(CodeHolder)>>contentsChanged Browser>>messageListIndex: PluggableListMorph>>changeModelSelection: PluggableListMorph>>mouseUp: PluggableListMorph(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableListMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: PluggableListMorph(Morph)>>processEvent:using: PluggableListMorph(Morph)>>processEvent: PluggableListMorph>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: [] in PasteUpMorph>>becomeActiveDuring: BlockClosure>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: Array(SequenceableCollection)>>do: WorldState>>handsDo:

Dec. 30, 2009

[Pharo-project] [update 1.1] MethodTrailer (really cool).

by StÃ©phane Ducasse

11121 ----- - Issue 1690: New Method Trailer part 1 (cs 1_ and 2_) 11122 ----- - Issue 1690: New Method Trailer part 2 (cs 3 merged) [update 1.1] #11123 11123 ----- - Issue 1690: New Method Trailer part 3 (cs 4 no conflict) Excellent job and big thanks igor. I read (not understood :)) all the code and it looks great! [update 1.1] #11124 11124 ----- - Issue 1690: New Method Trailer part 4 (cs 5) [update 1.1] #11125 11125 ----- - Issue 1690: New Method Trailer part 5 (cs 6 + postscript cs7) Stef

Dec. 30, 2009

Re: [Pharo-project] New class factory for tests (and other use cases)

by Adrian Kuhn

Alexandre Bergel <alexandre@...> writes: > Do you manage automatic class removing in the tearDown? Created classes are not registered with the system, so garbage collection will reclaim them when no longer used---unless there is a hidden class cache of which I am not aware. I have found a class names cache but not a class cache. > You propose: > > class := ClassFactory newSubclass: Point with: [ :f | > > f metaSide compile: 'somePoint ^ self x: 2 y: 3'. > > f compile: '+ arg ^ self x + arg x ..... 3' ]. > > ]. > > I find this difficult to remember. What is difficult to remember, the API names? By the way, the rational for using a block is that the class is only built in the end. The class cannot be built in the beginnen, since I want to allow the addition of instance variables any time while building it. The motivation is that clients should be able to loop over some array and add accessors one by one. For example as in class := ClassFactory newSubclassWith: [ :f | array do: [ :each | f compileAccessorFor: each. ]] which behind the scenes keeps adding new variables to class under construction. A future feature might even be initialization support ... --AA

Dec. 30, 2009

Re: [Pharo-project] Pharo-beginner mailing list ?

by StÃ©phane Ducasse

Ok (we are all beginners :) at least I'm :) ). On Dec 30, 2009, at 1:35 PM, George Herolyants wrote: > Hi > > Maybe it would be better to name it pharo-user(s) and leave this list > for the developers of pharo? Because "beginner" has too narrow > meaning. > > > George > > 2009/12/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi all >> >> I remember that the squeak-beginner mailing-list (our ideas) was a huge success >> since it enabled people to ask questions and have less mails. >> So a question to you: do you think that it would be good to have a pharo-beginner mailing list? >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 30, 2009

Re: [Pharo-project] Pharo-beginner mailing list ?

by George Herolyants

Hi Maybe it would be better to name it pharo-user(s) and leave this list for the developers of pharo? Because "beginner" has too narrow meaning. George 2009/12/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi all > > I remember that the squeak-beginner mailing-list (our ideas) was a huge success > since it enabled people to ask questions and have less mails. > So a question to you: do you think that it would be good to have a pharo-beginner mailing list? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 30, 2009

Re: [Pharo-project] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )

by StÃ©phane Ducasse

Excellent So we should finish 1.0 so that you get some cycles for 1.1 :) >> What I would like to understand >> - what part of the require algorithm could we unload? > > Everything can be unloaded. Good I tried 5 min in a wild way but I failed but ok it was quite wild :) > >> because I imagine that the requirement analysis is >> for the self sends deep up the hierarchy that may invoke an >> explicit requirement >> deep down the composition and this is not related >> to the simple self explicitRequirement. I would be good to do a >> pass because it would >> clarify the code. I could give a try but I would prefer you to do >> it and also we should not >> rush this is not because squeak is getting frantic that we should - >> I said that mainly for me. ;) > > Yes, I can take a look. But as you say, not right now ;) :) > >> - what is the impact from the tool perspective to have trait >> subclass of class description >> I imagine that you get less bug due to Trait dnu superclass and >> friend. > > I'd also like to look closer into NanoTraits. But so far I failed to > get a trunk image with it. I downloaded Squeak3.11-8472-alpha.image > from the ftp server and did an update to 8660 but I still get the > outdated traits implementation of Squeak. > > Inheriting from ClassDescription you need less code but you inherit > too much so I wonder how you deal with the inherited behavior that > does not make sense for traits. > >> I do not care about the install method I imagine that it is long and >> you can throw it away. > > Me neither. This was a joke ;) > > Adrian > >> Now let us be smarter than some people think we are :) >> What can we learn from nanotrait: >> - is the composition more robust (I think that andreas change a bit >> the operator) >> - is the code simpler? >> for example >> push traitComposition into TraitOrganizer so that we don't need to >> duplicate it in three places (Class, Metaclass, TraitDescription). >> of course using trait you do not duplicate >> - we have the opportunity to compare and weight pro and cons. >> We could even write a workshop paper on it for fun (ok not that >> fun :)). >> Stef >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 30, 2009

Re: [Pharo-project] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )

by Adrian Lienhard

On Dec 30, 2009, at 09:53 , StÃ©phane Ducasse wrote: > Adrian > > What I would like to understand > - what part of the require algorithm could we unload? Everything can be unloaded. > because I imagine that the requirement analysis is > for the self sends deep up the hierarchy that may invoke an > explicit requirement > deep down the composition and this is not related > to the simple self explicitRequirement. I would be good to do a > pass because it would > clarify the code. I could give a try but I would prefer you to do > it and also we should not > rush this is not because squeak is getting frantic that we should - > I said that mainly for me. ;) Yes, I can take a look. But as you say, not right now ;) > - what is the impact from the tool perspective to have trait > subclass of class description > I imagine that you get less bug due to Trait dnu superclass and > friend. I'd also like to look closer into NanoTraits. But so far I failed to get a trunk image with it. I downloaded Squeak3.11-8472-alpha.image from the ftp server and did an update to 8660 but I still get the outdated traits implementation of Squeak. Inheriting from ClassDescription you need less code but you inherit too much so I wonder how you deal with the inherited behavior that does not make sense for traits. > I do not care about the install method I imagine that it is long and > you can throw it away. Me neither. This was a joke ;) Adrian > Now let us be smarter than some people think we are :) > What can we learn from nanotrait: > - is the composition more robust (I think that andreas change a bit > the operator) > - is the code simpler? > for example > push traitComposition into TraitOrganizer so that we don't need to > duplicate it in three places (Class, Metaclass, TraitDescription). > of course using trait you do not duplicate > - we have the opportunity to compare and weight pro and cons. > We could even write a workshop paper on it for fun (ok not that > fun :)). > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 30, 2009

[Pharo-project] Pharo-beginner mailing list ?

by StÃ©phane Ducasse

Hi all I remember that the squeak-beginner mailing-list (our ideas) was a huge success since it enabled people to ask questions and have less mails. So a question to you: do you think that it would be good to have a pharo-beginner mailing list? Stef

Dec. 30, 2009