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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo- project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, October 25, 2009 2:59 PM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo- project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Friday, October 23, 2009 2:46 AM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo- project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, October 22, 2009 5:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections
2009/10/23 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project