December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Cannot update behind a proxy

by Nicolas Cellier

OK, I manually set a class var in the debugger, but find awkward that the Preferences Browser would not do that for me... 2009/12/7 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > The update process stops at 11070... > It cannot get access to > http://www.squeaksource.com/Pharo/ScriptLoader11-MarcusDenker.81.mcz > > 'Could not resolve the server named: www.squeaksource.com' > > I can perfectly access this resource via firefox though... > > Anything related to Preferences refactoring ? > > Nicolas >

Dec. 7, 2009

[Pharo-project] Cannot update behind a proxy

by Nicolas Cellier

The update process stops at 11070... It cannot get access to http://www.squeaksource.com/Pharo/ScriptLoader11-MarcusDenker.81.mcz 'Could not resolve the server named: www.squeaksource.com' I can perfectly access this resource via firefox though... Anything related to Preferences refactoring ? Nicolas

Dec. 7, 2009

Re: [Pharo-project] [update 1.1] #11076

by Lukas Renggli

Yeah, finally :-) 2009/12/7 Marcus Denker <denker(a)acm.org>: > 11076 > ----- > > Issue 1469: Â Â remove ProjectSwikiServer > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 7, 2009

Re: [Pharo-project] Dealing with Preferences in external packages?

by Lukas Renggli

That's a serious problem, but given that OmniBrowser is pretty modular I guess that the preferences can be factored out into an OBPharoPlatform. Lukas 2009/12/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Now that setting is starting to get integrated (great) we will also face the problem > of branching. > Â Â Â Â For example, how do we manage that OB uses Preferences.... and that we don't. > Â Â Â Â Any idea or process is welcome. > > Of course we can have a package full of override but this is the ultimate solution > Â Â Â Â before complete fork. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 7, 2009

Re: [Pharo-project] SmallDictionary>>removeAll or >>empty?

by Nicolas Cellier

2009/12/7 Simon Denier <Simon.Denier(a)inria.fr>: > > On 5 dÃ©c. 2009, at 17:49, Lukas Renggli wrote: > >> SmallDictionary comes from the refactoring engine. It is a highly >> optimized dictionary originally intended for parse-tree matching. The >> method #empty does not make sense outside that context. >> >> The method #removeAll is implemented in Collection. I don't think that >> this implementation can ever work in any concrete collection >> implementation, because it modifies the collection while iterating >> over it (lint would know that). Most classes override it with >> something sensible though. > > Back from my trip, my neurons are still not 100% functional. > > What would be a sensible implementation then? > > Most straightforward I can think of: > > SmallDictionary>>removeAll > Â self initliaze > or size := 0. keys atAllPut: nil. values atAllPut: nil. >> >> Lukas >> >> 2009/12/5 Simon Denier <Simon.Denier(a)inria.fr>: >>> Stupid question: how do I remove all entities from a SmallDictionary >>> >>> Let's take: >>> d := SmallDictionary new. >>> d add: $d -> 4. >>> d add: $e -> 5. >>> d >>> >>> If I do >>> d empty >>> >>> then d size = 0 and d do: behaves as if there is nothing >>> BUT someone can still perform >>> d at: $d -> 5 >>> >>> If I do >>> d removeAll >>> >>> I get a MessageNotUnderstood: SmallInteger>>key >>> because #removeAll inherited from Collection expects a different >>> structure >>> >>> -- >>> Â Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Â Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 7, 2009

[Pharo-project] Fwd: Dealing with Preferences in external packages?

by StÃ©phane Ducasse

> > > Now that setting is starting to get integrated (great) we will also face the problem > of branching. > For example, how do we manage that OB uses Preferences.... and that we don't. > Any idea or process is welcome. > > Of course we can have a package full of override but this is the ultimate solution > before complete fork. > > Stef > >

Dec. 7, 2009

Re: [Pharo-project] Dealing with Preferences in external packages?

by Gary Chambers

"Shared" settings will introduce another kind of package dependency... Perhaps there is some benefit of all settings being local to a package but cross-linked in some way such that the compatible preferences all change value at the same time in the settings browsers? There will always be some kind of compromise, one way or the other, but it might work ;-) Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, December 07, 2009 1:50 PM Subject: [Pharo-project] Dealing with Preferences in external packages? > Now that setting is starting to get integrated (great) we will also face > the problem > of branching. > For example, how do we manage that OB uses Preferences.... and that we > don't. > Any idea or process is welcome. > > Of course we can have a package full of override but this is the ultimate > solution > before complete fork. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 7, 2009

[Pharo-project] "" bug

by StÃ©phane Ducasse

in latest 1.1 I can only get "" by pressing " on an empty line. If I put the caret in front of the character and press " nothing happen. Is it me? Stef

Dec. 7, 2009

[Pharo-project] [update 1.1] #11078

by Marcus Denker

11078 ----- Issue 1548: Preferences migration part5

Dec. 7, 2009

Re: [Pharo-project] Help with Metacello configurations for external packages!!!

by Dale Henrichs

Dec. 7, 2009