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

Re: [Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)

by Alexandre Bergel

Thanks Michael and Antony about this discussion. cheers, Alexandre On 23 Mar 2009, at 09:30, StÃ©phane Ducasse wrote: > Michael > there is no problem. > discussion is also good. Dogma or trolling would be boring :) > > On Mar 23, 2009, at 12:42 AM, Michael van der Gulik wrote: > >> >> >> On Mon, Mar 23, 2009 at 11:39 AM, Antony Blakey <antony.blakey(a)gmail.com >>> wrote: >> >> On 23/03/2009, at 7:37 AM, Michael van der Gulik wrote: >> >> >> >>> Smalltalk, the language rather than the implementation, already has >>> fantastic support for concurrency. Smalltalkers just don't know how >>> to use it. We don't need to rethink the model, we just need to learn >>> to use what we have. >> >> Mutexes and semaphores are hardly 'fantastic'. The state of the art >> in >> support for concurrency is way beyond what Smalltalk provides - >> locking is both primitive and generally not scalable. >> >> >> Semaphores _are_ fantastic!! Lock-free algorithms are even cooler. >> >> The language lends itself to building up higher abstractions. Take >> for example Collection and all its subclasses; they're screaming out >> to have parallelised versions made: >> >> c := ConcurrentOrderedCollection new. >> c do: [ :each | ...this part gets executed in parallel...]. >> >> The caveat here is that you need to be careful about side-effects. >> >> This is just one example. I have some more rudimentary ideas at: >> http://gulik.pbwiki.com/Parallel+processing. >> >> Oh, and sorry to the Pharo guys for keeping this going. Let us know >> if you don't want threads like this on your list. >> >> Gulik. >> >> >> -- >> http://gulik.pbwiki.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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 24, 2009

Re: [Pharo-project] tooltips for inspector 'mystery' buttons

by Damien Cassou

On Mon, Mar 23, 2009 at 5:33 PM, Dale Henrichs <dale.henrichs(a)gemstone.com> wrote: > With 10259, there are tool tips for the 'mystery' buttons in the inspectors... > > If you have added a custom inspector method, you need to add #tooltip: to your pragama like the following for Object>>basicInspectorNodes: > > Â <inspector: #'1' priority: 600 toolTip: 'Basic elements'> Nice, thank you -- Damien Cassou http://damiencassou.seasidehosting.st

March 24, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Kernel fixes

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=688 On Mar 24, 2009, at 8:50 AM, Michael Rueger wrote: > Hi all, > > haven't looked at it in detail so I don't know for example which > "other changes" are needed, but I think we definitely should integrate > the necessary fixes (if not done so already, hope I'm not proving > myself ignorant here ;-)). > > Any takers? > > Michael > > > > ---------- Forwarded message ---------- > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: Tue, Mar 24, 2009 at 4:34 AM > Subject: [squeak-dev] Kernel fixes > To: The general-purpose Squeak developers list > <squeak-dev(a)lists.squeakfoundation.org> > > > Folks - > > While fixing Semaphore>>waitTimeoutMSecs: in our internal images, I > noticed that 3.10 was still missing a number of important Kernel fixes > that we've long taken for granted. If you run servers or rely > otherwise on heavy process/delay/semaphore usage you will definitely > want to apply the fixes provided at > http://bugs.squeak.org/view.php?id=7321 > > To install, either download the patches or just execute: > > Installer mantis fixBug: 7321. > > Do note that these fixes apply only to 3.10 since they assume other > changes to be present (so they won't work against 3.9 for example). > Also, they depend on each other so unless you are really careful you > should not pick and choose (this is why they are filed as a single > bug). > > Cheers, > - Andreas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 24, 2009

Re: [Pharo-project] seaside & pier on the iPhone

by Michael Roberts

Hi John, I would like to beta test your application. Mainly just to see it running and to understand Smalltalk on the iPhone and the beta testing mechanism. I'm not sure what information you need. My serial is: 889056XJY7K. If you need my UUID, how do I copy it from itunes or the phone? thanks Mike On Sun, Mar 22, 2009 at 4:57 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > For a couple of months now I have been working on a seaside/pier based > Wiki for the iPhone. > > I am now about a week away from sending it off to the Apple app store. > > However I'd like to broaden the beta test group a bit so I can catch > any issues before I submit it, especially in the area of persistency > storage. > > So what's it good for? I was asked that question this week, but let me > turn it around and ask: > > Good question what is Seaside and Pier good for? > > An iPhone Wiki? > Well... > > It's a handy construct for consolidating a bunch of PDF documents > since the mobile Safari Browser does a fine job of rendering them on > the device and a WIki does a fine job of providing a navigation > framework, but I'm sure there are other more important answers out > there somewhere? > > So > > Anyone who would like to participate as a beta tester can send me > email with a description of what they would use the Wiki for, and > supply their iPhone or iPod touch's device identifier and I'll look > into sending them a copy of the app. > > > -- > = > = > = > ======================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > 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 >

March 24, 2009

[Pharo-project] Fwd: [squeak-dev] Kernel fixes

by Michael Rueger

Hi all, haven't looked at it in detail so I don't know for example which "other changes" are needed, but I think we definitely should integrate the necessary fixes (if not done so already, hope I'm not proving myself ignorant here ;-)). Any takers? Michael ---------- Forwarded message ---------- From: Andreas Raab <andreas.raab(a)gmx.de> Date: Tue, Mar 24, 2009 at 4:34 AM Subject: [squeak-dev] Kernel fixes To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Folks - While fixing Semaphore>>waitTimeoutMSecs: in our internal images, I noticed that 3.10 was still missing a number of important Kernel fixes that we've long taken for granted. If you run servers or rely otherwise on heavy process/delay/semaphore usage you will definitely want to apply the fixes provided at http://bugs.squeak.org/view.php?id=7321 To install, either download the patches or just execute: Â Â Â Â Installer mantis fixBug: 7321. Do note that these fixes apply only to 3.10 since they assume other changes to be present (so they won't work against 3.9 for example). Also, they depend on each other so unless you are really careful you should not pick and choose (this is why they are filed as a single bug). Cheers, Â - Andreas

March 24, 2009

Re: [Pharo-project] New Pharo-dev AND web based on 10259

by Serge Stinckwich

On Mon, Mar 23, 2009 at 10:08 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Here are pharo-dev and pharo-web based on latest 10259 before Closure: > http://code.google.com/p/pharo/wiki/Downloads?tm=2 Thank you Damien. ScriptLoader loadSuperOB. does not work in this image. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

March 24, 2009

Re: [Pharo-project] seaside & pier on the iPhone

by John M McIntosh

Web site goes live http://www.mobilewikiserver.com Still need a few more beta testers. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

March 24, 2009

Re: [Pharo-project] Unicode merge

by StÃ©phane Ducasse

Loaded without problems after I paste "Le volcan, qui culmine Ã 3.108 m, se trouve Ã 170 km au sud-ouest d'Anchorage, la plus grande agglomÃ©ration d'Alaska, dont les habitants ont jusqu'ici Ã©tÃ© Ã©pargnÃ©s par les projections. Les compagnies aÃ©riennes ont Ã©tÃ© invitÃ©es Ã contourner la zone." and got shortcut error. debug? code is nil in Unicode class>>value: on mac english keyboard, english OS. stef On Mar 23, 2009, at 4:40 PM, Michael Rueger wrote: > Hi all, > > in the process of merging the unicode work into the current system I > will upload a bunch of packages to the inbox. The packages will not > load > as they are, will need some config maps etc to load it all. > > I will let you know when I figured out a way how to load > everything :-) > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2009

Re: [Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)

by Michael van der Gulik

On Mon, Mar 23, 2009 at 4:49 PM, Michael van der Gulik <mikevdg(a)gmail.com>wrote: > > > On Mon, Mar 23, 2009 at 2:21 PM, Michael van der Gulik <mikevdg(a)gmail.com>wrote: > >> >> >> On Mon, Mar 23, 2009 at 12:34 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >> >>> >>> Now consider the overhead of creating a fork vs the actual useful code >>> which is running within a block. >>> I presume, this code will run 10x times slower on a single core >>> processor, comparing to one w/o forks. >>> So, you will need to have 10 cores to match the computation time with >>> single core processor. >>> >>> I think its not wise to introduce parallelism on such low levels (in >>> Concurrent.Collections.Array>>withIndexDo:). Its like hammering nails >>> with microscope :) >>> >>> That's why i'm saying its too good to be true. >>> Introducing parallelism at such low levels will be a waste. I leaning >>> toward island model. This is a middle point between no sharing, like >>> in Hydra and sharing everything, like in what you proposing. >>> >> >> 10 times slower? Sounds like a made-up number to me... >> >> " Using 101 threads: " >> c := ConcurrentArray new: 1000001. >> Time millisecondsToRun: [c withIndexDo: [ :each :i | c at: i put: i >> asString. ]]. >> 5711 >> 5626 >> 6074 >> >> " Using 11 threads: " >> c := ConcurrentArray new: 1000001. >> Time millisecondsToRun: [c withIndexDo: [ :each :i | c at: i put: i >> asString. ]]. >> 3086 >> 3406 >> 3256 >> >> " Using 1 thread: " >> d := Array new: 1000001. >> Time millisecondsToRun: [d withIndexDo: [ :each :i | d at: i put: i >> asString]]. >> 2426 >> 2610 >> 2599 >> >> My implementation is 1/2 to 1/3 the speed of the single-threaded Array. If >> the blocks did more work, then the overhead would be lower and some benefit >> would be gained from using multiple cores. >> >> I don't have a good idea of where the overhead is going - maybe it's being >> lost in the block copying that is needed to work around Squeak's >> deficiencies? Or maybe it's waiting for the scheduler to do its stuff? >> >> Implementation attached, MIT license if you're picky. >> >> > I just tried it on VisualWorks as well. I removed the block copying and > renamed the method to "keysDo:" (I never thought of an array like that > before... keys and values). > > d := Array new: 1000001. > Time millisecondsToRun: [d keysDo: [ :i | d at: i put: i > printString]]. > 1180 > 982 > 1008 > > " Using 101 threads " > c := ConcurrentArray new: 1000001. > Time millisecondsToRun: [c keysDo: [ :i | c at: i put: i printString. > ]]. > 1072 > 1120 > 962 > > At this stage, I'm suspicous about the results :-). I tried it on SmalltalkMT on a dual-core system, but failed. I couldn't work out how to use its Semaphores; they don't behave like other Smalltalks and seem to be some MS Windows concoction. In fact, the whole environment feels like C++ with the Windows API. I also failed to get SmalltalkMT to use 100% of both cores on my machine despite forking lots of busy blocks. Huemul Smalltalk crashed when I tried to fork something. So... I remain saddened. It appears that Hydra and GemStone are the nearest we have to a multi-core Smalltalk, and they only do coarse-grained parallelism. This is a sad state of affairs. Gulik. -- http://gulik.pbwiki.com/

March 23, 2009

Re: [Pharo-project] Unicode merge

by Keith Hodges

Michael Rueger wrote: > Hi all, > > in the process of merging the unicode work into the current system I > will upload a bunch of packages to the inbox. The packages will not load > as they are, will need some config maps etc to load it all. > > I will let you know when I figured out a way how to load everything :-) > > Michael > atomic loading, just needs one tiny little bug fix (if you arent using traits) Keith

March 23, 2009