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

Re: [Pharo-project] Smells looking at collections

by StÃ©phane Ducasse

>> >>> >>>> 2) well, this is difficult to get the money for the butter and the butter - we are trying. >>> >>> If you can compose classes the way you can add a trait to a class now with class and optional method level instance+class variable mapping, then you're done. It would be a lot simpler to use it _and_ it would also be a lot easier to implement it. Especially the tools part. >> >> I'm interested to hear more about that. so can you explain what you meant because I did not understand it. >> Tell us more. The problem we faced was >> - offset access = you cannot reuse bytecode of a trait because the order of the offset can be different in each trait users > > If you mean that a CompiledMethod of a trait cannot be added to the class' method dictionary, than that's not an issue. The current Trait implementation was changed, because shared CompiledMethods caused other problems. no this is not what I meant > If you mean that the same bytecodes can't be used, than that's neither a problem, because you can and should be compile the method again. Sharing trailer bytes may cause problems. > So adding a method from a trait to a class is simply recompiling it in the class' context. this is what we wanted to avoid. Also because you may have to recompile all the other methods of the class hierarchy because if a trait add an instance variable then you should recompile the subclasses when a trait get added with a state in the superclass. > Instance variables should be used by name during compilation. If there's a name collision then use the instance variable map I mentioned above. what is that the instance variable map? take the time to write an example >> - initialization of instances variables at the trait level and the composition at the class levele > > You can always rename a trait's method in your class. So if the trait has an #initialize method, then simply rename it to #initializeFooBar and send it from the class' #initialize method. Yes this is what the javascript implementation does but this is not that nice but may be there is no better solution. So indeed we could think about adding state. > > > Levente > >> >>> >>>> 3) again if nobody does anything and we just all cry on ourselves then nothing will happen. >>> >>> Tools are a must. No tools - no users. >> >> Exact. >> >>>> So for now identifying traits and learning is the way. Then we can refactor, redesign >>> >>> Well, Traits are in Squeak since 2006, IIRC they were available a few years earlier. So in the last X (at least 4) years the only good candidate to become a Trait was Magnitude. >> >> Come on. >> I will not answer to such statement because I'm positive thinking. >> >> 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

Oct. 24, 2010

Re: [Pharo-project] Smells looking at collections

by StÃ©phane Ducasse

your 2 cts are really welcome. On Oct 24, 2010, at 7:49 PM, Johan Brichau wrote: > > On 24 Oct 2010, at 08:42, StÃ©phane Ducasse wrote: > >>> Well, Traits are in Squeak since 2006, IIRC they were available a few years earlier. So in the last X (at least 4) years the only good candidate to become a Trait was Magnitude. > > > PolyMorphic also uses traits. > There are non-core projects that also use them, for example WebTester. > > I can also name several occassions in the development of our application, where we considered using traits to avoid code duplication. The only reason we didn't was because of a need for portability to GS. But if I understood correctly, it's quite possible that GS will support them in the future. > > Traits are being added to many other languages as well (e.g. traitsjs.org) It would be a shame to remove them from Squeak/Pharo Smalltalk now. > > just my 2 cents, > Johan > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 24, 2010

Re: [Pharo-project] akuhn/SUnit: run faster tests first & step through tests

by Adrian Kuhn

Understandable. +1 for breaking backward compatibility. --AA On Oct 24, 2010, at 00:37 , StÃ©phane Ducasse wrote: > Lack of maintainers, too many unwanted features, lack of explanation, > large changes... > > And this is not that several persons did not look at the code. It > got more than the average. > > Now I'm thinking that with discussion and care we should really get > another testing framework with the same API that SUnit > because if we want that PharoSunit is the same as Sunit then we are > doomed to be backward compatible and no > real improvements. > > Stef > > On Oct 23, 2010, at 10:58 PM, Adrian Kuhn wrote: > >> Sad to hear that. >> >> Technical difficulties, or just lack of customers? ^^ >> >> --AA >> >> On Oct 23, 2010, at 08:05 , StÃ©phane Ducasse wrote: >> >>> It was too difficult to integrate. >>> >>> Stef >>> >>> On Oct 23, 2010, at 2:01 PM, Niko Schwarz wrote: >>> >>>> What's the status of akuhn/SUnit? I couldn't find his code in 1.2 >>>> core. >>>> >>>> Niko >>>> >>>> On Wed, Feb 3, 2010 at 1:13 PM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> this loads well in the latest 1,1 core :) >>>>> so now we should really have a look and these cool changes >>>>> >>>>> Stef >>>>> >>>>> On Jan 6, 2010, at 2:38 PM, Adrian Kuhn wrote: >>>>> >>>>>> SystemChangeNotifier uniqueInstance >>>>>> noMoreNotificationsFor: TestCase. >>>>>> Gofer it >>>>>> disablePackageCache; >>>>>> squeaksource: 'akuhn'; >>>>>> package: 'SUnit'; >>>>>> package: 'SUnitGUI'; >>>>>> load. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> >>>> >>>> -- >>>> http://scg.unibe.ch/staff/Schwarz >>>> twitter.com/nes1983 >>>> Tel: +41 076 235 8683 >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >

Oct. 24, 2010

[Pharo-project] [update 1.2] #12213

by Marcus Denker

12213 ----- Issue 3153: MCVersionReader uses FileList registration Issue 3152: wrong Monticello package dependencies Issue 1954: Browser less hardcoded UI class Issue 3038: ToolBuilderTests>>testGetButtonSideEffects seems to be wrong Issue 3033: PharoCorePackageDependenciesTests make tests with packages not presents in pharo 1.2 Issue 2298: RunArray which would cause Texts with empty runs to lose their emphasis. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 24, 2010

Re: [Pharo-project] Smells looking at collections

by Johan Brichau

On 24 Oct 2010, at 20:06, Levente Uzonyi wrote: >> PolyMorphic also uses traits. > > Where can I find it? Sorry, I meant Polymorph. The PolyMorph-Widgets category in any Pharo image has them: TEasilyThemed, TEnableInHalo (or something like that). >> There are non-core projects that also use them, for example WebTester. > > I don't see any trait in the latest version, though I used SqueakSource's web interface. There's just one (WtTClickable) right now.

Oct. 24, 2010

Re: [Pharo-project] Smells looking at collections

by Levente Uzonyi

On Sun, 24 Oct 2010, Johan Brichau wrote: > > On 24 Oct 2010, at 08:42, StÃ©phane Ducasse wrote: > >>> Well, Traits are in Squeak since 2006, IIRC they were available a few years earlier. So in the last X (at least 4) years the only good candidate to become a Trait was Magnitude. > > > PolyMorphic also uses traits. Where can I find it? > There are non-core projects that also use them, for example WebTester. I don't see any trait in the latest version, though I used SqueakSource's web interface. > > I can also name several occassions in the development of our application, where we considered using traits to avoid code duplication. The only reason we didn't was because of a need for portability to GS. But if I understood correctly, it's quite possible that GS will support them in the future. > > Traits are being added to many other languages as well (e.g. traitsjs.org) It would be a shame to remove them from Squeak/Pharo Smalltalk now. I'm not saying that trait-like composition is bad, I only say that there's a better approach. Levente > > just my 2 cents, > Johan > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 24, 2010

Re: [Pharo-project] Smells looking at collections

by Johan Fabry

On 24 Oct 2010, at 14:48, Johan Brichau wrote: > > On 24 Oct 2010, at 08:42, StÃ©phane Ducasse wrote: > >>> Well, Traits are in Squeak since 2006, IIRC they were available a few years earlier. So in the last X (at least 4) years the only good candidate to become a Trait was Magnitude. > > > PolyMorphic also uses traits. > There are non-core projects that also use them, for example WebTester. AspectMaps us them as well. They made it possible to really clean up my implementation, so I am happy with them (even though there are packaging issues). > Traits are being added to many other languages as well (e.g. traitsjs.org) It would be a shame to remove them from Squeak/Pharo Smalltalk now. +1 -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Oct. 24, 2010

[Pharo-project] Issue 3153: MCVersionReader uses FileList registration

by Pavel Krivanek

http://code.google.com/p/pharo/issues/detail?id=3153 This is the next important patch that enables to load Monticello to PharoKernel. Cheers -- Pavel

Oct. 24, 2010

Re: [Pharo-project] Smells looking at collections

by Johan Brichau

On 24 Oct 2010, at 08:42, StÃ©phane Ducasse wrote: >> Well, Traits are in Squeak since 2006, IIRC they were available a few years earlier. So in the last X (at least 4) years the only good candidate to become a Trait was Magnitude. PolyMorphic also uses traits. There are non-core projects that also use them, for example WebTester. I can also name several occassions in the development of our application, where we considered using traits to avoid code duplication. The only reason we didn't was because of a need for portability to GS. But if I understood correctly, it's quite possible that GS will support them in the future. Traits are being added to many other languages as well (e.g. traitsjs.org) It would be a shame to remove them from Squeak/Pharo Smalltalk now. just my 2 cents, Johan

Oct. 24, 2010

Re: [Pharo-project] Smells looking at collections

by Levente Uzonyi

On Sun, 24 Oct 2010, StÃ©phane Ducasse wrote: >>>> >> Not trivial? Maybe not, but only a little bit harder than trivial. > > We are open to suggestions believe me :) >> >>> 2) well, this is difficult to get the money for the butter and the butter - we are trying. >> >> If you can compose classes the way you can add a trait to a class now with class and optional method level instance+class variable mapping, then you're done. It would be a lot simpler to use it _and_ it would also be a lot easier to implement it. Especially the tools part. > > I'm interested to hear more about that. > Tell us more. The problem we faced was > - offset access = you cannot reuse bytecode of a trait because the order of the offset can be different in each trait users If you mean that a CompiledMethod of a trait cannot be added to the class' method dictionary, than that's not an issue. The current Trait implementation was changed, because shared CompiledMethods caused other problems. If you mean that the same bytecodes can't be used, than that's neither a problem, because you can and should be compile the method again. Sharing trailer bytes may cause problems. So adding a method from a trait to a class is simply recompiling it in the class' context. Instance variables should be used by name during compilation. If there's a name collision then use the instance variable map I mentioned above. > - initialization of instances variables at the trait level and the composition at the class levele You can always rename a trait's method in your class. So if the trait has an #initialize method, then simply rename it to #initializeFooBar and send it from the class' #initialize method. Levente > >> >>> 3) again if nobody does anything and we just all cry on ourselves then nothing will happen. >> >> Tools are a must. No tools - no users. > > Exact. > >>> So for now identifying traits and learning is the way. Then we can refactor, redesign >> >> Well, Traits are in Squeak since 2006, IIRC they were available a few years earlier. So in the last X (at least 4) years the only good candidate to become a Trait was Magnitude. > > Come on. > I will not answer to such statement because I'm positive thinking. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 24, 2010

Re: [Pharo-project] Proposal: adding 261 named colors

by Johan Fabry

Yes there are some fun names in there: ice, yelowish, midnight, barney. Also some very 'human-excreta-related' ones: puke, vomit, poo, booger, ... But I chose not to pass a watch-out-for-the-children filter. (What would I do with Barney for example ? :-P ) On 24 Oct 2010, at 03:46, StÃ©phane Ducasse wrote: > ok I read the code :) > > I like 'swamp' > > Stef > > On Oct 23, 2010, at 11:30 PM, Johan Fabry wrote: > >> Hi all, >> >> in the work of AspectMaps I was a bit let down by the named colors Pharo provides (Color red et cetera). Now I am happy to say that thanks to the XKCD color survey I was able to improve on this. I can now use 261 named colors thanks to a XKCDColor class, and I'd like to share the code, ideally to be included into Pharo. The code is available in bugreport http://code.google.com/p/pharo/issues/detail?id=3148 >> >> Here is the class comment fo XKCDColor: >> >> ---snip--- >> A color named according to the XKCD color survey, as published in http://blog.xkcd.com/2010/05/03/color-survey-results/ ("Over five million colors were named across 222,500 user sessions.") >> >> Of the full table of 954 colors that is published only those were selected that did not have a space in their name, ignoring e.g. electric lime, nasty green, macaroni and cheese, pinkish tan, but also light light blue, strong blue. This results in a table of 261 named colors, but with duplicates such as ochre and ocre. These were left in since as they are common misspellings it is more convenient for the user. >> >> To instantiate: XCDColor named: aString where aString is one of the 261 named colors. If the name is not known, the color red is instantiated. Instances of XKCDColor know their XKCD color name, returned by the name accessor. >> >> Thanks to Randall Monroe of http://xkcd.com for providing the data. >> ---snip--- >> >> And here is a picture of all the colors (Generated with Mondrian :-) ) >> >> <Colors.png> >> >> -- >> Johan Fabry >> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> >> _______________________________________________ >> 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 -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Oct. 24, 2010

Re: [Pharo-project] Proposal: adding 261 named colors

by Johan Fabry

Yes if it doesn't make it in Pharo, it would be great that it gets in Moose. Stef, you closed the bug, does this mean it will be integrated ? On 24 Oct 2010, at 04:12, Tudor Girba wrote: > Hi Johan, > > I would definitely be interested in getting this as an external library around Mondrian and Moose. > > Cheers, > Doru > > > On 24 Oct 2010, at 07:09, Johan Fabry wrote: > >> If you instantiate a color but dont see it, does it matter that the color is not what you wanted? It's like considering the classical 'tree falls in the forest' question. >> >> Or if you prefer a more implementation-based view: if a morph cannot be drawn, do you halt the system? Right now it is not the case, a rectangle with a cross is drawn. >> >> In any case, I am open to suggestions for improvement! > -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Oct. 24, 2010

[Pharo-project] a bit of fun

by StÃ©phane Ducasse

http://www.scribd.com/doc/38648591/About-Coders-new-version Stef

Oct. 24, 2010

[Pharo-project] problem with metacello in 1.2

by StÃ©phane Ducasse

Dale did something change on the server side? This is strange 199 - Issue 3048: MC method cache fix. Thanks Igor Stasenko 200 - Issue 2653: Editor cursor fix: remove autoclose in texteditor. - Issue 3128: AuthorRequestImprovement. Thanks Alain Plantec - Issue 3099: Create method in the debugger does not provides getter/setters implementors. Thanks Hernan Wilkinson 201 - Issue 1800: MenuIcons and ThemeIcons should be merged. Big thanks to alain plantec!!! 202 - Issue 3070: weird replacements in TextEditor. Thanks Alain Plantec!!! 203 - Issue 654: inconsistent highlight color. Thanks Alain Plantec - Issue 3101: Wrong Monticello packages initialization order. Thanks Pavel Krivanek 204 - Issue 2868: allClassesUsingPool: allClassesUsingPoolVariable: for systemNavigation - Issue 3046: BUG: LineMorph class>>from:to:color:width: returns a PolygonMorph - Issue 3130: MethodReference >> #isLocalSelector should not be part of Monticello package - Issue 3095: Character isLiteral is in wrong category - Issue 3134: Cleaning uniclasses from smartRefStream Jannik can you check with the Utilities trick I sent you to try Utilities readServer: Utilities serverUrls updatesThrough: 12200 saveLocally: false updateImage: true 199 200 201 202 203 204 so that we try to identify the problem Stef

Oct. 24, 2010

Re: [Pharo-project] What happened to demo mode?

by Alain Plantec

Le 24/10/2010 18:30, Serge Stinckwich a Ã©crit : > > > Le 24 oct. 2010 Ã 16:23, laurent laffont <laurent.laffont(a)gmail.com > <mailto:laurent.laffont@gmail.com>> a Ã©crit : > >> Added: http://book.pharo-project.org/book/CustomizingPharo/ > > Thank you Laurent, but i guess there is still a problem with demo mode > under Mac os x (the font used in browser code pane is not correct). yes ! unfortunately see Issue 2986. <http://code.google.com/p/pharo/issues/detail?id=2986> Alain > > -- Serge Stinckwich > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 24, 2010

[Pharo-project] Issue 3152: wrong Monticello package dependencies

by Pavel Krivanek

Hi, please integrate it soon: http://code.google.com/p/pharo/issues/detail?id=3152 Cheers, -- Pavel

Oct. 24, 2010

Re: [Pharo-project] What happened to demo mode?

by Serge Stinckwich

Le 24 oct. 2010 Ã 16:23, laurent laffont <laurent.laffont(a)gmail.com> a Ã©crit : > Added: http://book.pharo-project.org/book/CustomizingPharo/ Thank you Laurent, but i guess there is still a problem with demo mode under Mac os x (the font used in browser code pane is not correct). -- Serge Stinckwich

Oct. 24, 2010

Re: [Pharo-project] export information to PDF

by Mariano Martinez Peck

Hi. The only thing I know is in http://www.seaside.st/documentation/pdfs (it is not Seaside specific) cheers mariano 2010/10/24 name name <onor16(a)gmail.com> > Hello, > > Could you tell me how can I export (or where I can found ) information > that I can get with a getter into a .pdf file? > > Thanks > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 24, 2010

[Pharo-project] [update 1.2] #12212

by Marcus Denker

12212 ----- Issue 3137: Comment in Behavior >> allMethods is wrong Issue 3149: No setting in the setting browser Issue 3150: implementor of and sender of dont retrieve class side methods Issue 2340: Cursor for textEditor or new paragraph -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 24, 2010

Re: [Pharo-project] some patterns I would like to **kill**

by Schwab,Wilhelm K

If I understand you, you took things normally stored in instance variables, and (redundantly?) stored them as properties, right? ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Saturday, October 23, 2010 10:47 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] some patterns I would like to **kill** On 23 October 2010 21:47, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Hey, I want some credit here - for coming to Squeak's possible defense :) > > All I am saying is that there is a possible space/speed tradeoff with a twist. There was a fair amount written about these decisions, which is why I know anything at all about them. Adding an instance variable for a rarely used sub-morph of a widely-instantiated morph might be an opportunity to fail to learn from history. Most likely, the patterns Stef has noticed are simply mis-uses of sparse storage. The best way to proceed would be to find an example of it that has many instances in the image, profile, fix, and profile again to see if the fix hurts performance (or perhaps helps it). The usual caveats about benchmarking being really hard to do well apply, of course. > I did some experiment(s) with Morphic, placing many morph aspects into properties dictioary (such as color, border, borderwidth etc), and these values are used in rendering all the time. And i didn't noticed heavy speed degradation. > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Saturday, October 23, 2010 11:00 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] some patterns I would like to **kill** > > On 23 October 2010 17:13, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Stef, >> >> Of course. But in terms of avoiding unintended consequences, just consider the points I raised. Some of the avoidance of instance variables (extensions, etc.) might have been a good idea with the gc at the time but is now an ugly hack, or that sparse storage tricks were over-used. >> > Well, one way or another you have to tame the complexity somehow. > Be it extra instvar, or putting it into extensions doesn't changes the > model's concept: you need a reference to some object > which is responsible for some specific stuff. > > >> Bill >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] >> Sent: Saturday, October 23, 2010 7:33 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] some patterns I would like to **kill** >> >> I think that if you have a container that contains morphs probably findA and other queries are useful. >> Now for a button that is also at the same place a field is the best. >> >> Stef >> >> >> On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote: >> >>> Stef, >>> >>> #respondsTo: - no argument. More defensive programming (aka masked bugs). Tests like this have their place, but are over-used in Squeak. >>> >>> Using #submorphs *might* be easier to defend. Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. An instance variable could also cache stale information. Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read. >>> >>> Bill >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse(a)free.fr] >>> Sent: Thursday, October 21, 2010 4:47 PM >>> To: Pharo Development >>> Subject: [Pharo-project] some patterns I would like to **kill** >>> >>> Hi >>> >>> I was reading Pluggable and friends >>> I identified some patterns. >>> >>> >>> The respondsTo plague >>> Examples: >>> >>> color := self fillStyle asColor. >>> (self labelMorph respondsTo: #enabled:) >>> ifTrue: [self labelMorph enabled: self enabled]. >>> (self labelMorph respondsTo: #interactionState:) >>> ifTrue: [self labelMorph interactionState: self interactionState] >>> >>> (self labelMorph respondsTo: #enabled:) ifTrue: [ >>> self labelMorph enabled: aBoolean]. >>> >>> (self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]]) >>> >>> >>> by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed. >>> >>> >>> Using submorphs to avoid one single inst var makes code quite ugly to read: >>> >>> >>> labelMorph >>> "Answer the actual label morph." >>> >>> self hasSubmorphs ifFalse: [^nil]. >>> self firstSubmorph hasSubmorphs ifFalse: [^nil]. >>> ^self firstSubmorph firstSubmorph >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 24, 2010

[Pharo-project] #3149 and #3150

by Luc Fabresse

A fix for : http://code.google.com/p/pharo/issues/detail?id=3149 http://code.google.com/p/pharo/issues/detail?id=3150 is attached. Tested in 12211. It was a bug introduced by my changes in SystemNavigation. Please, forgive me ;-) More unit tests are needed for SystemNavigation, SystemDictionary and SystemOrganization. I will write some. #Luc

Oct. 24, 2010

[Pharo-project] export information to PDF

by name name

Hello, Could you tell me how can I export (or where I can found ) information that I can get with a getter into a .pdf file? Thanks

Oct. 24, 2010

Re: [Pharo-project] Pharo problem with Windows 7

by Mariano Martinez Peck

2010/10/24 Christian Eduardo Palomares Peralta <palomares.c(a)gmail.com> > Hi > > After three days i've got success, i totally disabled my antivirus and it > works =) > I told you :) > > Thanks for the help to Alexandre Bergel, Torsten Bermann and Mariano > Martinez > > Obviously i'm going to enable my antivirus and configure it > > Yes, just exclude the Pharo folder and that's all. Cheers Mariano > -- > Christian Eduardo Palomares Peralta (ShinjiDev) - > http://learningwebdev.blogspot.com > Administrador del Grupo Python-PerÃº > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 24, 2010

Re: [Pharo-project] [ANN] pre-build Core#12210

by Alain Plantec

found. It is because the semantic of SystemNavigation>>allBehaviorsDo: has changed. http://code.google.com/p/pharo/issues/detail?id=3149 Le 23/10/2010 18:34, Alain Plantec a Ã©crit : > Strange, there is no setting shown in the setting browser ??? > The settings methods are still here thought > alain > > Le 23/10/2010 17:47, Marcus Denker a Ã©crit : >> https://gforge.inria.fr/frs/download.php/27677/PharoCore-1.2-12210.zip >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Oct. 24, 2010

[Pharo-project] Learning on Sockets

by laurent laffont

Hi, I want to record a screencast on basic networking and also explore this idea: http://forum.world.st/Community-in-the-IDE-tp2543540p2543540.html Do you have some links on documentation and/or good code to look at ? I'm searching for best practices / modelizations to write a chat server and client. Actually I've read and tried those: http://book.pharo-project.org/book/networking/Socket http://wiki.squeak.org/squeak/325 Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/

Oct. 24, 2010