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

Re: [Pharo-project] O2PackageBrowser broken in Pharo 10495

by Matthias Berth

maybe, I used the other one (11.3), had no time to check with the current version yet. Cheers Matthias On Mon, Nov 23, 2009 at 10:37 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hasn't this been fixed in the latest Pharo image announced by Damien > yesterday? > > Adrian > > On Nov 23, 2009, at 19:20 , Matthias Berth wrote: > >> FWIW, I have submitted a quick a fix to #1476 >> UndefinedObject(Object)>>doesNotUnderstand: #takesNodes , see the >> EnhancedOB repository on squeaksource: >> >> Name: OmniBrowser2-matthias_berth.6 >> Author: matthias.berth >> Time: 14 November 2009, 2:56:23 pm >> UUID: 9ced8959-8aa3-4ce3-9341-e9367fbcb683 >> Ancestors: OmniBrowser2-DavidRoethlisberger.5 >> >> patch to tolerate nil in cmdFactories (otherwise browser won't open in >> current Pharo pharo1.0-10495-rc1web09.11.3 ) >> >> Cheers >> >> Matthias >> >> >> On Sun, Nov 22, 2009 at 5:50 PM, Damien Cassou <damien.cassou(a)gmail.com >> > wrote: >>> On Sat, Nov 21, 2009 at 9:32 PM, Adrian Lienhard <adi(a)netstyle.ch> >>> wrote: >>>> David has already fixed some issues a week ago (I know he fixed >>>> #1476). But >>>> there is no new build available yet. Until these new images are >>>> available, >>>> I've reverted the links on the download page to the previous >>>> versions, which >>>> do not have the issue of the O2 package browser. >>> >>> I will create a new release. >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Lambdas are relegated to relative obscurity until Java makes them >>> popular by not having them." James Iry >>> >>> _______________________________________________ >>> 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 >

Nov. 23, 2009

Re: [Pharo-project] Saving preferences to disk gives an error in latest pharo core

by Henrik Jegbjerg Hansen

Thanks, this fixes it for me! Henrik Johansen <henrik.s.johansen(a)veloxit.no> writes: > Yes, it's caused by preferences referencing obsolete classes. > > Change > Preferences class >> removePreference: aSymbol > "Remove all memory of the given preference symbol." > > self dictionaryOfPreferences removeKey: aSymbol ifAbsent: []. > Parameters removeKey: aSymbol ifAbsent: []. > (Parameters at: #PersonalDictionaryOfPreferences ifAbsent: []) ifNotNil: [:personalDict | personalDict removeKey: aSymbol ifAbsent: []] > > Then evaluate: > > Preferences removePreference: #automaticFlapLayout; > removePreference: #navigatorOnLeftEdge; > removePreference: #classicNavigatorEnabled. > > And you should be able to save. > > Cheers, > Henry > > > On Nov 23, 2009, at 4:46 17PM, Henrik Jegbjerg Hansen wrote: > >> Saving preferences to disk gives an error in latest pharo core. I am on >> Ubuntu Linux with the latest VM. >> >> Any ideas how to fix this? >> >> >> -- >> Henrik Jegbjerg Hansen >> >> _______________________________________________ >> 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 > -- Henrik Jegbjerg Hansen

Nov. 23, 2009

Re: [Pharo-project] O2PackageBrowser broken in Pharo 10495

by Adrian Lienhard

Hasn't this been fixed in the latest Pharo image announced by Damien yesterday? Adrian On Nov 23, 2009, at 19:20 , Matthias Berth wrote: > FWIW, I have submitted a quick a fix to #1476 > UndefinedObject(Object)>>doesNotUnderstand: #takesNodes , see the > EnhancedOB repository on squeaksource: > > Name: OmniBrowser2-matthias_berth.6 > Author: matthias.berth > Time: 14 November 2009, 2:56:23 pm > UUID: 9ced8959-8aa3-4ce3-9341-e9367fbcb683 > Ancestors: OmniBrowser2-DavidRoethlisberger.5 > > patch to tolerate nil in cmdFactories (otherwise browser won't open in > current Pharo pharo1.0-10495-rc1web09.11.3 ) > > Cheers > > Matthias > > > On Sun, Nov 22, 2009 at 5:50 PM, Damien Cassou <damien.cassou(a)gmail.com > > wrote: >> On Sat, Nov 21, 2009 at 9:32 PM, Adrian Lienhard <adi(a)netstyle.ch> >> wrote: >>> David has already fixed some issues a week ago (I know he fixed >>> #1476). But >>> there is no new build available yet. Until these new images are >>> available, >>> I've reverted the links on the download page to the previous >>> versions, which >>> do not have the issue of the O2 package browser. >> >> I will create a new release. >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> >> _______________________________________________ >> 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

Nov. 23, 2009

Re: [Pharo-project] PackageInfo>>classes does not distinguish traits from classes (issue?)

by Adrian Lienhard

Hi Simon, There is no such method. But it would be easy to add (just send "aPackage classes select: #isTrait"). The reason for returning traits with the classes is that clients of PackageInfo typically expect "compilation units", i.e., a collection including traits. The naming, of course, is not optimal, and should be fixed in the long run. The problem is to do so without breaking the clients of PackagInfo. Cheers, Adrian On Nov 23, 2009, at 16:28 , Simon Denier wrote: > Hi there > > When I run PackageInfo>>classes, I get both classes and traits defined > in the package. So I can understand the need for a method retrieving > all 'compilation units' (or behaviors) from a package, but is there no > method to just retrieve the regular classes? Especially since there is > a #externalTraits method. > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 23, 2009

Re: [Pharo-project] settings integration

by Lukas Renggli

> but lukas this is not because systemSetting: > > Â Â Â Â does not refer to setting classes that there is no dependency. > Â Â Â Â newSetting Â and all the rest will introduce a dependency. Sure, that's a dependency too, but not one that prevents clean loading. Hard dependencies in Smalltalk that prevent from loading are missing super classes, missing classes that are extended, missing traits imports, and missing class references. Pharo can somehow handle the last dependency gracefully, but it shows up as an error in the transcript and causes an undeclared variable to be defined in the system. Other Smalltalk don't allow to load such code (VAST). Personally I don't consider sending a non-existing message in a method that is never called that much of a problem. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 23, 2009

Re: [Pharo-project] Pharo by Example - chapter about Exception - Error - Notification - Abort?

by Bart Gauquie

Thanks very much, Bart 2009/11/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > Enjoy I had a lot of fun writing it when my family went to the swimming > pool and I could concentrate :) > > Stef > > On Nov 23, 2009, at 9:05 AM, Bart Gauquie wrote: > > > Dear all, > > > > I've been searching the Pharo by Example book about how to handle > Exception, Error, ... in Pharo. > > > > I've found some information about it in the SUnit chapter, in method > 7.11: Catching test case errors and failures; this is only a small fragment > however. > > > > Is there any chapter planned about this topic? It would be very useful i > think, since it is an important topic, and I've read that Smalltalks > exception handling is very powerful, but I don't know much about it and like > to learn it. > > > > Kind Regards, > > > > Bart > > > > -- > > imagination is more important than knowledge - Albert Einstein > > Logic will get you from A to B. Imagination will take you everywhere - > Albert Einstein > > Learn from yesterday, live for today, hope for tomorrow. The important > thing is not to stop questioning. - Albert Einstein > > The true sign of intelligence is not knowledge but imagination. - Albert > Einstein > > Gravitation is not responsible for people falling in love. - Albert > Einstein > > _______________________________________________ > > 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 > -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein Gravitation is not responsible for people falling in love. - Albert Einstein

Nov. 23, 2009

Re: [Pharo-project] settings integration

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : >>> I don't want an extra package just with the settings for every package >>> >> I write. Also I don't want to have unreferenced classes in any of my >> packages. >> > > But how can you then remove setting preference from your package? > Magic? but so far I do not see how. > > Package 1 > my app + class var for preferences (but no reference to preferences) > > Package 1-Pref > reference to setting > > so that I can remove Package1-pref when we remove preferences. > This is exactly what I would like to do for the migration from old preferences to the new setting framework in the core. But, as far as I understand, Lukas does'nt want to be constrained to introduce a "Package 1-Pref" package. This is why he prefers the builder pattern. Then, only at the price of one argument, even if setting declarations are implemented in "Package 1", no class dependency is introduced. I still prefer the 2 packages solution, even with the builder pattern because I think it is better to be able to remove all setting declaration methods and eventually some class variable if the setting package is removed. But ok, let's go for this refactoring ! :) Cheers Alain

Nov. 23, 2009

Re: [Pharo-project] LaTeX users: favorite editor??

by csrabak＠bol.com.br

I use Emacs + AUCTeX + RefTeX Em 21/11/2009 17:39, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: Stef, I looked at the PBE page again and noticed a link to the LaTeX sources for the book, which lead me to wonder what editor you use? I recently found TeX Maker, and generally like it. My one complaint is that (so far at least) I have found no analog to texify, which (part of MikTeX) would do everything required to update a document. While that might be painful for "quick" edits to a book, it's great for shorter documents or to ensure that the toc, references, etc. are up to date. Bill _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 23, 2009

Re: [Pharo-project] settings integration

by StÃ©phane Ducasse

>> I don't want an extra package just with the settings for every package > I write. Also I don't want to have unreferenced classes in any of my > packages. But how can you then remove setting preference from your package? Magic? but so far I do not see how. Package 1 my app + class var for preferences (but no reference to preferences) Package 1-Pref reference to setting so that I can remove Package1-pref when we remove preferences. >> Still that introduces a lot of dependencies between packages. In your > example CodeHolder still depends on the preferences, because it > depends on the CodeHolder-Preferences that in turn depend on the > Preferences. Loading and unloading in the right order will be a > nightmare (without having the transcript full of undeclared warnings). No code Holder does not depend on Preference. Now CodeHolder-Pref depend on Preference but just for the declaration of preference not for its execution. And Code-Holder Does not depend on Code-Holder-Pref this is the inverse > > My suggestion completely decouples the setting declaration from the > setting framework. Metacello is following that pattern for its project > definitions with great success. > >>> 3. getSelector:/setSelector: should be replaced by #selector:, the >>> write-accessor in most cases can be inferred from the read-accessor >>> (see Magritte). The target can be predefined to the receiving class, >>> that simplifies the definition. >>> >> done, but I would keep also getSelector:/setSelector: > > Yes, definitely. > >>> 4. Why is there a #default:? Normally a package should already have >>> initialized the setting, or does it lazily when the accessor is >>> performed the first time. >>> >> the default is optional. >> Do you think it is really a problem to keep it ? > > Actually that was more of a question. Maybe specifying a default is > also useful to reset the settings to the default value? > >>> 5. I don't know what #parent: means? If this is to group the settings >>> of a particular application I suggest to do that in the pragma. >>> >> now we have a tree of settings (group allow only one level). >> parent is the selector of the method which implements the parent setting >> (the parent node in the tree). >> I think it is better like this because : >> - you can use sender/implementor >> - when I implement a setting, I don't want to know/indicate the full path > > Who defines that tree? Who defines the labels of this tree? Who > defines the icons of that tree? > >> no, this is not like that because a setting declaration is never stored >> (I mean in a global tree somewhere) >> the tree is always dynamically built (no change management is to be >> implemented). > > I imagine that the builder has some kind of a Seaside like API that > allows the methods to add and configure the settings, and probably > also group them into tree nodes. In the following example there is no > need to use the pragma for the groups (which is ugly indeed): > > CodeHolder class>>settingsOn: aBuilder > <settings> > > aBuilder group > label: 'Code Browser'; > with: [ > aBuilder setting > label: 'Annotation Pane'; > selector: #annotationPane. > aBuilder setting > label: 'Auto Format'; > selector: #autoFormat. > aBuilder group > label: 'Highlighting'; > with: [ self settingsHighlightOn: aBuilder ]. > aBuilder group > label: 'Formatting'; > with: [ self settingsFormatOn: aBuilder ] ] > > I think that would also make the whole thing much easier to understand. > >> - one method = one setting > > The configurable formatter of the refactoring browser has 23 settings. > Shout, the syntax highlighter, has 108 style definitions. It simply > does not scale to be forced to have to write a separate method for > each setting. > >> - a setting method returns the setting declaration (which is never >> stored but only used dynamically by the settings browser) > > I did not suggest to store the settings anywhere. The builder object > would be passed into all <settings> methods to build the tree > dynamically whenever needed. > > Cheers, > 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

Nov. 23, 2009

Re: [Pharo-project] settings integration

by StÃ©phane Ducasse

> > Sure, because you still want to be able to declare the settings > anywhere. And you want to be able to add settings methods as class > extensions to other classes. This is all possible, the only difference > is that the settings method has one argument and therefor no > dependency to anything whatsoever (which is absolutely crucial). CodeHolder class>>systemSettings: aBuilder <systemsettings: 'Code Browser'> aBuilder newSetting label: 'Show annotation pane' translated; selector: #browsersHaveAnnotationPane; description: 'If checked then the annotation pane is shown ...'. aBuilder newSetting "defines more settings for that group" but lukas this is not because systemSetting: does not refer to setting classes that there is no dependency. newSetting and all the rest will introduce a dependency. > Yes, that would solve the problem of the 200 preferences. I still > prefer using a builder API, it would make it easier much easier to > read and build. Also consider that depending on { }-constructs for > settings declarations adds a dependency to Squeak/Pharo/GemStone, > because these array constructs are not part of of any language > specification. well.... at one point we should move. Because we should ideally get rid of #()

Nov. 23, 2009