- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] ClassTestCase

by Levente Uzonyi

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 > =========================================================================== > > > > >

May 25, 2010

Re: [Pharo-project] Problem with Demo mode [WAS] Re: [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

by Serge Stinckwich

On Mon, May 24, 2010 at 11:02 PM, Alain Plantec <alain.plantec(a)free.fr> wrote: > Le 24/05/2010 16:53, Mariano Martinez Peck a Ã©crit : >> >> >> On Mon, May 24, 2010 at 11:56 AM, Serge Stinckwich >> <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>> wrote: >> >> Â Â When i switch to demo mode, method selector in System Browser are no >> Â Â more bold in the bottom pane. >> >> >> I didn't understand you. Could you please attach both screenshots: how it >> should be and how is it ? >> >> Alain do you know about this ? > > Hi, > Strange, I've tested and all is ok here. > could you try with > -------- > StandardFonts setDemoFonts > -------- > > Alain >> >> Cheers > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

May 25, 2010

Re: [Pharo-project] ClassTestCase

by John M McIntosh

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. Also consider 'first' 'second' Well and the case of the simple accessor self foo ifTrue:[] where foo ^foo -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

May 25, 2010

[Pharo-project] FFI debugging lesson

by Schwab,Wilhelm K

I did some FFI based work in Pharo 1.0 and realized something that I found surprising; this might help others new to it. An incorrect argument type in a call spec does not result in a compile-time error; instead it leads to "Cannot coerce arguments" at the time of the call. FWIW. Bill

May 24, 2010

[Pharo-project] ConnectionQueue defect in 1.0

by Schwab,Wilhelm K

Hello all, Attached is a simple test for networking. It passed in 1.0 RC1 and fails in 1.0 and in 1.1 beta. The problem arises in ConnectionQueue>>listenLoop. #waitForConnectionFor: returns a boolean, not the new socket, and the listen loop looks like it is expecting the socket. Any ideas? Bill

May 24, 2010

Re: [Pharo-project] Latex to HelpSystem converter? [WAS] Re: [Metacello] Re: [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

by Dale Henrichs

Mariano Martinez Peck wrote: > > On Mon, May 24, 2010 at 11:41 PM, Torsten Bergmann <astares(a)gmx.de<mailto:astares@gmx.de>> 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. I have pulled the Metacello-Help package over to the metacello repository and have added to a baseline for 1.0-beta.27... but it should have more content... > > 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. Mariano is actually doing all of the heavy lifting on the PBE chapter:) > > Maybe I am dreaming too much, but it would be cool to export somehow some chapters to HelpSystem. > Is there a way to export from Latex to ASCII ? even more, how difficult could be to code a plugin (or whatever name is) to automatically generate the nice code for HelpSystem from Latex code? > > Then we can include PBE in the image also ;) This would be very cool! It seems that there is a place for online (pdf..) documentation, but the online and in-image documentation really needs to stay in synch! Dale

May 24, 2010

[Pharo-project] Latex to HelpSystem converter? [WAS] Re: [Metacello] Re: [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

by Mariano Martinez Peck

On Mon, May 24, 2010 at 11:41 PM, Torsten Bergmann <astares(a)gmx.de> 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. Maybe I am dreaming too much, but it would be cool to export somehow some chapters to HelpSystem. Is there a way to export from Latex to ASCII ? even more, how difficult could be to code a plugin (or whatever name is) to automatically generate the nice code for HelpSystem from Latex code? Then we can include PBE in the image also ;) Cheers Mariano > 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 24, 2010