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

Re: [Pharo-project] Pavel can you check :)

by Pavel Krivanek

Hi, fix attached to the issue. Unknown classes are initialized at the end by alphabetical order. Cheers, -- Pavel On Sat, Oct 23, 2010 at 12:39 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > When I clicked on a package, it got downloaded to the package cache using the writeDefinitions: method > > writeDefinitions: aCollection > Â Â Â Â "initStream is an ugly hack until we have proper init defs" > > Â Â Â Â initializers := Dictionary new. > > Â Â Â Â (MCDependencySorter sortItems: aCollection) > Â Â Â Â Â Â Â Â do: [:ea | ea accept: self] > Â Â Â Â Â Â Â Â displayingProgress: 'Writing definitions...'. > > Â Â Â Â (Class superclassOrder: (initializers Â keys collect: [:each | Smalltalk classOrTraitNamed: each])) do: [:class | > Â Â Â Â Â Â Â Â stream nextPutAll: (initializers at: class name) contents ]. > > > Now it is bugging because initializers keys could contain a class that is not in the image and then put nil in the set > The previous version of the method was: > > writeDefinitions: aCollection > Â Â Â Â "initStream is an ugly hack until we have proper init defs" > Â Â Â Â initStream := String new writeStream. > > Â Â Â Â (MCDependencySorter sortItems: aCollection) > Â Â Â Â Â Â Â Â do: [:ea | ea accept: self] > Â Â Â Â Â Â Â Â displayingProgress: 'Writing definitions...'. > > Â Â Â Â stream nextPutAll: initStream contents. > > > - The previous version did not save initializers or may be different > > - Now the changes does not take into account classes that are not in the image. > And this one should still be saved > > > > > > > > > > On Oct 23, 2010, at 12:22 PM, StÃ©phane Ducasse wrote: > >> Apparently when we browse >> Compiler-eem.155 from the squeak trunk (ScriptLoader new addExtraRepositories) >> >> we get a problem because there is a nil in the set. >> >> Can you have a look? >> >> 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. 23, 2010

[Pharo-project] "suggest" for the sprint

by Mariano Martinez Peck

I also agree with Marcus idea: 'lets integrate much make us be more productive and progress faster'. I would love to have the Benjamin work. - Remove "Messages Names" and "Method FInder" and put his new tool. - Put his new changes browser. I would be really really nice to have this, even if it is not perfect yet. People may start to use it, report issues and give feedback. Thanks Mariano

Oct. 23, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Mariano Martinez Peck

On Fri, Oct 15, 2010 at 6:40 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > > On 15 oct. 2010, at 17:31, Mariano Martinez Peck wrote: > > > They've changed a lot from 1.0. For example, self, super, etc, are not in > "orange" or that color of 1.0. > > Instances variables, are blue (instead of black), the same as > parameters,etc... > > > > is there a way to recover the original colors? do we wanted this change > or it is accidental ? > > > > I think the colors in 1.0 were inherited from the dev images build by > Damien Cassou. In 1.1, the colors comes from the settings of Lukas, who > maintains Shout? Am I wrong? > > I liked the colors in 1.0, but now I am accustomed to the current theme, > which is very keen to the eye, except for two things that I change: > - distinguish instance vars/class vars from other variables: I use a > brownish color for that, as I want to see at once methods accessing the > state of the object > - distinguish class references: I use bold black as in the previous style, > as I want to quickly catch hard dependencies in the code > > EXACTLY!!! this is exacrtly the same that bothers me. > To customize colors, two solutions: > 1) hack SHTextStylerST80>>defaultStyleTable > did you do this? can you share? > 2) load latest Shout and use Settings (then you should be able to save/load > your style), since there is now a Settings interface > > The problem is that I have my own style also....and when you save an style I think you save it completly...I guess you cannot merge, so I will loose my own changes. Anyway, can you export and share the style so that I can take a look? Thanks! Mariano > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Mariano Martinez Peck

On Fri, Oct 15, 2010 at 9:21 PM, Ramon Leon <ramon.leon(a)allresnet.com>wrote: > On 10/15/2010 9:40 AM, Simon Denier wrote: > >> >> On 15 oct. 2010, at 17:31, Mariano Martinez Peck wrote: >> >> They've changed a lot from 1.0. For example, self, super, etc, are not in >>> "orange" or that color of 1.0. >>> Instances variables, are blue (instead of black), the same as >>> parameters,etc... >>> >>> is there a way to recover the original colors? do we wanted this change >>> or it is accidental ? >>> >> >> I think the colors in 1.0 were inherited from the dev images build by >> Damien Cassou. In 1.1, the colors comes from the settings of Lukas, who >> maintains Shout? Am I wrong? >> > > I preferred the old colors as well and switched them back. The new ones > are just too weak, not enough color, not enough bold, can't tell things > apart. > Exactly. Can you or Simon provide a script to set back the original colors?? So that we can apply this for next PharoDev images? (or at least for my own images) Thanks Mariano > > -- > Ramon Leon > http://onsmalltalk.com > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2010

Re: [Pharo-project] Loading FFI into Pharo?

by David T. Lewis

On Fri, Oct 22, 2010 at 10:40:50AM +0200, Mariano Martinez Peck wrote: > On Fri, Oct 22, 2010 at 10:33 AM, Friedrich Dominicus < > frido(a)q-software-solutions.de> wrote: > > > Mariano Martinez Peck <marianopeck(a)gmail.com> writes: > > > > > On Fri, Oct 22, 2010 at 10:05 AM, Friedrich Dominicus < > > > frido(a)q-software-solutions.de> wrote: > > > > > > Friedrich Dominicus <frido(a)q-software-solutions.de> writes: > > > > > > > "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> writes: > > > > > > > >> I haven't had much trouble with it. You can look in the inbox for > > > >> Migrate (for how I load it) and the DolphinCompatibility package > > for > > > >> things that I have added to the ODBC support. > > > > Are there any usage examples for ODBC and Pharo or is it go out and > > find > > > > out yourself? And another maybe stupid question has anyone used it > > for > > > > accessing .mdb databases from MS-Access? > > > Ok i'm probabla currently a bit confused. AFAIKT the Pharo I've > > running > > > here is 32-bit. My machine however is a 64-bit System, so to use the > > > unixodbc I probably would need the 32-bit version of the unixodbc > > > driver. Is that correct? > > > > > > > > > Yes. Exactly. To compile ODBC you may want to try something like we did > > in > > > SqueakDBX: > > > > > > http://www.squeakdbx.org/SqueakDBX%20in%2064%20bits > > Thanks my confusion has not last that long. I just was puzzling why isql > > does connect but Pharo won't. Sure the reason is clear, but it has > > catched me. Fine, I'm trying to get unixodbc compiled an installed on my > > 64 bit box. I just wonder has anyone build a 64-bit Pharo? > > > > More or less. Because you need: a 64 bits VM, and a 64 bits image as much as > I understand. > In addition, there are certain bugs in FFI about using it in 64 bits. > Details here: http://bugs.squeak.org/view.php?id=7237 FFI can be made to work on 64-bits but it is difficult and complicated, so if you are just trying to get ODBC working you should stick with 32 bit binaries. Dave

Oct. 23, 2010

Re: [Pharo-project] problem with metacello in 1.2

by Mariano Martinez Peck

On Sat, Oct 23, 2010 at 7:05 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Wierd...now I have the same problem :( > > > On Sat, Oct 23, 2010 at 6:06 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> I think you were having a problem with the internet connection. Here it is >> fine. >> Try again ;) >> >> 2010/10/23 Fabrizio Perin <fabrizio.perin(a)gmail.com> >> >>> Hi all, >>> i was trying to make Moose loadable into a 1.2 i did try to run the >>> configuration of Moose and i got an error at the very beginning caused by >>> the configuration of metacello. Am i missing something or it actually should >>> work? I did expect to have problem but not with the configuration of >>> metacello. >>> >>> I'm using a >>> >>> Pharo image 12203 on a Squeak4.2.5beta1U VM >>> >>> To reproduce the error just open the image and execute in a workspace: >>> >>> Gofer new >>> squeaksource: 'Moose'; >>> package: 'ConfigurationOfMoose'; >>> load. >>> (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault >>> >>> Attached the log. >>> >>> Thanks, >>> Fabrizio >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >

Oct. 23, 2010

Re: [Pharo-project] problem with metacello in 1.2

by Mariano Martinez Peck

Wierd...now I have the same problem :( On Sat, Oct 23, 2010 at 6:06 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > I think you were having a problem with the internet connection. Here it is > fine. > Try again ;) > > 2010/10/23 Fabrizio Perin <fabrizio.perin(a)gmail.com> > >> Hi all, >> i was trying to make Moose loadable into a 1.2 i did try to run the >> configuration of Moose and i got an error at the very beginning caused by >> the configuration of metacello. Am i missing something or it actually should >> work? I did expect to have problem but not with the configuration of >> metacello. >> >> I'm using a >> >> Pharo image 12203 on a Squeak4.2.5beta1U VM >> >> To reproduce the error just open the image and execute in a workspace: >> >> Gofer new >> squeaksource: 'Moose'; >> package: 'ConfigurationOfMoose'; >> load. >> (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault >> >> Attached the log. >> >> Thanks, >> Fabrizio >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Oct. 23, 2010

[Pharo-project] fix for smallDebugIcon

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=3146

Oct. 23, 2010

[Pharo-project] smallDebugIcon kiss of death

by StÃ©phane Ducasse

smallDebugIcon "Answer a small debug icon." ^self smallDebugIcon Should be turned into ^ self smallErrorIcon Stef

Oct. 23, 2010

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

by Alain Plantec

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. 23, 2010

Re: [Pharo-project] Smells looking at collections

by StÃ©phane Ducasse

> > There was a discussion here a few weeks ago concerning a Trait I proposed called TComparable. It is the protocol of Magnitude bundled separately as a Trait, so any class can behave like Magnitude without having to inherit from Magnitude or use composition. You need only add "uses: TComparable" to the class template and then override its abstract methods as needed, and instances of your class will now be comparable. Association could use TComparable rather than inheriting from Magnitude, and, if the build system permits, Magnitude itself could be rewritten to use TComparable. Stef. approved of the idea and expressed a desire to see it in upcoming versions of Pharo, but I am not sure what the current status is. > > > That's a nice solution, but it means that Traits have to be in the Kernel. I have three problems with Traits: > 1) they are stateless > 2) they are different from classes > 3) incomplete tools support (this may be fixed in Pharo, but I doubt it is) 1) we build some code to see if we really need state and this is not that obvious and adding state is not trivial 2) well, this is difficult to get the money for the butter and the butter - we are trying. 3) again if nobody does anything and we just all cry on ourselves then nothing will happen. So for now identifying traits and learning is the way. Then we can refactor, redesign Stef

Oct. 23, 2010

Re: [Pharo-project] Smells looking at collections

by StÃ©phane Ducasse

This is in 1.2 :) Stef On Oct 23, 2010, at 4:55 PM, jaayer wrote: > > > > > ---- On Fri, 22 Oct 2010 04:56:28 -0700 NicolÃ¡s Paez wrote ---- > >> Hi, I was looking at collection packages and I found that the class Association inherits from Magnitude.It is really strange for me because inheritance represent a "is-a" relation. >> >> >> So I looked that the documentation of each of these classes: >> >> >> Association: I represent a pair of associated objects--a key and a value. My instances can serve as entries in a dictionary. >> >> >> Magnitude: I'm the abstract class Magnitude that provides common protocol for objects that have >> the ability to be compared along a linear dimension, such as dates or times. >> Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as >> Character and LookupKey. >> >> >> >> Based on this, I think this relation is conceptually WRONG. >> If the idea is to reuse code then composition should be used instead of inheritance. >> >> >> >> >> What do you think? >> >> Saludos! >> Nico. >> blog: nicopaez.wordpress.com > > There was a discussion here a few weeks ago concerning a Trait I proposed called TComparable. It is the protocol of Magnitude bundled separately as a Trait, so any class can behave like Magnitude without having to inherit from Magnitude or use composition. You need only add "uses: TComparable" to the class template and then override its abstract methods as needed, and instances of your class will now be comparable. Association could use TComparable rather than inheriting from Magnitude, and, if the build system permits, Magnitude itself could be rewritten to use TComparable. Stef. approved of the idea and expressed a desire to see it in upcoming versions of Pharo, but I am not sure what the current status is. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2010

Re: [Pharo-project] problem with metacello in 1.2

by Mariano Martinez Peck

I think you were having a problem with the internet connection. Here it is fine. Try again ;) 2010/10/23 Fabrizio Perin <fabrizio.perin(a)gmail.com> > Hi all, > i was trying to make Moose loadable into a 1.2 i did try to run the > configuration of Moose and i got an error at the very beginning caused by > the configuration of metacello. Am i missing something or it actually should > work? I did expect to have problem but not with the configuration of > metacello. > > I'm using a > > Pharo image 12203 on a Squeak4.2.5beta1U VM > > To reproduce the error just open the image and execute in a workspace: > > Gofer new > squeaksource: 'Moose'; > package: 'ConfigurationOfMoose'; > load. > (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault > > Attached the log. > > Thanks, > Fabrizio > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2010

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

by Marcus Denker

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.

Oct. 23, 2010

Re: [Pharo-project] Object>>at:modify:???

by Mariano Martinez Peck

2010/10/23 Guillermo Polito <guillermopolito(a)gmail.com> > Why not deprecate/remove the #deprecate: without the useful parameters? :D > > I said that few months ago: http://forum.world.st/what-about-deprecating-deprecated-td2306905.html#a230… :) > 2010/10/23 Mariano Martinez Peck <marianopeck(a)gmail.com> > > >> >> On Sat, Oct 23, 2010 at 1:32 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> Ok we can deprecate it. >>> >>> >> ys, but please please please use deprecated: anExplanationString on: date >> in: version >> >> cheers >> >> mariano >> >> >>> On Oct 22, 2010, at 11:04 PM, Hernan Wilkinson wrote: >>> >>> > In a 1.1 image I have, the class HttpRequest is using that message... >>> > >>> > On Thu, Oct 21, 2010 at 4:08 PM, stephane ducasse < >>> stephane.ducasse(a)free.fr> wrote: >>> > I would like to deprecate the following method since nobody use it. >>> > What do you think? >>> > >>> > Stef >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> > >>> > >>> > -- >>> > HernÃ¡n Wilkinson >>> > Agile Software Development, Teaching & Coaching >>> > Mobile: +54 - 911 - 4470 - 7207 >>> > email: hernan.wilkinson(a)10Pines.com >>> > site: http://www.10Pines.com >>> > >>> > _______________________________________________ >>> > 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 >

Oct. 23, 2010

Re: [Pharo-project] [update 1.2] #12209

by Alain Plantec

Le 23/10/2010 16:51, Marcus Denker a Ã©crit : > 12209 > ----- > > Issue 2525: SystemWindow out of focus color wrong hey! too fast ! :) I was just testing it and the fixe is not ok. I'm preparing the good one now. Alain

Oct. 23, 2010

Re: [Pharo-project] [update 1.2] #12209

by Mariano Martinez Peck

On Sat, Oct 23, 2010 at 4:51 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > 12209 > ----- > > Issue 3049: ClassBuilderTest > Issue 1746: ReferenceStream>>readOnlyFileNamed: is missing > Issue 1981: Raising DuplicateError Exception in class builder > Issue 2525: SystemWindow out of focus color wrong > Issue 3143: To mark a test as an expected failure, one has to overwrite > expectedFailures > A test can now be marked as an expected failure by adding an annotation <expectedFailure>. Good step! > > -- > 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. 23, 2010

Re: [Pharo-project] [update 1.2] #12210

by Mariano Martinez Peck

On Sat, Oct 23, 2010 at 5:16 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > 12210 > ----- > > Issue 2653: Editor cursor fix > Issue 3015: When a test is restarted in the debugger, #tearDown and > #setUp and not send > This is excellent and I suffer this problem several times. Thanks Hernan!!! > Issue 1853: NetNameResolver localHostAddress returns public or private > address instead of loopback address. > -- > 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. 23, 2010

Re: [Pharo-project] Smells looking at collections

by Levente Uzonyi

On Sat, 23 Oct 2010, jaayer wrote: > ---- On Fri, 22 Oct 2010 04:56:28 -0700 NicolÃ¡s Paez wrote ---- >Hi, I was looking at collection packages and I found that the class Association inherits from Magnitude.It is really strange for me because inheritance represent a "is-a" relation. > > >So I looked that the documentation of each of these classes: > > >Association:Â I represent a pair of associated objects--a key and a value. My instances can serve as entries in a dictionary. > > >Magnitude:Â I'm the abstract class Magnitude that provides common protocol for objects that have >the ability to be compared along a linear dimension, such as dates or times. > Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as >Character and LookupKey. > > > >Based on this, I think this relation is conceptually WRONG. >If the idea is to reuse code then composition should be used instead of inheritance. > > > > >What do you think? > >Saludos! >Nico. >blog: nicopaez.wordpress.com There was a discussion here a few weeks ago concerning a Trait I proposed called TComparable. It is the protocol of Magnitude bundled separately as a Trait, so any class can behave like Magnitude without having to inherit from Magnitude or use composition. You need only add "uses: TComparable" to the class template and then override its abstract methods as needed, and instances of your class will now be comparable. Association could use TComparable rather than inheriting from Magnitude, and, if the build system permits, Magnitude itself could be rewritten to use TComparable. Stef. approved of the idea and expressed a desire to see it in upcoming versions of Pharo, but I am not sure what the current status is. That's a nice solution, but it means that Traits have to be in the Kernel. I have three problems with Traits: 1) they are stateless 2) they are different from classes 3) incomplete tools support (this may be fixed in Pharo, but I doubt it is) Levente _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2010

Re: [Pharo-project] fixed issue 3025

by Marcus Denker

On Oct 23, 2010, at 5:05 PM, Fabrizio Perin wrote: > fixed 3025 > > http://code.google.com/p/pharo/issues/detail?id=3025. > > code in slice SLICE-Issue-3025-removedtest-FabrizioPerin.1.mcz in pharoinbox. > > The Slice seems to be empty -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 23, 2010

[Pharo-project] [update 1.2] #12210

by Marcus Denker

12210 ----- Issue 2653: Editor cursor fix Issue 3015: When a test is restarted in the debugger, #tearDown and #setUp and not send Issue 1853: NetNameResolver localHostAddress returns public or private address instead of loopback address. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 23, 2010

[Pharo-project] fixed issue 3025

by Fabrizio Perin

fixed 3025 http://code.google.com/p/pharo/issues/detail?id=3025. code in slice SLICE-Issue-3025-removedtest-FabrizioPerin.1.mcz in pharoinbox. Cheers, Fabrizio

Oct. 23, 2010

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

by Igor Stasenko

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.

Oct. 23, 2010

Re: [Pharo-project] Smells looking at collections

by jaayer

---- On Fri, 22 Oct 2010 04:56:28 -0700 NicolÃ¡s Paez wrote ---- >Hi, I was looking at collection packages and I found that the class Association inherits from Magnitude.It is really strange for me because inheritance represent a "is-a" relation. > > >So I looked that the documentation of each of these classes: > > >Association:Â I represent a pair of associated objects--a key and a value. My instances can serve as entries in a dictionary. > > >Magnitude:Â I'm the abstract class Magnitude that provides common protocol for objects that have >the ability to be compared along a linear dimension, such as dates or times. > Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as >Character and LookupKey. > > > >Based on this, I think this relation is conceptually WRONG. >If the idea is to reuse code then composition should be used instead of inheritance. > > > > >What do you think? > >Saludos! >Nico. >blog: nicopaez.wordpress.com There was a discussion here a few weeks ago concerning a Trait I proposed called TComparable. It is the protocol of Magnitude bundled separately as a Trait, so any class can behave like Magnitude without having to inherit from Magnitude or use composition. You need only add "uses: TComparable" to the class template and then override its abstract methods as needed, and instances of your class will now be comparable. Association could use TComparable rather than inheriting from Magnitude, and, if the build system permits, Magnitude itself could be rewritten to use TComparable. Stef. approved of the idea and expressed a desire to see it in upcoming versions of Pharo, but I am not sure what the current status is.

Oct. 23, 2010

[Pharo-project] [update 1.2] #12209

by Marcus Denker

12209 ----- Issue 3049: ClassBuilderTest Issue 1746: ReferenceStream>>readOnlyFileNamed: is missing Issue 1981: Raising DuplicateError Exception in class builder Issue 2525: SystemWindow out of focus color wrong Issue 3143: To mark a test as an expected failure, one has to overwrite expectedFailures -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 23, 2010