- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: [squeak-dev] macintosh cocoa 32/64bit & 64/64bit VM goes BETA

by John M McIntosh

Ah, if someone can describe the test case: which I think is take a pharo 1.1 core 11049 then do update? I'll see where it's hung. would that be the pharo1.1-11073-alphadev09.12.1.zip or pharo1.1-11073-alphaweb09.12.1.zip from the 1.1 alpha links on the main pharo web page? On 2009-12-07, at 1:33 PM, Henrik Sperre Johansen wrote: > That's pretty normal, it's happened to me a lot of times, at least. > If you leave if for a while, it'll starts responding again. > No idea why it happens though, I glanced at the code one time it > happened, but no neurons fired :/ > > Cheers, > Henry > > On 07.12.2009 21:49, Michael Roberts wrote: >> Hi, I did a quick test on the 32bit version on 10.5.8. I took a pharo >> 1.1 core 11049 and told it to update from the network. It processed >> all the updates (took some time) and drew the "ok" dialog. However it >> then hung. I am not sure if that is related to the VM or not. in a >> spare moment I will dig deeper. >> >> thanks, >> Mike >> >> On Fri, Dec 4, 2009 at 7:33 PM, John M McIntosh >> <johnmci(a)smalltalkconsulting.com> wrote: >> >>> On 2009-12-04, at 4:30 AM, StÃ©phane Ducasse wrote: >>> >>> >>>>> john needs beta testers....Do not forget >>>>> I know that we are all terribly busy. >>>>> >>>>> >>> >>> Yes , *cough* feedback and response has been zero... >>> Maybe I should push the self-destruct button on the 3.x, 4.x VM series. >>> Where is that red button? Must be here somewhere in the office clutter... >>> >>> -- >>> =========================================================================== >>> John M. McIntosh<johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.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 >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Dec. 7, 2009

Re: [Pharo-project] Scriptloader class>>loadFFI

by Mariano Martinez Peck

This is wrong. It is FFI-Pools not FFI-Pool. But I am sure I tested it. So, it seems Andreas has changed it again. So, it must be: ScriptLoader>>loadFFI self new installer monticello http: 'source.squeakfoundation.org'; project: 'FFI'; install: 'FFI-Pools'; install: 'FFI-Kernel'; install: 'FFI-Tests'; install: 'FFI-Examples'. (Smalltalk at: #ExternalType) initialize. (Smalltalk at: #ExternalStructure) compileAllFields. Smalltalk recreateSpecialObjectsArray. On Wed, Nov 25, 2009 at 12:33 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > yes, it is 1478 issue > > > On Wed, Nov 25, 2009 at 4:35 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> Isn't this issue http://code.google.com/p/pharo/issues/detail?id=1478 ? >> >> Adrian >> >> On Nov 25, 2009, at 01:48 , Schwab,Wilhelm K wrote: >> >> > At least your email system *HAS* a refresh button. Could somebody >> > please tell me what stranglehold MS has on the market??? I thought >> > group wise was bad when they foisted that on us :( >> > >> > >> > >> > >> > -----Original Message----- >> > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto: >> pharo-project-bounces(a)lists.gforge.inria.fr >> > ] On Behalf Of Henrik Sperre Johansen >> > Sent: Tuesday, November 24, 2009 7:21 PM >> > To: pharo-project(a)lists.gforge.inria.fr >> > Subject: Re: [Pharo-project] Scriptloader class>>loadFFI >> > >> > Have.. to... hit... refresh button before replying! ;) >> > >> > On 25.11.2009 01:18, David T. Lewis wrote: >> >> Yes, that is probably it. The separate Pools package was set up to >> >> permit VMMaker to have just the Pools package as a prerequisite, >> >> rather than the entire FFI package. >> >> >> >> Dave >> >> >> >> On Tue, Nov 24, 2009 at 06:56:53PM -0500, Schwab,Wilhelm K wrote: >> >> >> >>> I think I found it: Andreas added a Pools sub-package, so #loadFFI >> >>> needs to load it before the kernel. Right?? >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >> >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> >>> Schwab,Wilhelm K >> >>> Sent: Tuesday, November 24, 2009 6:52 PM >> >>> To: Pharo-project(a)lists.gforge.inria.fr >> >>> Subject: [Pharo-project] Scriptloader class>>loadFFI >> >>> >> >>> Does >> >>> >> >>> Scriptloader loadFFI >> >>> >> >>> work in RC1? It's barking at me about FFIConstants. >> >>> >> >>> Bill >> >>> >> >>> >> >> _______________________________________________ >> >> 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 >> > >

Dec. 7, 2009

[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