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

Re: [Pharo-project] Core font

by Adrian Lienhard

Yes, that is possible. We have the Cuis fonts integrated and can use them in the core. Like this we can also remove the (ugly) Accuny font. Any taker? Adrian On Nov 11, 2009, at 13:43 , Torsten Bergmann wrote: > The squeak trunk has a nice looking default font compared > to pharo core (without Freetype). > > Wasnt that related to some Cuis changes that were also > integrated into Pharo already? Any chance we can get that > too? Just curious... > > Thx > Torsten > > > -- > DSL-Preisknaller: DSL Komplettpakete von GMX schon fÃ¼r > 16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 11, 2009

[Pharo-project] Core font

by Torsten Bergmann

The squeak trunk has a nice looking default font compared to pharo core (without Freetype). Wasnt that related to some Cuis changes that were also integrated into Pharo already? Any chance we can get that too? Just curious... Thx Torsten -- DSL-Preisknaller: DSL Komplettpakete von GMX schon fÃ¼r 16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02

Nov. 11, 2009

[Pharo-project] [update 1.1] #11040

by Marcus Denker

11040 ----- Issue 1432: HttpUrl fix Issue 1367: MessageTally>>spyOn:cutoff: Issue 1433: ByteSymbol DNU #hasWideCharacterFrom:to: Issue 1384: TransparentColor instance return false when #isSelfEvaluating is called

Nov. 11, 2009

Re: [Pharo-project] SystemVersion

by Michael Roberts

ok cool. before i propose changes, does anyone have any opinion on this mantis entry copied to our tracker. Damien? http://code.google.com/p/pharo/issues/detail?id=1012 If no one does I suggest to close it. thanks, Mike On Tue, Nov 10, 2009 at 8:38 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > No I checked Â by accident after and this is better than before because it was in SystemVersion packge :) > > On Nov 10, 2009, at 9:29 PM, Michael Roberts wrote: > >>> Now this class should not be alone in one package. >> >> do you mean it shouldn't be in System-Support? Â Or in a better named >> package? Â System-Support is a mixed bag of classes. >> >> thanks, >> Mike >> >> _______________________________________________ >> 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. 10, 2009

Re: [Pharo-project] SystemVersion

by StÃ©phane Ducasse

No I checked by accident after and this is better than before because it was in SystemVersion packge :) On Nov 10, 2009, at 9:29 PM, Michael Roberts wrote: >> Now this class should not be alone in one package. > > do you mean it shouldn't be in System-Support? Or in a better named > package? System-Support is a mixed bag of classes. > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 10, 2009

Re: [Pharo-project] SystemVersion

by Michael Roberts

> Now this class should not be alone in one package. do you mean it shouldn't be in System-Support? Or in a better named package? System-Support is a mixed bag of classes. thanks, Mike

Nov. 10, 2009

[Pharo-project] Nice picture :)

by StÃ©phane Ducasse

a symbolic one :) Begin forwarded message: > From: Samuel MORELLO <samuel.morello(a)ouvanous.com> > Date: November 10, 2009 4:58:38 PM GMT+01:00 > To: StÃ©phane DUCASSE <stephane.ducasse(a)inria.fr> > > Salut, > > Je me suis dis que tu aimerai cette photo ;-) > http://www.fubiz.net/2009/11/08/ibai-acevedo/ibai8/ > > A+ > Samuel

Nov. 10, 2009

Re: [Pharo-project] why we should kill project

by Igor Stasenko

In defence to the author, i could say, that sometimes its really hard to follow KISS principle, especially when problem domain requires many conditions to be checked and hence you inevitably need to introduce branches in code. Sometimes, when code start stinking you can look back at model and find the way to simplify it, but sometimes you simply can't do that (consider bussiness logic ) :) And of course, for a novice programmer it is crucial to have a master, who can revise his code and teach how to write a good code, point at mistakes and so on.. Even not for novice, even i prefer to have someone who could revise my code, because in this way there are less chances that you miss something or doing awfully wrong unnoticed. 2009/11/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Nov 10, 2009, at 8:44 PM, John M McIntosh wrote: > >> >> On 2009-11-10, at 7:40 AM, StÃ©phane Ducasse wrote: >> >>> if you want to have fun try to identify the number of times certain >>> parts are duplicated inside the same method. >>> >>> Stef >> >> Actually an interesting exercise here would be to determine who >> originally wrote the method, then >> decide is it a result of the author's original coding, or the result >> of 10 people hacking it. >> >> If it's mostly the result of a single author, then I'm sure some nifty >> tool (someone could write) could >> determine which other methods the person authored then kick out the >> more complex ones and >> decide if the same coding practises are followed, er then mark them as >> candidates for simplification? > > :) > you know I found a fun one > Â Â Â Â self flag: #aname. "klhkjhjk" > Â Â Â Â self flag: #aname. "hkjkjhkj" > >> I mention this because it reminded me of a project I was on years ago >> where after a consultant had >> left we determined his code was problematic based on bug reports >> statistics and at 2:00 am one >> morning I and the senior project leader pressed *delete* on all that >> code base since we had >> decided it was cheaper to rewrite it all from scratch versus fixing it. > > :) > > Probably we should have done it several years ago but we are making progress daily. > > Stef > _______________________________________________ > 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.

Nov. 10, 2009

Re: [Pharo-project] why we should kill project

by StÃ©phane Ducasse

On Nov 10, 2009, at 8:44 PM, John M McIntosh wrote: > > On 2009-11-10, at 7:40 AM, StÃ©phane Ducasse wrote: > >> if you want to have fun try to identify the number of times certain >> parts are duplicated inside the same method. >> >> Stef > > Actually an interesting exercise here would be to determine who > originally wrote the method, then > decide is it a result of the author's original coding, or the result > of 10 people hacking it. > > If it's mostly the result of a single author, then I'm sure some nifty > tool (someone could write) could > determine which other methods the person authored then kick out the > more complex ones and > decide if the same coding practises are followed, er then mark them as > candidates for simplification? :) you know I found a fun one self flag: #aname. "klhkjhjk" self flag: #aname. "hkjkjhkj" > I mention this because it reminded me of a project I was on years ago > where after a consultant had > left we determined his code was problematic based on bug reports > statistics and at 2:00 am one > morning I and the senior project leader pressed *delete* on all that > code base since we had > decided it was cheaper to rewrite it all from scratch versus fixing it. :) Probably we should have done it several years ago but we are making progress daily. Stef

Nov. 10, 2009

Re: [Pharo-project] why we should kill project

by John M McIntosh

On 2009-11-10, at 7:40 AM, StÃ©phane Ducasse wrote: > if you want to have fun try to identify the number of times certain > parts are duplicated inside the same method. > > Stef Actually an interesting exercise here would be to determine who originally wrote the method, then decide is it a result of the author's original coding, or the result of 10 people hacking it. If it's mostly the result of a single author, then I'm sure some nifty tool (someone could write) could determine which other methods the person authored then kick out the more complex ones and decide if the same coding practises are followed, er then mark them as candidates for simplification? I mention this because it reminded me of a project I was on years ago where after a consultant had left we determined his code was problematic based on bug reports statistics and at 2:00 am one morning I and the senior project leader pressed *delete* on all that code base since we had decided it was cheaper to rewrite it all from scratch versus fixing it. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 10, 2009