On Oct 23, 2009, at 3:31 PM, Schwab,Wilhelm K wrote: > Stef, > > With no disrespect to Sig's opinions, I'm glad to hear that. I very > quickly cobbled together a class called SharedLookupTable, and have > no problems making it (suitably debugged) available. > > Now it's time for me to kick your ass a little, to coin a phrase :)
no problem > Monticello is pretty good at what it does, but I sense the things it > does not do interfering with good decision making. The class ended > up in my Dolphin compatibility package, in part because it belongs > there, though it really should be separate so I can easily release > it and people would be able to get it w/o having to accept other > ideas they might not want. But it went in the compatiblity package > so I would not have to mess around with another package. Saving > them is a pain; loading them into a new image is a pain. why? > Saving: the interface works well once understood, and the features > it offers should never go away. However, either by script or by > multiple selection, it would be nice to provide a comment to be > applied to everything to be saved "now" vs. having to be prompted > for it, then have the list scroll, then have to click away another > window. Do that 30 times and it starts to get old. this is strange because I thought that we fixed that pop up plague when saving slices Then you get all the comments you already typed in one of the button of the poped up window. Did you see it? > Loading: I spent a chunk of yesterday trying to build an RC1 image. > Doing so revealed that my script-loader for script-loader does not > validate package names. I had one build attempt come to a halt over > case-sensitivity; I do not mind that. What I mind is that the > particular case mix in question was more or less forced on me by a > typo of mine. If MC were better about offering choices when they > apply, I might not have typed it that way. > > I realize that Gofer is coming, and it might fix a lot of this. yes and also metacello which is coming along well > The ideas above are probably not new, but I list them just in case. > > Bill > > > > -----Original Message----- > From: [email protected] [mailto:pharo- > [email protected]] On Behalf Of Stéphane Ducasse > Sent: Friday, October 23, 2009 2:46 AM > To: [email protected] > Subject: Re: [Pharo-project] Thread-safe collections > > I would really like to see some packages getting implementing around > the idea of a couple of robust and well tested thread safe > collections. > > Stef > > On Oct 23, 2009, at 2:16 AM, Schwab,Wilhelm K wrote: > >> Sig, >> >> One can always construct examples in which protecting the entire >> loop is the better option. That's not the scenario of interest. >> Just as shared queues are useful, shared sets and dictionaries have >> value for sporadic access scenarios. Doing it your way, everyone >> writes their own incompletely protected (read buggy/dangerous) ad- >> hoc >> implementations of these common collections. >> >> I favor having solid implementations that are complete and as correct >> as we can get them, leaving people to optimize as you suggest when it >> makes sense to do so. >> >> Bill >> >> >> -----Original Message----- >> From: [email protected] [mailto:pharo- >> [email protected]] On Behalf Of Igor Stasenko >> Sent: Thursday, October 22, 2009 5:23 PM >> To: [email protected] >> Subject: Re: [Pharo-project] Thread-safe collections >> >> 2009/10/23 Schwab,Wilhelm K <[email protected]>: >>> Hello all, >>> >>> I just looked around for thread-safe collections, and found nothing >>> that looks like a shared dictionary. The squeak-dev archives >>> contain >>> the obligatory newbie posts (wanting all collections to be thread >>> safe) and the expected replies, some of which are overly dismissive >>> of the idea. Something that protects things like >>> #at:ifAbsentPut: and friends is _really_ useful. Am I missing an >>> existing implementation? >>> >> >> Imo, there's only one shared collection which is useful - shared >> queue. :) If you need more kinds of thread-safe collections, it >> probably indicating that the concurrent code (or model) which you >> designed is in pretty bad shape. >> >> Just compare two following snippets: >> >> 1 to: 100 do: [:i | collection threadSafeAt: i put: something]. >> >> and: >> >> semaphore critical: [ 1 to: 100 do: [:i | collection at: i put: >> something] ]. >> >> What you think, which one is better? >> >> >>> Bill >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
