Stef, It sounds like I am indeed missing something in saving slices. I saw mention of it, but thought I read that it was not the preferred method and didn't dig further. Are you saying that I can make one big slice with all of my stuff and suddenly all becomes easy??
On the load side, I was having problems over name mis-matches that would not exist given a good packaging system. I could probably get around them now by reifying the names in my load script. Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stéphane Ducasse Sent: Sunday, October 25, 2009 2:59 PM To: [email protected] Subject: Re: [Pharo-project] Thread-safe collections 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
