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

Re: [Pharo-project] Mike we need some fixes for mime.... :)

by Lukas Renggli

> Comment 1 by mike.rueger, Feb 14 (2 days ago) My guess is that > MIMEDocument>>initialize is changed/overriden by Pier? No. Magritte and Pier do not touch MimeDocument. Seaside adds two extension methods, but they do not conflict. It is KomHttpServer that adds #initialize as a class extension method. Pier does not load into newer Pharo versions for another reason: It has an uppercase class instance variable that I cannot rename without f***ing up all existing Pier installations (see related discussion). Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 17, 2009

Re: [Pharo-project] Distributed versioning ... MonticelloHub?

by StÃ©phane Ducasse

I do not understand how Issue 456: 7272: BlockContext equality test is missing is related to kernel extensions? http://code.google.com/p/pharo/issues/detail?id=204&q=kernel%20extensions&c… Hi list, we (with Stef) are browsing Kernel-Extensions, here are some notes for discussion, as we think there is stuff that should be merged in Pharo. Null and Split-Join could be packaged on their own since they are well-defined features. Most of the cleanup methods make sense, but what's the difference between cleanUp and freeSomeSpace ? AppRegistry class >> removeObsolete "AppRegistry removeObsoleteClasses" self registeredClasses copy do:[:cls| (cls class isObsolete or:[cls isBehavior and:[cls isObsolete]]) ifTrue:[self unregister: cls]]. self subclasses do:[:cls| cls removeObsolete]. Behavior class >> flushObsoleteSubclasses "Behavior flushObsoleteSubclasses" ObsoleteSubclasses finalizeValues. Behavior >> sourceMatchesBytecodeAt: Class class >> freeSomeSpace "Fix some problems with classes. Use Smalltalk allClassesDo: since it does not use the subclass list, which we may be modifying during this iteration" Smalltalk allClassesDo: [:ea | ea fixObsoleteSuperclass. ea removeDuplicateSubclassEntries] Collection >> contains: should probably be standardized as part of the STEPS project Collection >> reject:thenDo: and select:thenDo: should be included and similar enumerations reimplemented in this way too SystemDictionary >> forgetClass: aClass logged: aBool badly named but interesting "Delete the class, aClass, from the system. Note that this doesn't do everything required to dispose of a class - to do that use Class>>removeFromSystem." aBool ifTrue: [SystemChangeNotifier uniqueInstance classRemoved: aClass fromCategory: aClass category]. SystemOrganization removeElement: aClass name. self removeFromStartUpList: aClass. self removeFromShutDownList: aClass. self removeKey: aClass name ifAbsent: []. DataStream classRemoved: aClass. self flushClassNameCache SystemDictionary >> globals needs to pay attention that compiled methods share the associations Number >> to: stop do: aBlock displayingProgress: aString would be probably nicer with the block argument last === To discuss: Collection >> removeAll: comment should explain in which cases it is useful "the slow way" ^ self removeAllSuchThat: [ :each | true ] SequenceableCollection >> <= smells funnyâ¦ what is it useful for ? SequenceableCollection >> replacing:with: replaces in place, not obvious from the name the stream methods like putOn: â¦ convenience ? are they coherent ? String >> withoutTrailing: probably makes sense but then this is mostly useful for line breaksâ¦ why not a #trimLinebreak Set >> likeOrAdd: ok but then that should be available for any collection (and renamed addIfAbsent:) "Include newObject as one of the receiver's elements, but only if not already present. Answer the oldObject." === Useless: ProtoObject >> iconOrThumbnailOfSize: Object >> askFor: and askFor:ifDefault: that's a workaround Object >> deprecated is already here Object >> log should be packaged in a logging package since it's a convenience method SequenceableCollection >> copyReplacing:with: just to type one space less ?

Feb. 17, 2009

Re: [Pharo-project] Distributed versioning ... MonticelloHub?

by StÃ©phane Ducasse

The point is that the cleanUp and freeSomeSpace extensions are interesting. stef On Feb 17, 2009, at 8:26 AM, Damien Cassou wrote: > On Mon, Feb 16, 2009 at 8:22 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> sorry you lost me on this one. > > Do not take care of KernelExtensions. It's not needed anymore to load > Sake/Packages and LPF into Pharo. > > Start by integrating issue #456 on PharoInbox. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 17, 2009

Re: [Pharo-project] Mike we need some fixes for mime.... :)

by StÃ©phane Ducasse

On Feb 16, 2009, at 5:15 PM, Michael Rueger wrote: > StÃ©phane Ducasse wrote: > >>> Issue 520: MIMEDocument class(Object)>>doesNotUnderstand: >>> #resetMIMEdatabase >>> http://code.google.com/p/pharo/issues/detail?id=520 > > > Hmm, there isn't a MIMEDocument>>initialize anymore, so the bug is > introduced by someone reintroducing/overriding the class initialize > method. you wrote: Comment 1 by mike.rueger, Feb 14 (2 days ago) My guess is that MIMEDocument>>initialize is changed/overriden by Pier? Now I checked and in previous version this method was define in MIMEDocument MIMEdatabase _ self extendedMIMEdatabase so did you remove it on purpose during the refactoring? Stef

Feb. 17, 2009

Re: [Pharo-project] Distributed versioning ... MonticelloHub?

by Damien Cassou

On Mon, Feb 16, 2009 at 8:22 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > sorry you lost me on this one. Do not take care of KernelExtensions. It's not needed anymore to load Sake/Packages and LPF into Pharo. Start by integrating issue #456 on PharoInbox. -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 17, 2009

Re: [Pharo-project] Preferences refactoring

by StÃ©phane Ducasse

I did not follow in detail but my gut feeling is the following one: - keep the preference browser as a layer on top of the rest - change the preferences default and move them into the tools (pragmas there). - change the flow to not query the preference class during the execution of the tools. I will try to get back my brain to read the thread. stef On Feb 16, 2009, at 6:32 PM, Gary Chambers wrote: > So, for new browser it needs to be decided what information to show > as this > will affect the pragma. > For instance, do we still want categories, "project > specific" (probably not) > etc. > > I expect we will want a Preference class either way to model each > preference > in the browser. > Making a new browser is quite an undertaking given the different > types of > preference (boolean, text, one-of-many, colour, font etc.). > > Regards, Gary. > > ----- Original Message ----- > From: "Alain Plantec" <beranger22(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, February 16, 2009 5:08 PM > Subject: Re: [Pharo-project] Preferences refactoring > > > Gary Chambers a Ã©crit : >> I'll have a think. Some theme settings can currently be set >> (manually) >> on a per theme basis. >> Would be nice to handle that, though the pragma route suggests that a >> static facade would be needed to delegate to the defaults for the >> current theme... >> >> I'd see something like >> >> X class>>myPreference >> <preference: 'Readable name' type: #Boolean set: #myPreference: >> default: #defaultMyPreference description: 'Helpful text'> >> ^ myPreference ifNil: [myPreference := self defaultMyPreference] >> >> X class>>defaultMyPreference >> ^false >> >> X class>>myPreference: aTValue >> myPreference := aTValue. >> "do any stuff to notify/apply change..." >> >> That would be enough got get the value (selector of pragma) and all >> the rest. The default value needs to be by method since pragma >> arguents only support literals (some preferences may be complex >> objects). The type can be used by the preference browser to determine >> how to handle the values... I suggest having the class name of the >> expected value here to help with that > ok, this is what I suggested also (all informations are explicitly > declared with pragma) > >> (the class may have extensions allowing it to work with the >> preference >> browser). > i'm not sure it is a good idea to keep the current preference > browser ... >> >> Of course, another approach is to just decentralize the >> preferences... >> >> X class>>xyzColorPreference >> <preference> >> ^Preference new >> name: #xyzColor >> defaultValue: Color red >> helpString: 'Specifies the xyz color of abc' >> localToProject: false >> categoryList: #(#'window colors') >> changeInformee: self >> changeSelector: #xyzColor: >> viewRegistry: (PreferenceViewRegistry registryOf: >> #windowColorPreferences) >> >> And tweak Preference>>notifyInformeeOfChange to handle the argument >> for the changeSelector (passing the new preference value). * > I prefer previous solution. Maybe we need a Preference class but I'm > not > sure. >> >> That should work ok with the existing preference browser with a few >> tweaks (the preference browser should have a its preferences var set >> to a new instance of a class that provides the relevant protocol that >> is used on the Preference class side but with the preferences >> discovered via the code below). >> >> (Object withAllSubclasses >> inject: OrderedCollection new >> into: [:pragmas :class | pragmas, (Pragma allNamed: #preference in: >> class)]) >> collect: [:pragma | pragma methodClass theNonMetaClass perform: >> pragma >> selector] > yes, cool code :) > > > alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Regards, Gary > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 16, 2009

Re: [Pharo-project] Preferences refactoring

by Matthew Fulmer

On Mon, Feb 16, 2009 at 02:19:55PM -0500, Matthew Fulmer wrote: > On Mon, Feb 16, 2009 at 05:32:33PM -0000, Gary Chambers wrote: > > So, for new browser it needs to be decided what information to show as this > > will affect the pragma. > > For instance, do we still want categories, "project specific" (probably not) > > etc. > > > > I expect we will want a Preference class either way to model each preference > > in the browser. > > Making a new browser is quite an undertaking given the different types of > > preference (boolean, text, one-of-many, colour, font etc.). > > I think Magritte is the proper solution. It already handles UI > metadata like this. Something like this: prefTheme <preference category: 'User Interface'> ^ MASingleOptionDescription new options: #( 'Vistary' 'Watery' 'Squeak' 'Soft Squeak' ); reference: MAStringDescription new; autoAccessor: 'theme'; label: 'Theme'; priority: 40; beSorted; yourself > Regarding preferences being optional, I think just a few tweaks > to the MC loader would work: If the Preferences Browser is not > loaded, MC will not compile the methods that return the Magritte > metadata. If this is done properly, as in MC1.5, these methods > will hang out uncompiled in the orphanage until you load the > preferences package, at which point they will be loaded into the > image. This is completely wrong. In the above example, if Magritte was not loaded, MASingleOptionDescription will bind to Undeclared. Then, if Magritte is ever loaded, it will notice the reference in Undeclared, and recompile this method to act correctly. > Out-of-order package loading is nice. Out-of-order loading, in the form of global references, has been supported since smalltalk-76 by the Undeclared object. The MC1.5 orphanage supports another kind of out-of-order loading, in addition to that supported by Undeclared. But it is irrelavant in this example. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Feb. 16, 2009

Re: [Pharo-project] Loading Polymorph

by StÃ©phane Ducasse

ok do you imply that I should be able to push in the release the latest version without problem? Excellent! Stef On Feb 16, 2009, at 1:22 PM, Gary Chambers wrote: > Loads from 42 upwards should be ok as normal. Polymorph-Widgets- > gvc-45 now > on SqueakSource > with some lint related changes and a few other goodies ;-) > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Sunday, February 15, 2009 2:53 PM > Subject: Re: [Pharo-project] Loading Polymorph > > >> I will try to see what I can do to load it. >> >> Stef >> >> >>> Latest Polymorph-Widgets versions (from 41 to 42) require the MC >>> workaround to load/merge, unfortunately. >>> Anything down to drawing... in this case the change to dropShadows. >>> >>> Regards, Gary >>> _______________________________________________ >>> 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 >

Feb. 16, 2009

Re: [Pharo-project] Message sent but not implemented (part one)

by StÃ©phane Ducasse

thanks!!!!! Stef On Feb 16, 2009, at 10:49 AM, Damien Cassou wrote: > On Sat, Feb 14, 2009 at 2:20 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> it would be good to open a bug entry for each group (per class) of >> problems. > > Issues 528 to 570 > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 16, 2009

Re: [Pharo-project] Distributed versioning ... MonticelloHub?

by StÃ©phane Ducasse

sorry you lost me on this one. Stef On Feb 16, 2009, at 10:30 AM, Damien Cassou wrote: > On Sat, Feb 14, 2009 at 12:17 PM, Keith Hodges <keith_hodges(a)yahoo.co.uk > > wrote: >> I think that you will find that you have most of them already. > > Yes, only issue #456 (which includes the fix and is already in > PharoInbox) needs to be included. I guess there are no or very few > overrides left. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 16, 2009