On Oct 25, 2009, at 10:15 PM, Schwab,Wilhelm K wrote: > 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??
if you have a package and some dependents when you will save a comments will be propagated to all the dependents no need to repeat that. > 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. I suggest that you start also to look at metacello because dale is managing glass with it and doru moose/mondrian.... in the future we want to manage the release with it. Stef > > Bill > > > > -----Original Message----- > From: [email protected] [mailto:pharo- > [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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
