- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

Ok I see > That was recently added to the classbuilder. As I wrote in the other > thread the class builder should not bother about such things, a > preference does not help here because newbies won't know what settings > they have to choose for a particular package to load without debuggers > popping up. I know that we already disagree on that one so I will reread the thread if needed. Now having a bit of rules should help. Uppercase are for globals. Then the preference has nothing todo with newbies. I thought more as a way to help you to migrate. Newbies should not write code were classinstancevar are in uppercase. > I created lint rules that check for consistent > capitalization of variable names (instance-, temp-, argument-variables > lowercase; class-, pool-, global-variables uppercase). > >> I do not understand why if you turn an uppercase class instance >> variable >> into a lower case class instance variable this would fucked up the >> other pier installations? >> The migration of instances is broken? > > The class builder is not the problem. It is Monticello that treats a > variable renaming as a removal of the old and addition of the new > variable. Indeed this is not good and break the smooth migration of smalltalk. Sorry about that. This really shows that we can improve. For example the fact that the changeset does not treat class definitino as doit and that instance varaible are not first class entities does not help either. stef

Feb. 17, 2009

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

by Marcus Denker

Hi, I think we should revert the change. The idea was to enforce good coding practices, for that, a better place is the browser itself: it should have a "checking" phase where it does checks and tells the user if there are strange things (Lukas mentioned that Lint applied to just one method is *very* fast). Marcus On 17.02.2009, at 09:59, Lukas Renggli wrote: >> propose a preference to turnout the warning >> Who implemented this Uppercase class instance variable. > > That was recently added to the classbuilder. As I wrote in the other > thread the class builder should not bother about such things, a > preference does not help here because newbies won't know what settings > they have to choose for a particular package to load without debuggers > popping up. I created lint rules that check for consistent > capitalization of variable names (instance-, temp-, argument-variables > lowercase; class-, pool-, global-variables uppercase). > >> I do not understand why if you turn an uppercase class instance >> variable >> into a lower case class instance variable this would fucked up the >> other pier installations? >> The migration of instances is broken? > > The class builder is not the problem. It is Monticello that treats a > variable renaming as a removal of the old and addition of the new > variable. > > Lukas > > -- > 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Feb. 17, 2009

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

by Lukas Renggli

> propose a preference to turnout the warning > Who implemented this Uppercase class instance variable. That was recently added to the classbuilder. As I wrote in the other thread the class builder should not bother about such things, a preference does not help here because newbies won't know what settings they have to choose for a particular package to load without debuggers popping up. I created lint rules that check for consistent capitalization of variable names (instance-, temp-, argument-variables lowercase; class-, pool-, global-variables uppercase). > I do not understand why if you turn an uppercase class instance variable > into a lower case class instance variable this would fucked up the > other pier installations? > The migration of instances is broken? The class builder is not the problem. It is Monticello that treats a variable renaming as a removal of the old and addition of the new variable. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 17, 2009

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

by StÃ©phane Ducasse

propose a preference to turnout the warning Who implemented this Uppercase class instance variable. I do not understand why if you turn an uppercase class instance variable into a lower case class instance variable this would fucked up the other pier installations? The migration of instances is broken? Stef On Feb 17, 2009, at 9:34 AM, Lukas Renggli wrote: >> 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 > > _______________________________________________ > 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 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