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

Re: [Pharo-project] settings integration

by StÃ©phane Ducasse

> > > Note, that I would put the code directly on the class side of > CodeHolder. I don't see a reason why CodeHolderSettings are required. > If the preferences are stored in class variables one can easily access > the settings. I imagine because we want to be able to remove any trace of preferences. (may be could use class extension). Stef

Nov. 23, 2009

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

by StÃ©phane Ducasse

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

Nov. 23, 2009

[Pharo-project] Fwd: Issue 793 in pharo: Get ObjectTracer and ObjectViewer working

by StÃ©phane Ducasse

strange Begin forwarded message: > From: pharo(a)googlecode.com > Date: November 22, 2009 9:22:49 PM GMT+01:00 > To: stephane.ducasse(a)gmail.com > Subject: Re: Issue 793 in pharo: Get ObjectTracer and ObjectViewer working > > > Comment #2 on issue 793 by marianopeck: Get ObjectTracer and ObjectViewer working > http://code.google.com/p/pharo/issues/detail?id=793 > > Ok, the package ObjectMetaTools was comitted in PharoInbox with both classes. > However, I couldn't commit my change on Kernel (the removal of those 2 classes). My > image took 1gb of RAM and then an abort due to an out of memory. Is this a known > problem ? con can I remove those classes from Kernel-Objects then? > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings

Nov. 23, 2009

Re: [Pharo-project] (no subject)

by StÃ©phane Ducasse

On Nov 22, 2009, at 7:31 PM, Lukas Renggli wrote: >> IMHO, the real problem has been a sort of XP snobbery: it appears that those building or integrating what would otherwise be a wonderful tool, have zero interest in preserving comments, and even some contempt for those of who write them. > > This has nothing to do with snobbery, it is a technical issue. > >> I will spare you second-hand comments about what has been done in other languages and editors, as I have never encountered an RB anywhere but Smalltalk. > > I know the refactoring engine of Eclipse. It must be 20 years ahead of > Smalltalk. Not sure because it is full of bugs because Java is complex. Now if you give me one engineering for 6 months I guess we can catch up and what you are doing is cool. At Smalltalk diego "gneffer" show a realy extension to RB (and really simple to implement) where you could select a couple of methods and it would check duplicated code and extract the methods automatically. > When saying that one must keep in mind that printing Java code so that > it preserves the formatting is easier than to do the same with > Smalltalk. Even if they have to handle 100+ AST node types > individually, they all have a very strict structure and are rarely > nested in unpredictable ways. Furthermore since the editor expands, > completes, indents and formats a lot of code automatically anyway, > people don't even notice when their code gets reformatted. I know that we discuss the placement of comment with gwenael too. I think that some heuristics may help. And probably with the simple pretty printer of damien. Stef > 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] O2PackageBrowser broken in Pharo 10495

by Matthias Berth

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 >

Nov. 23, 2009

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

by Henrik Johansen

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 >

Nov. 23, 2009

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

by Henrik Jegbjerg Hansen

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

Nov. 23, 2009

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

by Simon Denier

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

Nov. 23, 2009

Re: [Pharo-project] Merlin: a library to build Wizards

by Schwab,Wilhelm K

Keeping a desired size might be as simple as adding a surrounding container, but hopefully Gary can provide a #preferredExtent or something, that when notNil fixes the size of a window w/o the need to "waste a widget." It took a little while to get it right, but Dolphin has long done a nice job of that - no great surprise really. As a grateful friend, not only does the current situation force the user to chase the buttons between panes, it also looks like we don't know how to fix the size (which coincidentally is the case, however temporary it might be<g>). Having views that _can_ size themselves is great; we should not need to rely on it when building for end users. I have not had much time for GUIs in Pharo, but I already miss MVP. Gary is probably the best person to comment on whether your data manipulation methods are redundant or belong at a more abstract level. I think it has to be one or the other, as getting data into and out of controls is not specific to wizards. If you have done it well, we should probably spread it around; if there are better ways to do the job, we should note that and you should eventually/gradually move toward the better approach. Repeating myself a little, I really like value models and adapters for matching domain objects to controls. Thanks for doing this! Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Cyrille Delaunay Sent: Monday, November 23, 2009 9:23 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Merlin: a library to build Wizards Hi, Thanks for your comments. I have changed the default buttons to 'Next >>' and '<< Back'. I have not yet find how to fix the same size to all panes. For the moment I'm using a 'PluggableDialogWindow' that I open in a StandardWindow (StandardWindow new openModal: dialogWindow). Doing this, the pane is automatically resize according the elements of the dialogWindow. But indeed, it would maybe be more usefull for the user to click the next buttons one after the others without moving the moose according the resized pane. WizardPart is not so specific to the wizard hierarchy: -> There is the two methods 'outputValue' and 'retrieveInputRequired' that make the link with a cooresponding wizard pane , but they are abstract methods. Therefore, you can retrieve the inputs in the way you want and make what you want with the output. -> The other link is a kind of control for enabling the next button of the wizard pane. By default, it's an instance variable set to true, so you can not take care of that. A lot of subclasses of WizardPart I made don't retrieve any input and don't care about the next button. You can create instances and directly have the morph contents (with the method 'contents'). I agree for the LastPane. For example, in the addition, soustraction, ... wizard example, a LastPane could have been the selection of the last element of the operation, and after that we could have a pane that simply display the result (without any control). However, the first pane diplayed in a wizard will allways look like a FirstWizardPane (or maybe a customized version of it). 2009/11/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> If I understand you, that's not a good idea: the last pane in the sequence is not necessarily the last step in the wizard. I have examples in Dolphin that branch depending on user's choices along the way, and sometimes it reaches a close with additional panes remaining in the list, but those are for "the road not taken." Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of vicnet Sent: Monday, November 23, 2009 8:21 AM To: pharo-project(a)lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Merlin: a library to build Wizards Hello, Cyrille Delaunay wrote: > > Just send this email to inform you that I have developed a small > library ( called 'Merlin' ) that provide a simple structure to build Wizards. > I test it. It is quit good. Just wondering why user have to say a pane is the first pane, dans another pane is the last. Could not the framework find it by itself ? The first one is a FirstPane and the last one when it is launch is a LastPane ? a+ Vicnet -- View this message in context: http://n2.nabble.com/Merlin-a-library-to-build-Wizards-tp4038238p4051036.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 23, 2009

Re: [Pharo-project] Merlin: a library to build Wizards

by Cyrille Delaunay

Hi, Thanks for your comments. I have changed the default buttons to 'Next >>' and '<< Back'. I have not yet find how to fix the same size to all panes. For the moment I'm using a 'PluggableDialogWindow' that I open in a StandardWindow (StandardWindow new openModal: dialogWindow). Doing this, the pane is automatically resize according the elements of the dialogWindow. But indeed, it would maybe be more usefull for the user to click the next buttons one after the others without moving the moose according the resized pane. WizardPart is not so specific to the wizard hierarchy: -> There is the two methods 'outputValue' and 'retrieveInputRequired' that make the link with a cooresponding wizard pane , but they are abstract methods. Therefore, you can retrieve the inputs in the way you want and make what you want with the output. -> The other link is a kind of control for enabling the next button of the wizard pane. By default, it's an instance variable set to true, so you can not take care of that. A lot of subclasses of WizardPart I made don't retrieve any input and don't care about the next button. You can create instances and directly have the morph contents (with the method 'contents'). I agree for the LastPane. For example, in the addition, soustraction, ... wizard example, a LastPane could have been the selection of the last element of the operation, and after that we could have a pane that simply display the result (without any control). However, the first pane diplayed in a wizard will allways look like a FirstWizardPane (or maybe a customized version of it). 2009/11/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > If I understand you, that's not a good idea: the last pane in the sequence > is not necessarily the last step in the wizard. I have examples in Dolphin > that branch depending on user's choices along the way, and sometimes it > reaches a close with additional panes remaining in the list, but those are > for "the road not taken." > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of vicnet > Sent: Monday, November 23, 2009 8:21 AM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Merlin: a library to build Wizards > > > Hello, > > > Cyrille Delaunay wrote: > > > > Just send this email to inform you that I have developed a small > > library ( called 'Merlin' ) that provide a simple structure to build > Wizards. > > > I test it. It is quit good. > > Just wondering why user have to say a pane is the first pane, dans another > pane is the last. > > Could not the framework find it by itself ? > The first one is a FirstPane and the last one when it is launch is a > LastPane ? > > a+ > Vicnet > -- > View this message in context: > http://n2.nabble.com/Merlin-a-library-to-build-Wizards-tp4038238p4051036.ht… > 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 >

Nov. 23, 2009