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

[Pharo-project] FFI not loading on squeak-dev 496

by Mariano Martinez Peck

I guess this problem is related to Metacello. Probably not with Monticello in itself but in our own configuration. Sorry Dale for send you so many questions, emails, requests of new features, etc. But be aware that this is due to the fact we are migrating our projects to Metacello :) This problem related to Esteban, seems to be something with Metacello. We are trying to evaluate this: (ConfigurationOfSqueakDBX project version: '1.1') load You can find that configuration class in http://www.squeaksource.com/SqueakDBX The problem is that all the FFI classes that are load BEFORE SqueakDBX, have NO METHODS. Ok, then the parser tries to parse the 'cdelc:' of FFI and the DNU is to callingConventionFor: which is one of the class side methods of the class ExternalStructure. But when I debug that, I noticed that all classes of the FFI packages don't have any method :( Of course, this includes ExternalFunction>>callingConventionFor: This is weird. I don't know how to proceed. Let me know if I can help you with something else. Maybe there is something wrong in my configuration. Cheers, Mariano ---------- Forwarded message ---------- From: Esteban Lorenzano <estebanlm(a)gmail.com> Date: Mon, Dec 7, 2009 at 10:25 PM Subject: [Pharo-project] FFI not loading on squeak-dev 496 To: pharo-project(a)lists.gforge.inria.fr Hi, I'm trying to load FFI on a squeak-dev image (496 09.11.04) and I'm having a DNU here: externalFunctionDeclaration "Parse the function declaration for a call to an external library." | descriptorClass callType retType externalName args argType module fn | descriptorClass := Smalltalk at: #ExternalFunction ifAbsent:[nil]. descriptorClass == nil ifTrue:[^false]. callType := descriptorClass callingConventionFor: here. ------------------------------------------------------------ ^HERE Does anybody knows what happens? Cheers, Esteban _______________________________________________ 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: FFI not loading on squeak-dev 496

by Mariano Martinez Peck

I guess this problem is related to Metacello. Probably not with Monticello in itself but in our own configuration. Sorry Dale for send you so many questions, emails, requests of new features, etc. But be aware that this is due to the fact we are migrating our projects to Metacello :) This problem related to Esteban, seems to be something with Metacello. We are trying to evaluate this: (ConfigurationOfSqueakDBX project version: '1.1') load You can find that configuration class in http://www.squeaksource.com/SqueakDBX The problem is that all the FFI classes that are load BEFORE SqueakDBX, have NO METHODS. Ok, then the parser tries to parse the 'cdelc:' of FFI and the DNU is to callingConventionFor: which is one of the class side methods of the class ExternalStructure. But when I debug that, I noticed that all classes of the FFI packages don't have any method :( Of course, this includes ExternalFunction>>callingConventionFor: This is weird. I don't know how to proceed. Let me know if I can help you with something else. Maybe there is something wrong in my configuration. Cheers, Mariano ---------- Forwarded message ---------- From: Esteban Lorenzano <estebanlm(a)gmail.com> Date: Mon, Dec 7, 2009 at 10:25 PM Subject: [Pharo-project] FFI not loading on squeak-dev 496 To: pharo-project(a)lists.gforge.inria.fr Hi, I'm trying to load FFI on a squeak-dev image (496 09.11.04) and I'm having a DNU here: externalFunctionDeclaration "Parse the function declaration for a call to an external library." | descriptorClass callType retType externalName args argType module fn | descriptorClass := Smalltalk at: #ExternalFunction ifAbsent:[nil]. descriptorClass == nil ifTrue:[^false]. callType := descriptorClass callingConventionFor: here. ------------------------------------------------------------ ^HERE Does anybody knows what happens? Cheers, Esteban _______________________________________________ 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

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

by StÃ©phane Ducasse

You lost me gary :) On Dec 7, 2009, at 6:56 PM, Gary Chambers wrote: > "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 > > > _______________________________________________ > 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

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

by StÃ©phane Ducasse

would be nice. On Dec 7, 2009, at 7:11 PM, Lukas Renggli wrote: > 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 > > _______________________________________________ > 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

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

by StÃ©phane Ducasse

publish the solution to smallDictionary like that we integrate it. On Dec 7, 2009, at 4:47 PM, Simon Denier wrote: > > 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 > > > > > _______________________________________________ > 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

Re: [Pharo-project] SLICE-PreferencesMigrationPart5

by StÃ©phane Ducasse

Yes thanks. Because we did what henrik suggested in the past. Stef On Dec 7, 2009, at 5:17 PM, alain.plantec(a)free.fr wrote: > 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 >>> >> >> > > > > _______________________________________________ > 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

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

by StÃ©phane Ducasse

I want a catalog for Pharo because I want to know what I can load in Pharo. Especially because I will be a time where we will have too many differences with squeak. Stef On Dec 7, 2009, at 2:28 PM, Mariano Martinez Peck wrote: > > > On Mon, Dec 7, 2009 at 1:57 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 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 > > I like the first one most, because it uses the same convention as the > metacello suggested convention. > > > I don't know if I like to put "Pharo" in the name. The idea of Metacello is also to be able to easily port form one dialect to other. So, suppose I want to create the ConfigurationOfFFI, maybe I will have something for #squeak and something for #pharo or even for gemstone. > > So, I rather a name, not hardcoded to pharo, so that the configurations there should have the conditions. > > I like MetacelloRepository. > > Best, > > Mariano > > 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 > > _______________________________________________ > 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

Re: [Pharo-project] Issue 1551: possible to create 2 ByteSymbols with the same sequence of characters( WAS: getting rid of Symbol >> new: ?)

by Sheridan Mahoney

The address for my Google account is: smagooey(a)yahoo.com I just sent Stef an email attachment with the license agreement, and will be putting a hard copy in the mail. Cheers, Sheri Adrian Lienhard wrote: > > Hi Sheri, > > Thanks for the contribution! > > Please send me the mail address you use for the Google account. I'll > add you to the list of developers. > > BTW, have you signed the license agreement? > > Cheers, > Adrian > > > On Dec 7, 2009, at 21:14 , Sheridan Mahoney wrote: > >> >> and, forgot to mention, I did an image check, and did not find any >> uses of >> Symbol >> new: once we changed Symbol >> intern: . >> >> Also, does something need to be enabled in order to be able to >> modify the >> description fields in the issue tracker? Not having much luck in my >> searches... > >> Thanks, >> Sheri >> >> >> >> Sheridan Mahoney wrote: >>> >>> This is just to let the people of the list know I have reported the >>> above >>> bug (Issue 1551) and >>> submitted a fix and tests to PharoInbox. It is called: >>> SLICE-disallow-Symbol-new-SheridanMahoney.2 >>> >>> I didn't see a way to change the status to "Fixed", so it is just >>> listed >>> as "New". >>> >>> Cheers, >>> Sheri >>> >>> >>> >>> Adrian Lienhard wrote: >>>> >>>> Hi Sheri, >>>> >>>> Sounds ok to make new: raise an exception if you adjust the tests >>>> (and >>>> any code that exists in the image using new: (but I assume there is >>>> none)). >>>> >>>> >>> >>> >> >> -- >> View this message in context: >> http://n2.nabble.com/Re-getting-rid-of-Symbol-new-tp4109230p4128207.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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 > > -- View this message in context: http://n2.nabble.com/Re-getting-rid-of-Symbol-new-tp4109230p4128749.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 7, 2009

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

by Nicolas Cellier

2009/12/7 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/12/7 Alain Plantec <alain.plantec(a)free.fr>: >> >> >> >>>> Nicolas, do you try with the new setting browser or with the old >>>> preference browser? >>>> Alain >>>> >>> >>> Hello Alain, >>> The old one I guess. Where is the menu to open a new one ? >>> >> >> <worldmenu>/System/Settings... >> > > Thanks, case of blindness, I have selected <worldmenu>/System/Preferences... > OK, you don't want to bother with old browser, so your plan is to let > it rot until the new one is fully operational, isn't it? > > Nicolas > Oops, I did not finish my message... I suggest the menu being renamed 'System/Preferences... (deprecated)' in between Nicolas >> >>> Nicolas >>> >>> >>>>> >>>>> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >

Dec. 7, 2009

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

by Nicolas Cellier

2009/12/7 Alain Plantec <alain.plantec(a)free.fr>: > > > >>> Nicolas, do you try with the new setting browser or with the old >>> preference browser? >>> Alain >>> >> >> Hello Alain, >> The old one I guess. Where is the menu to open a new one ? >> > > <worldmenu>/System/Settings... > Thanks, case of blindness, I have selected <worldmenu>/System/Preferences... OK, you don't want to bother with old browser, so your plan is to let it rot until the new one is fully operational, isn't it? Nicolas > >> Nicolas >> >> >>>> >>>> 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 >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 >

Dec. 7, 2009