- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Preferences refactoring pushed

by Alain Plantec

Igor Stasenko wrote: > the 'message pane missin' spam in transcript is really annoying :) > Issue 1378 <http://code.google.com/p/pharo/issues/detail?id=1378>: annoying MC Transcript log "Warning: pane summary not found" Fixed Cheers Alain

Oct. 27, 2009

Re: [Pharo-project] update server down?

by Tudor Girba

The GForge maintenance was announced in a forward by Stef on Oct 23 :). Doru On 27 Oct 2009, at 10:07, Michael Roberts wrote: > Probably. Where are they announced? Can they be posted here? > > Cheers mike > > On Tuesday, October 27, 2009, Tudor Girba <tudor.girba(a)gmail.com> > wrote: >> Wasn't this problem due to the announced maintenance of GForge for >> Monday 26th October 2009, from 18:30 to 22:00? >> >> Doru >> >> On 27 Oct 2009, at 08:57, Michael Roberts wrote: >> >>> yes it's working now. thanks >>> Mike >>> >>> On Tue, Oct 27, 2009 at 7:51 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> apparently the forge was down yesterday evening. >>>> Not sure that this is available now. >>>> >>>> On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: >>>> >>>>> i'm getting timeouts from the update server. can someone confirm? >>>>> >>>>> thanks, >>>>> Mike >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Problem solving should be concentrated on describing >> the problem in a way that is relevant for the solution." >> >> >> >> >> _______________________________________________ >> 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 -- www.tudorgirba.com "We are all great at making mistakes."

Oct. 27, 2009

Re: [Pharo-project] update server down?

by Michael Roberts

Probably. Where are they announced? Can they be posted here? Cheers mike On Tuesday, October 27, 2009, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Wasn't this problem due to the announced maintenance of GForge for > Monday 26th October 2009, from 18:30 to 22:00? > > Doru > > On 27 Oct 2009, at 08:57, Michael Roberts wrote: > >> yes it's working now. thanks >> Mike >> >> On Tue, Oct 27, 2009 at 7:51 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> apparently the forge was down yesterday evening. >>> Not sure that this is available now. >>> >>> On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: >>> >>>> i'm getting timeouts from the update server. can someone confirm? >>>> >>>> thanks, >>>> Mike >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Problem solving should be concentrated on describing > the problem in a way that is relevant for the solution." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 27, 2009

[Pharo-project] update server down?

by Torsten Bergmann

>Wasn't this problem due to the announced maintenance of GForge for >Monday 26th October 2009, from 18:30 to 22:00? or related to a squeaksource server reset: http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-October/140479.… -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Oct. 27, 2009

Re: [Pharo-project] update server down?

by Tudor Girba

Wasn't this problem due to the announced maintenance of GForge for Monday 26th October 2009, from 18:30 to 22:00? Doru On 27 Oct 2009, at 08:57, Michael Roberts wrote: > yes it's working now. thanks > Mike > > On Tue, Oct 27, 2009 at 7:51 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> apparently the forge was down yesterday evening. >> Not sure that this is available now. >> >> On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: >> >>> i'm getting timeouts from the update server. can someone confirm? >>> >>> thanks, >>> Mike >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution."

Oct. 27, 2009

Re: [Pharo-project] ClassOrganizer oddities

by Nicolas Cellier

2009/10/27 Igor Stasenko <siguctua(a)gmail.com>: > 2009/10/26 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> so what is the fix? >> I would really like to get announcement instead of event >> systemNotification but I'm sure that this >> can be a bit tricky. >> > > Yes, tricky :) > Here what i have in mind: > > Any change to system should be captured _before_ it applied. > This allows us to introduce a policy which can validate the change and decide > whether it allowed to be made or not. > > I made the SystemChangeEvent class, which having following state: > Â - changeKind - a symbol, which identifies the change Hi Igor, IMHO, nowadays, the trend would be to create subclasses rather than internal symbols... Shouldn't there be a symmetry with the hierarchy of changes in DeltaStream (for example) ? Nicolas > Â - parameters - a dictionary , which holding different parameters, > important for change > Â - subject - the object which is going to be changed (or taking a main > role in change) > Â - action - a block closure which , if evaluated, will apply the > change to system > > For example, here the method which creates & populates the system change event: > > classify: element under: heading suppressIfDefault: aBoolean > > Â Â Â Â (self subject newSystemEvent: #changeSelectorCategory) > Â Â Â Â Â Â Â Â subject: element; > Â Â Â Â Â Â Â Â param: #behavior->self subject; > Â Â Â Â Â Â Â Â param: #category->heading asSymbol; > Â Â Â Â Â Â Â Â param: #suppressIfDefault->aBoolean; > Â Â Â Â Â Â Â Â action: [ super classify: element under: heading suppressIfDefault: > aBoolean ]; > Â Â Â Â Â Â Â Â signal. > --------- > > The event handling procedure is following: > > - first of all, an event passed to a system arbiter object > - a system arbiter checking with the policy > - if everything ok, change is applied by evaluating action. > - and finally, change is announced to any interesting parties > > I want to make each package to hold own policy (a set of flags > identified by name, to ease fileout). > Then, any event could be validated by policy by issuing: > Â package policy validate: change > > For example, lets see , what validations we could introduce for method > recategorization event. > > Â - lets take most interesting case, when we want to recategorize the > method in ClassA, which belongs to PackageA, > Â and putting it into extension category, like *PackageB > > Â - check, if we allow any changes to ClassA (policy of PackageA) > Â - check if PackageA allows method extensions (policy of PackageA) > Â - check if PackageB allows extending the classes of another packages > (policy of PackageB) > Â - check if extension overrides existing method > Â - and of course, we should check that given extension does not > creates a circular dependency between the packages. > > There, of course, some problems which arising. > - changes nesting. > Â Some changes is complex ones, and even a simple method > recategorization could lead to another event - creating a new > Â category in class. Â Optimally, it would be cool to have only most > basic events, which can't be nested. And any action which may lead to > multiple changes, should be split on a number of basic ones. > A SystemChangeNotifier solving this by allowing doing things silently: > Â SystemChangeNotifier uniqueInstance doSilently: [ ... ]. > so, any changes within the block , if any, won't be announced. > > - atomicity support. To support the bulk model updating, i can imagine > the framework, which capturing any changes without applying them, by > building/collecting all changes in parallel, and then applying them by > a single mass-become. This is what SystemEditor does. > > - metaprogramming. There should be a means to leave a room for > metaprogramming. We wouldn't want to signal a system change for > anonymous classes, and many other things, which can be tricky here. > > P.S. as you can see , the plans is quite bold, and will require > numerous refactorings :) So, the more people is interested in that, > the better. > >> Stef >> > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 27, 2009

Re: [Pharo-project] update server down?

by Michael Roberts

yes it's working now. thanks Mike On Tue, Oct 27, 2009 at 7:51 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > apparently the forge was down yesterday evening. > Not sure that this is available now. > > On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: > >> i'm getting timeouts from the update server. can someone confirm? >> >> thanks, >> Mike >> >> _______________________________________________ >> 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 >

Oct. 27, 2009

Re: [Pharo-project] Thread-safe collections

by StÃ©phane Ducasse

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(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Sunday, October 25, 2009 2:59 PM > To: Pharo-project(a)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(a)lists.gforge.inria.fr [mailto:pharo- >> project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse >> Sent: Friday, October 23, 2009 2:46 AM >> To: Pharo-project(a)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(a)lists.gforge.inria.fr [mailto:pharo- >>> project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko >>> Sent: Thursday, October 22, 2009 5:23 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Thread-safe collections >>> >>> 2009/10/23 Schwab,Wilhelm K <bschwab(a)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(a)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(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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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

Oct. 27, 2009

Re: [Pharo-project] (a = b) => (a hash = b hash)

by StÃ©phane Ducasse

> > Yes. Filenames and URLs are particularly problematic. Fortunately > they > tend to be O(100) in size, as opposed to O(1000) in size. Thus, the > less demanding path of just hashing the characters is efficient enough > for the cases I've seen so far. > >> IMO, we should not let Array hash ~= Interval hash coexist with >> Array = Interval >> Because it's like putting some traps on programmers path. >> > > Yes, I agree. I'd vote on breaking #=, with the caveat that chances > are > some code will be broken. Does Pharo have a release strategy that > allows more fundamental changes to go in, as opposed to > maintenance/improvement fixes? yes we talk then we summarize and describe a bug entry and Now I'm thinking that it would be good to have a page with important changes per version I would put there the discussions about the float changes we did in 1.0. Stef

Oct. 27, 2009

Re: [Pharo-project] update server down?

by StÃ©phane Ducasse

apparently the forge was down yesterday evening. Not sure that this is available now. On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: > i'm getting timeouts from the update server. can someone confirm? > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 27, 2009