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

Re: [Pharo-project] [Metacello] Re: [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

by StÃ©phane Ducasse

I suggest that we avoid copy and paste. Why not having everything in the web pharo-book since we can - browse it on the web - generate latex and book for it - query it via help I do not see the point of having an ascii outdated version. We do not have the manpower for doing that. I'm already losing my time with svn since some people committed over my changes.... Stef On May 24, 2010, at 11:41 PM, Torsten Bergmann wrote: >> We should listen to Torsten but as far as I would expect, only HelpSystem, >> but it is already included in both PharoCore and Squeak. > > The help system is included in Squeak trunk and Pharo core, so > one should be able to load the three example books (Squeak, Pharo, > Metacello) which I uploaded in squeksource/HelpSystem in both > environments. Still they are just small demo books - no real > docu since there is not much content yet. > > However - we could reuse them to document these systems if > for instance Dale is willing to contribute stuff to the > Metacello book or we create an ASCII version of the Metacello > preview PBE chapter. Would be nice to have a real Metacello help book > that would be part of the Metacello distro (similar to the ProfStef > Tutorial on Metacello) ... > > Thanks > T. > > > > > > > > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 25, 2010

Re: [Pharo-project] Monticello keeps "diffing" forvever

by AxiNat

It seems it was a problem with my image, I started off with a clean image and now it's working properly.

May 25, 2010

[Pharo-project] About CodeMorph and Styler dependency

by Fernando olivero

Hi Stef, regarding some recent mails about CodeMorph and Shout dependency i don't know if you got this email. But i've removed the dependency from Shout and Styler. I'm still thinking about using Lukas petit parser to do the styling, or separating the Shout package in two different packages. One that deals with TextMorph and the other just for Styling text. Fernando Begin forwarded message: > From: Fernando olivero <oliverof(a)lu.unisi.ch> > Date: May 17, 2010 5:51:30 PM GMT+02:00 > To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> > Subject: Re: [Pharo-project] TextEditor and NewTextMorph merges and fixes > > De nada ! > > Actually i just published another version of the CodeMorph. > I found no need for subclassing CodeMorph, since the accepting behavior is on the announcements now, having specific ClassDescriptionMorph and MethodMorph wouldn't be beneficial. > Also removed the dependency with the Shout ( and the styler). > > > Name: Morphic-FernandoOlivero.589 > Rethought the CodeMorph class hierarchy, removed the subclasses and added CodeMorph class methods for creating > "MethodMorph" and "ClassDefinitionMorph" > > > Fernando > > On May 17, 2010, at 3:35 PM, StÃ©phane Ducasse wrote: > >> Tx!!!! >> Gaucho man >> >> On May 17, 2010, at 3:32 PM, Fernando olivero wrote: >> >>> Issue: 2375 >>> >>> Name: System-Text-FernandoOlivero.8 >>> Author: FernandoOlivero >>> Time: 17 May 2010, 3:22:14 pm >>> >>> >>> >>> ###################################### >>> Issue: -- >>> >>> Name: Morphic-FernandoOlivero.588 >>> Author: FernandoOlivero >>> Time: 17 May 2010, 1:42:04 pm >>> >>> >>> >>> _______________________________________________ >>> 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 >

May 25, 2010

Re: [Pharo-project] How to deal with issue 1594

by StÃ©phane Ducasse

Thanks gabriel and happy celebration! Stef On May 25, 2010, at 7:00 AM, Gabriel Cotelli wrote: > During the sprint in baires we write some tests to detect the senders of = nil to be replaced with isNil as the issue suggest. > > We now need to do a rewrite of this methods (this could be done using the refactoring engine as lukas proposed in the issue). However if I do this rewrite on the Dev image I will change code not only in Pharo Core but also in some external packages. Is it the intended scope of the issue?. > > I think that first we need to do the rewrite on Pharo Core code. > And let every package maintainer to decide if he wants to do it or not. Of course for the community maintained packages we can make that decision too. > > In the future I think would be good to have some kind of "Pharo Coding Practices" (or the name we want) that can be automatically tested. As a community we can discuss this practices and provide some automatic way to ensure that. > > As soon as posible I will create a Slice with the changes in Pharo Core and post it to the inbox (sorry if it takes me some days but here where are celebrating the argentinean bicentennial so i don't have too much free time this days :) ). > > Regards, > Gabriel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 25, 2010

Re: [Pharo-project] How to deal with issue 1594

by Igor Stasenko

2010/5/25 Gabriel Cotelli <g.cotelli(a)gmail.com>: > During the sprint in baires we write some tests to detect the senders of = > nil to be replaced with isNil as the issue suggest. and what if i intentionally may want to implement: MyClass>> = anObject ^ anObject == nil to make my object to be 'equal' to nil? > We now need to do a rewrite of this methods (this could be done using the > refactoring engine as lukas proposed in the issue). However if I do this > rewrite on the Dev image I will change code not only in Pharo Core but also > in some external packages. Is it the intended scope of the issue?. > I think that first we need to do the rewrite on Pharo Core code. > And let every package maintainer to decide if he wants to do it or not. Of > course for the community maintained packages we can make that decision too. > In the future I think would be good to have some kind of "Pharo Coding > Practices" (or the name we want) that can be automatically tested. As a > community we can discuss this practices and provide some automatic way to > ensure that. > As soon as posible I will create a Slice with the changes in Pharo Core and > post it to the inbox (sorry if it takes me some days but here where are > celebrating the argentinean bicentennial so i don't have too much free time > this days :) ). > Regards, > Gabriel > > _______________________________________________ > 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.

May 25, 2010

[Pharo-project] How to deal with issue 1594

by Gabriel Cotelli

During the sprint in baires we write some tests to detect the senders of = nil to be replaced with isNil as the issue suggest. We now need to do a rewrite of this methods (this could be done using the refactoring engine as lukas proposed in the issue). However if I do this rewrite on the Dev image I will change code not only in Pharo Core but also in some external packages. Is it the intended scope of the issue?. I think that first we need to do the rewrite on Pharo Core code. And let every package maintainer to decide if he wants to do it or not. Of course for the community maintained packages we can make that decision too. In the future I think would be good to have some kind of "Pharo Coding Practices" (or the name we want) that can be automatically tested. As a community we can discuss this practices and provide some automatic way to ensure that. As soon as posible I will create a Slice with the changes in Pharo Core and post it to the inbox (sorry if it takes me some days but here where are celebrating the argentinean bicentennial so i don't have too much free time this days :) ). Regards, Gabriel

May 25, 2010

[Pharo-project] New weak finalization support. Implementation

by Igor Stasenko

Hello, i updated the weak finalization classes. I made its behavior/protocol similar to old WeakRegistry, also all weak registry tests on new class is green. First, file in .st then .cs Also, don't forget about special objects array: http://bugs.squeak.org/view.php?id=7525 And sure thing, you will need a VM support for it. But I am unsure, how to introduce a fallback code (and do we really need it)? I thought, that i could just add a simple startUp routine which does GC to see if new finalization supported by VM. Then it could pick either WeakFinalizationRegistry or old WeakRegistry. But then, it will slow down the image startup significantly, not saying that John fought hard to avoid full memory/heap walk during image startup on iPhone. So, maybe introduce an additional prim into VM, which will tell us if it supports new finalization? Or query the VM version? I need your advice. -- Best regards, Igor Stasenko AKA sig.

May 25, 2010

Re: [Pharo-project] ClassTestCase

by John M McIntosh

On 2010-05-24, at 7:22 PM, Levente Uzonyi wrote: > Inlining more methods is a bad idea IMHO. It makes the compiler and the decompiler more complex. An inlining JIT is the real solution. > > > Levente If it's smalltalk code underfoot then likely a bunch of people might have an interest or at least be able to hack, criticize, be happy, or ignore it. If it's a JIT buried in SLANG, C or assembler then I'd guess not more than 5 people would know anything about how it works, or figure out how to fix it. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

May 25, 2010

Re: [Pharo-project] ClassTestCase

by Francisco Ortiz PeÃ±aloza

Is "isNil" really more readable than "== nil"? imho yes... i find it more readable, more "smalltalkish" but the conversation ended up being about performance rather than if it's more readable or not so obviously there is a bigger issue :) Francisco On Mon, May 24, 2010 at 11:22 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Mon, 24 May 2010, John M McIntosh wrote: > >> >> On 2010-05-24, at 1:47 PM, Levente Uzonyi wrote: >> >>> On Mon, 24 May 2010, Lukas Renggli wrote: >>> >>>>> IMHO 4 is the most readable and it is the fastest in Pharo/Squeak at >>>>> the >>>>> moment, so that should be preferred in core packages. >>>> >>>> It should not be preferred or changes unless you can prove a real >>>> performance benefit. I still haven't seen a single realistic benchmark >>>> with real code (from Pharo, Seaside, Pier, ...) where you can measure >>>> a real difference between these 4 variants. >>> >>> Well, just replace all uses of == nil and #ifNil:, etc with isNil and >>> isNil ifTrue: etc. Then get some benchmarks which you accept as realistic >>> and run them in both images. >>> >> >> >> Well what is going on is that you are changing the >> foo isNil ifTrue: >> which is a message send for the isNil into a >> foo == nil ifTrue: >> which then does an object identity check in byte codes. >> >> Because messages sends are *slow* removing one from millions of executions >> does improve things. >> >> However what be more clever is changing the compiler to optimize the use >> of isNil so you maintain readability without a performance penalty. > > Is "isNil" really more readable than "== nil"? > >> >> Also consider 'first' 'second' >> >> Well and the case of the simple accessor >> >> self foo ifTrue:[] >> where >> foo >> ^foo > > Inlining more methods is a bad idea IMHO. It makes the compiler and the > decompiler more complex. An inlining JIT is the real solution. > > > Levente > >> >> >> -- >> >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Â Twitter: >> Â squeaker68882 >> Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com >> >> =========================================================================== >> >> >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 25, 2010

[Pharo-project] Monticello keeps "diffing" forvever

by AxiNat

Hi all, A package I had uploaded to monticello was corrupt, and besides -I think it's not relevant, but just in case- squeaksource was down so it was only saved locally. When I realized that the version was corrupt I erased it from the repo, and now every time I try to save a new version it stays "Diffing" forever, should I wait for it to finish (I'm beginning to lose faith in this ever happening) or take a different approach? Thanks! Bernat Romagosa.

May 25, 2010