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

[Pharo-project] [update 1.1] #11077

by Marcus Denker

11077 ----- Issue 1406: #ofSize: should be defined in SequenceableCollection class rather than Collection (part2) Issue 1549: System-Settings package has no repository

Dec. 7, 2009

Re: [Pharo-project] SLICE-PreferencesMigrationPart5

by alain.plantec＠free.fr

Hi Henrik, For now, I've only replaced the deprecated method body with the corresponding non-deprecated one. This should make pharo run as requested without any annoying popup. All these methods are localized in the Preferences class. It will be very easy to retrieve them and insert a "self deprecated: 'bla bla bla'". Thanks for your comments Cheers Alain Selon Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > A practice I've seen, and found useful in the past, is replacing the > deprecated method body with the corresponding non-deprecated method call. > This makes proceeding warnings work, and if you turn off warnings, the calls > doesn't stop behaving correctly before you replace them. > > Could this be done, or are the semantics to new settings too different? > > Cheers, > Henry > > On Dec 7, 2009, at 3:41 12PM, Alain Plantec wrote: > > > ------------------ > > SLICE-PreferencesMigrationPart5 is in InBox > > > > * remove projectPreferenceFlagDictionary inst var from Project > > * migrate "docking bars" group > > * migrate "fileout" group > > * remove all remaining deprecated popup (hope it makes OB using ok) > > ------------------ > > > > Alain > > > > > > > > > > _______________________________________________ > > 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] [update 1.1] #11076

by Marcus Denker

11076 ----- Issue 1469: remove ProjectSwikiServer

Dec. 7, 2009

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

by Simon Denier

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 > > 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

Dec. 7, 2009

Re: [Pharo-project] SLICE-PreferencesMigrationPart5

by Henrik Johansen

A practice I've seen, and found useful in the past, is replacing the deprecated method body with the corresponding non-deprecated method call. This makes proceeding warnings work, and if you turn off warnings, the calls doesn't stop behaving correctly before you replace them. Could this be done, or are the semantics to new settings too different? Cheers, Henry On Dec 7, 2009, at 3:41 12PM, Alain Plantec wrote: > ------------------ > SLICE-PreferencesMigrationPart5 is in InBox > > * remove projectPreferenceFlagDictionary inst var from Project > * migrate "docking bars" group > * migrate "fileout" group > * remove all remaining deprecated popup (hope it makes OB using ok) > ------------------ > > Alain > > > > > _______________________________________________ > 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] Window drag and drop strange behavior in 1.1 latest

by StÃ©phane Ducasse

Hi all I remember that I integrated a change that was supposing to fix drag and drop or shadow. I cannot look for it since I'm in the train. Now there is a problem. to see it: move slowly your mouse to a window (from outside the window). When you get an arrow press and the window will be selected but place quite far from where you click. Stef

Dec. 7, 2009

[Pharo-project] MetaSource (was: A centralized repository (Going a step forward Gofer and Metacello))

by Torsten Bergmann

Esteban Lorenzano wrote: >I will start work on a first version of tools needed Have a look at MetaSource, started as a SqueakSource successor based on newer Squeak/Pharo/Seaside with possible Metacello integration in the future. http://www.squeaksource.com/MetaSource Attached is a screenshot. Use one of Damiens latest Pharo dev-images and use the package "MetaSource-ImageBuilder" to load all. (it loads Seaside, FFI, Widgetbox, MetaSource ...) and prepares a full image with the webapp ready to start. It was discussed offlist and progress is very slow but could be a start. Outcome of the offlist discussion was to (maybe) wait until the next Monticello version is out and a stable Metacello is ready... Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Dec. 7, 2009

Re: [Pharo-project] A centralized repository (Going a step forward Gofer and Metacello)

by Miguel Enrique CobÃ¡ Martinez

El lun, 07-12-2009 a las 09:57 -0300, Esteban Lorenzano escribiÃ³: > Ok, that is all the blessing needed :) > I will start work on a first version of tools needed (there are not > mutch at all) and I will upload a meta-package as soon as I have it > working, to test it. > On first stage, we will use a centralized repository on SqueakSource, > and on second stage we can think on a more fashionable way to show the > catalog :) > > About the SqueakSource repository, the name I first proposed > (PharoMetacelloRepository) is not admited for SqueakSource (too large), > so I need variants... what do you think? > I have this in mind: > > -ConfigurationOfPharo > -MetaPharo > -MetacelloRepository MetaHub ;) And if Santa is generous, should be (with proper time) as good as github. > > I like the first one most, because it uses the same convention as the > metacello suggested convention. > > Cheers, > Esteban > > On 2009-12-05 07:27:25 -0300, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> said: > > > Hi lorenzo > > > > YES! we need a catalog in place of Universe package. I think that using mon > > ticello as a way to store metacello config is the way to go. > > We do not need to integrate metacello for now (even if the goal is to succe > > ed to manage > > Pharo with metacello). We could do Gofer loadMetacelloRepository or somethi > > ng like that. > > Then this is important because the testServer could also use this informati > > on. > > > > > > Stef > > > > > > On Dec 4, 2009, at 7:32 PM, Esteban Lorenzano wrote: > > > >> Hi all, > >> Iâm begining to transfer all my projects to metacello (I think this is > > > >> the best package manager present today for pharo), and I have an idea I > > > >> want to share and discuss: > >> > > > >> I think we need a metacello based centered repository. > >> > > > >> The universe doesnât fit with metacello and squeakmap even less. > >> > > > >> So this is my idea (it is based on âibiblioâ for maven/java and apt-g > > et > > > >> for ubuuntu): > >> -we can create a project on squeaksource called > > > >> âPharoMetacelloRepositoryâ, where people can put its public metacello > > > >> configuration packages (for example ConfigurationOfSeaside30, > > > >> ConfigurationOfDeimos, etc.). > >> -we should integrate metacello to pharo core (like Gofer now) > >> -weâll need to create a new class âLoaderâ > >> > > > >> What âLoaderâ does? it loads versions from âmetacello repositories > > â, > > > >> for example: > >> > > > >> Loader default latest: âSeaside30â. âThis will load latest version > > of > > > >> ConfigurationOfSeaside30â > >> > > > >> Loader class>>#default answers a loader pointing to > > > >> âPharoMetacelloRepositoryâ, but you could define others (for your > > > >> private projects). > >> > > > >> How Loader works? > >> 1) validate loading a valid metacello configuration package (weâll need > > > >> to define this later > >> 2) load metacello package > >> 3) do something like âMetacelloConfigurationClass project > > > >> loadLatestVersionâ (for #latest), and the corresponding sends for > > > >> specific versions, etc. > >> > > > >> I think this will solve any package management problem, by using > > > >> something already present (SqueakSource), and of course, we could think > > > >> on better repository places/formats later (but we will be âon the road > > â) > >> > > > >> So, what do you think? > >> > > > >> btw: If the community agree, Iâm offering my self to implement this ide > > a ;) > >> > > > >> Cheers, > >> Esteban > >> > > > >> > > > >> > > > >> _______________________________________________ > >> 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Dec. 7, 2009

Re: [Pharo-project] issue 794

by Miguel Enrique CobÃ¡ Martinez

El lun, 07-12-2009 a las 01:34 -0500, Sean Allen escribiÃ³: > Using 64 bit debian lenny, I'm experiencing issue 794. > > The issue was closed but there doesn't seem to be any definitive how > it was resolved for others. > Can someone give me an idea of what the fix is? > > I see one where upgrading to an unstable version of debian worked but > I'm try to avoid that. I appears to me that the issue was never solved on Debian stable (lenny at the time) only worked for me after upgrading to squeeze. In my case I don't have any 64 bit server with lenny in production, only 32 bit servers, so the network issue doesn't affected me. Hopefully when I use 64 bit servers in production I will use Squeeze (that should be stable by then) and the problem will never hit me. Anyway, as I said, the problem was never correctly addressed or even the main cause discovered. Potentially, when the Pharo 1.0 get released, it will hit several users using Lenny 64 bit. Maybe this should be confirmed and the tickets opened again. Cheers > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Dec. 7, 2009

[Pharo-project] SLICE-PreferencesMigrationPart5

by Alain Plantec

------------------ SLICE-PreferencesMigrationPart5 is in InBox * remove projectPreferenceFlagDictionary inst var from Project * migrate "docking bars" group * migrate "fileout" group * remove all remaining deprecated popup (hope it makes OB using ok) ------------------ Alain

Dec. 7, 2009