- Pharo-dev - lists.pharo.org

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

by Torsten Bergmann

>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

May 24, 2010

Re: [Pharo-project] Old configuration options

by Mariano Martinez Peck

On Mon, May 24, 2010 at 11:25 PM, nullPointer <epicfan(a)gmail.com> wrote: > > I did probe the new developer image verion 1.1, and donÂ´t see options like > "easySelection", very useful when works continoously with morphs. That > option is lost or is usable in another place? > > See issue: http://code.google.com/p/pharo/issues/detail?id=1568 I cc'ed Alain. Cheers Mariano > Thanks for the answers. > -- > View this message in context: > http://forum.world.st/Old-configuration-options-tp2229221p2229221.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > 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

[Pharo-project] Old configuration options

by nullPointer

I did probe the new developer image verion 1.1, and donÂ´t see options like "easySelection", very useful when works continoously with morphs. That option is lost or is usable in another place? Thanks for the answers. -- View this message in context: http://forum.world.st/Old-configuration-options-tp2229221p2229221.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 24, 2010

Re: [Pharo-project] ClassTestCase

by StÃ©phane Ducasse

5 % is cool in such scenario. Thanks levente. I believe in small speed ups and you show that. Stef On May 24, 2010, at 10: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. > > For now I can only show a microbenchmark that I evaluated in PharoCore-1.1-11367 on my slow machine: > > Original: > (1 to: 5) collect: [ :run | > FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | > [ [ file next isNil ] whileFalse ] timeToRun ] ] > #(9928 9733 9753 9703 9711) > > Then I replaced the #isNil send to == nil: > > (1 to: 5) collect: [ :run | > FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | > [ [ file next == nil ] whileFalse ] timeToRun ] ] > #(9214 9301 9419 9273 9285) > > Not bad 4.8% faster. Then I replaced the line > character1 isNil ifTrue: [^ nil]. > with > character1 ifNil: [^ nil]. > in UTF8TextConverter >> #nextFromStream:. > > (1 to: 5) collect: [ :run | > FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | > [ [ file next == nil ] whileFalse ] timeToRun ] ] > #(8947 8779 8814 8845 8810). > 5% faster than the previous. > > Removing 2 #isNil sends from the tight loop gave ~10% speedup. > > > Levente > >> >> >>> 1 just looks bad, I can't imagine an OODB that doesn't map it's "null >>> object" directly to nil, otherwise #= will be asymmetric: >>> null = nil -> true >>> nil = null -> false >> >> That's not the problem. The problem is when you have proxy objects >> then all these inlined an shortcut variants fail miserably. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> 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 24, 2010

Re: [Pharo-project] ClassTestCase

by Levente Uzonyi

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. For now I can only show a microbenchmark that I evaluated in PharoCore-1.1-11367 on my slow machine: Original: (1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next isNil ] whileFalse ] timeToRun ] ] #(9928 9733 9753 9703 9711) Then I replaced the #isNil send to == nil: (1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next == nil ] whileFalse ] timeToRun ] ] #(9214 9301 9419 9273 9285) Not bad 4.8% faster. Then I replaced the line character1 isNil ifTrue: [^ nil]. with character1 ifNil: [^ nil]. in UTF8TextConverter >> #nextFromStream:. (1 to: 5) collect: [ :run | FileStream readOnlyFileNamed: (SourceFiles at: 1) name do: [ :file | [ [ file next == nil ] whileFalse ] timeToRun ] ] #(8947 8779 8814 8845 8810). 5% faster than the previous. Removing 2 #isNil sends from the tight loop gave ~10% speedup. Levente > > >> 1 just looks bad, I can't imagine an OODB that doesn't map it's "null >> object" directly to nil, otherwise #= will be asymmetric: >> null = nil -> true >> nil = null -> false > > That's not the problem. The problem is when you have proxy objects > then all these inlined an shortcut variants fail miserably. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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

Re: [Pharo-project] Concurrency in Pharo?

by Adrian Lienhard

Hi Andrei, 1) is what most do (at least what we do at netstyle.ch for apps that can have higher loads). The following blog post is a nice writeup from Ramon Leon describing how to implement such a system: http://onsmalltalk.com/scaling-seaside-more-advanced-load-balancing-and-pub… HTH, Adrian On May 24, 2010, at 20:47 , Mariano Martinez Peck wrote: > This is a good question. I don't have experience by myself but I can tell > you what I think it is usually done: > > 1) For one CPU: > > If the image don't need to be saved (no need of in image persistence) you > can take the same VM and load N number of images running at the same .image. > You can even not use .changes and .sources. Each image in different port. > Then, you have in front of them a web server (Apache or friends) and you do > load balance. The only thing you should take care with Seaside is to have > AFFINITY -> the same client should go always to the same image while a > conversation occurs. This is just a web-server setting. > > 2) For multiple core, I am thinking, maybe I am wrong, you may be able to > load different vms. For assigning each VM to a particular CPU. I don't know > windows, but in Linux (maybe I am wrong) I think you can specify where to > exclusively run a process. The, for each VM you do 1). > Do you know if this can work? > > Finally, there are different VM that aim not necessary multiple CPU but > similar: > > - COG VM > - Hydra > > I cc'ed may developers of them so that they can help you. > > Cheers > > Mariano > > > 2010/5/24 Andrei Stebakov <lispercat(a)gmail.com> > >> I've been really impressed with what Seaside and Pier were capable of and >> really wanted to start my new web project with Pharo. >> I learned that Pharo (and most other open source ST implementations) only >> use green threads, having no ability to use a multi-core CPU systems. >> For those of you with experience building mid to heavy load web sites, how >> do you expect them to scale up on using just one core? >> Is Pharo a right tool for that? >> Maybe Pharo (Squeak) has something up its sleeve to handle this, but my >> heart really sank when I learned about this issue... >> >> Thank you, >> Andrei >> >> _______________________________________________ >> 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 24, 2010

[Pharo-project] [update 1.1] #11371

by StÃ©phane Ducasse

11371 ----- - Issue 1281: Button in TestRunner to fileout the test results. Thanks Laurent. - Issue 2468: Better method trailer method creation. Part One. Thanks Igor. - Issue 2406: MovieMorph should be removed from the core. Thanks Alain. - Issue 2467: AlllocationTest#testOutOfMemorySignal fails. Thanks Laurent - Issue 2331: Reuse test unload - Now there is an SUnitUnloader. Thanks Guillermo. Stef

May 24, 2010

Re: [Pharo-project] ClassTestCase

by Lukas Renggli

> 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. > 1 just looks bad, I can't imagine an OODB that doesn't map it's "null > object" directly to nil, otherwise #= will be asymmetric: > null = nil -> true > nil = null -> false That's not the problem. The problem is when you have proxy objects then all these inlined an shortcut variants fail miserably. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 24, 2010

Re: [Pharo-project] ClassTestCase

by Levente Uzonyi

On Mon, 24 May 2010, Lukas Renggli wrote: >> For now the list of levente and a slow machine >> >> Â Â Â Â "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible." >> is the one to use > > Please read my comments on the issue tracker. > > For *any practical* example it doesn't matter what to use speed wise: That's not true. Most of the time it doesn't matter, but when these checks/conditional statements are in tight loops they can make a huge difference. Core packages have some good code examples and those have to be fast, but not cross-dialect. I'm sure other smalltalks are implemented this way. > > 1 = nil ifTrue: [ ] > 2 == nil ifTrue: [ ] > 3 isNil ifTrue: [ ] > 4 ifNil: [ ] 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. 2 is cross-dialect and it's probably the fastest in all dialects, so if I were writing cross-dialect code then I'd probably use that. 3 looks nice and #isNil is inlined in some dialects (AFAIK), but it's "slow" in Squeak/Pharo. 1 just looks bad, I can't imagine an OODB that doesn't map it's "null object" directly to nil, otherwise #= will be asymmetric: null = nil -> true nil = null -> false Btw I hope we will have an inlining JIT soon which can decrease/eliminate these performance differences. Levente > > Personally I find 3 the most readable. 1 and 3 are the only practical > ones if you use OODBs, because they are not shortcut by the compiler. > > I only use 4 for lazy initializers, it makes a good pattern. The use > of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable > if you don't care about compatibility with other Smalltalk dialects. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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

Re: [Pharo-project] Concurrency in Pharo?

by Igor Stasenko

On 24 May 2010 21:47, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > This is a good question. I don't have experience by myself but I can tell > you what I think it is usually done: > > 1) For one CPU: > > If the image don't need to be saved (no need of in image persistence) you > can take the same VM and load N number of images running at the same .image. > You can even not use .changes and .sources. Each image in different port. > Then, you have in front of them a web server (Apache or friends) and you do > load balance. The only thing you should take care with Seaside is to have > AFFINITY -> the same client should go always to the same image while a > conversation occurs. This is just a web-server setting. > > 2) For multiple core, I am thinking, maybe I am wrong, you may be able to > load different vms. For assigning each VM to a particular CPU. I don't know > windows, but in Linux (maybe I am wrong) I think you can specify where to > exclusively run a process. The, for each VM you do 1). > Do you know if this can work? > 3) write a good code, so it could handle things well without need of so much horsepower :) > Finally, there are different VM that aim not necessary multiple CPU but > similar: > > - COG VM > - Hydra > > I cc'ed may developers of them so that they can help you. > > Cheers > > Mariano > > > 2010/5/24 Andrei Stebakov <lispercat(a)gmail.com> >> >> I've been really impressed with what Seaside and Pier were capable of and >> really wanted to start my new web project with Pharo. >> I learned that Pharo (and most other open source ST implementations) only >> use green threads, having no ability to use a multi-core CPU systems. >> For those of you with experience building mid to heavy load web sites, how >> do you expect them to scale up on using just one core? >> Is Pharo a right tool for that? >> Maybe Pharo (Squeak) has something up its sleeve to handle this, but my >> heart really sank when I learned about this issue... >> Thank you, >> Andrei >> _______________________________________________ >> 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 24, 2010