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

Re: [Pharo-project] settings integration

by Alain Plantec

Lukas Renggli a Ã©crit : Hi Lukas, > I have a couple of ideas below. > > >> CodeHolderSettings class>>browsersHaveAnnotationPaneSetting >> <setting> >> ^ (SettingManager newSetting: 'Show annotation pane' translated) >> parent: #codeBrowsingSettingNode; >> default: false; >> target: CodeHolder; >> setSelector: #browsersHaveAnnotationPane:; >> getSelector: #browsersHaveAnnotationPane; >> description: 'If checked then the annotation pane is shown >> in browsers; it is dynamically updated with useful informations about >> the code which is currently browsed' translated >> > > 1. The pragma <setting> seems to be a bit short and quite a common > name. Could be that others use this pragma already. Maybe something > slightly longer like <systemsettings> would be better? > ok, but note that you can use any other keyword. The default is actually setting, it can be systemsetting. you can also decide to use your own keyword for your project or your application. As an example, <seaside>, and then, browse them with SystemSettingBrowser browse: 'seaside' "for seaside settings only" or SystemSettingBrowser browse: 'seaside|systemsetting' "for seaside and systemsetting settings" > 2. To avoid having class references from everywhere onto the system > preference package I suggest that you pass into the method a builder > object (see configurations in Seaside 3.0). Like this there are no > dependencies and no compiler warnings. This would also allow to define > multiple preferences in one method. > I would'nt do that . I think it is better to have a specific package for the settings. Then, SettingManager is only referenced by packages which are dedicated to settings management. It makes them very easily removable. see also my answer for you 'after refactoring' example. > 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: > 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 ? > 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 > After this "refactoring" I imagine that the code looks like this: > > 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" > 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). - one method = one setting - a setting method returns the setting declaration (which is never stored but only used dynamically by the settings browser) > 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. > Again one can decide to remove the system-settings package and then all setting declarations. So, I think is it better to have two packages. Another reason is that a setting class variable could be defined only for the need of the setting browser. If it is declared in a setting specific package, then the system can remain clean if the setting browser is removed. thanks, thanks for your comments !!! Cheers Alain > Cheers, > Lukas > >

Nov. 22, 2009

[Pharo-project] New Pharo based on core 10496

by Damien Cassou

http://pharo-project.org/pharo-download -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Nov. 22, 2009

Re: [Pharo-project] settings integration

by Lukas Renggli

I have a couple of ideas below. > CodeHolderSettings class>>browsersHaveAnnotationPaneSetting > Â Â <setting> > Â Â ^ (SettingManager newSetting: 'Show annotation pane' translated) > parent: #codeBrowsingSettingNode; > Â Â Â Â Â Â default: false; > Â Â Â Â Â Â target: CodeHolder; > Â Â Â Â Â Â setSelector: #browsersHaveAnnotationPane:; > Â Â Â Â Â Â getSelector: #browsersHaveAnnotationPane; > Â Â Â Â Â Â description: 'If checked then the annotation pane is shown > in browsers; it is dynamically updated with useful informations about > the code which is currently browsed' translated 1. The pragma <setting> seems to be a bit short and quite a common name. Could be that others use this pragma already. Maybe something slightly longer like <systemsettings> would be better? 2. To avoid having class references from everywhere onto the system preference package I suggest that you pass into the method a builder object (see configurations in Seaside 3.0). Like this there are no dependencies and no compiler warnings. This would also allow to define multiple preferences in one method. 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. 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. 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. After this "refactoring" I imagine that the code looks like this: 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" 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. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 22, 2009

[Pharo-project] windows 64 bit: printing NetNameResolver localHostAddress fails even after evaluating NetNameResolver initializeNetwork

by Bart Gauquie

This is related to: http://lists.gforge.inria.fr/pipermail/pharo-project/2009-November/016021.h… I was trying out magma on Pharo. I'm using magma r43final on Pharo1.0rc1 Latest update: #10493 on Windows Vista 64 bit. In order for the magma client wanting to connect to the server i had to adapt NetNameResolver>>useOldNetwork ^true It worked till i tried the new high availability of magma. If i tried with a node to connect to a primary server i always got following error on the secondary node: MagmaSession>>signalExceptionLike with as message: 'a primitive has failed'. After some debugging i figured out that the it in fact was the primary server which sent to the secondary an Error object with message text: 'a primitive has failed'. in the primary server log: MaLocalRequestServer(MaRequestServer)>>processRequest: Receiver: a MaLocalRequestServer Arguments and temporary variables: aMaClientServerRequest: a MaCommitRequest answer: Error: a primitive has failed Receiver's instance variables: console: a MaRequestServerConsole processor: a MagmaRepositoryController Inspired by some issues mentioned @ google code, I tried to evaluate NetNameResolver localHostAddress on the primary server image. That worked, however trying to print that resulted in 'a primitive has failed'. Even after the NetNameResolver initializeNetwork suggestions I found. error: NetNameResolver class(Object)>>error: Receiver: NetNameResolver Arguments and temporary variables: aString: 'a primitive has failed' Receiver's instance variables: superclass: Object methodDict: a MethodDictionary() format: 2 instanceVariables: nil organization: ('as yet unclassified') subclasses: nil name: #NetNameResolver classPool: a Dictionary(#DefaultHostName->'' #HaveNetwork->true #ResolverBusy->...etc... sharedPools: nil environment: Smalltalk category: #'Network-Kernel' traitComposition: nil localSelectors: nil NetNameResolver class(Object)>>primitiveFailed Receiver: NetNameResolver Arguments and temporary variables: Receiver's instance variables: superclass: Object methodDict: a MethodDictionary() format: 2 instanceVariables: nil organization: ('as yet unclassified') subclasses: nil name: #NetNameResolver classPool: a Dictionary(#DefaultHostName->'' #HaveNetwork->true #ResolverBusy->...etc... sharedPools: nil environment: Smalltalk category: #'Network-Kernel' traitComposition: nil localSelectors: nil NetNameResolver class>>primGetNameInfo:flags: Receiver: NetNameResolver Arguments and temporary variables: <<error during printing> Receiver's instance variables: superclass: Object methodDict: a MethodDictionary() format: 2 instanceVariables: nil organization: ('as yet unclassified') subclasses: nil name: #NetNameResolver classPool: a Dictionary(#DefaultHostName->'' #HaveNetwork->true #ResolverBusy->...etc... sharedPools: nil environment: Smalltalk category: #'Network-Kernel' traitComposition: nil localSelectors: nil SocketAddress>>hostNumber Receiver: <<error during printing>> Arguments and temporary variables: size: nil name: nil Receiver's instance variables: <<error during printing>> SocketAddress>>printOn: Receiver: <<error during printing>> Arguments and temporary variables: aStream: a LimitedWriteStream '' Receiver's instance variables: <<error during printing>> [] in SocketAddress(Object)>>printStringLimitedTo: Receiver: <<error during printing>> Arguments and temporary variables: s: a LimitedWriteStream '' Receiver's instance variables: <<error during printing>> I then tried to revert the changes to NetNameResolver back to: useOldNetwork ^UseOldNetwork ~~ false printing NetNameResolver localHostAddress now nicely printed a ipv6 address. However if i then try to connect to the primary server from the secondary server i get: MagmaSession>>signalExceptionLike MagmaEnvironmentError: magma@PC_XX:51003 could not be made a warm backup because it is not reachable from magma@PC_XX:51001. Which is again the same ipv6 error. So the problem i'm facing is that either of them work I can connect with my magma client to the server if i enable ipv4 only, but then high availability dont work and vice verse. Anyone any id how i can debug the primitive has failed on: NetNameResolver class>>primGetNameInfo: socketAddress flags: flags <primitive: 'primitiveResolverGetNameInfo' module: 'SocketPlugin'> flags == 0 ifTrue: [^self primGetNameInfo: socketAddress flags: SocketAddressInformation numericFlag]. self primitiveFailed further more, why cant the primitiveFailed mention which primitive has failed? Thanks, 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

Nov. 22, 2009

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

by alesch

I like LyX, on the Mac. Schwab,Wilhelm K wrote: > > 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 > > -- View this message in context: http://n2.nabble.com/LaTeX-users-favorite-editor-tp4043774p4047693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 22, 2009

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

by Michael van der Gulik

On Sun, Nov 22, 2009 at 8:39 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > 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. > Simple stuff: LyX. I don't know how well it imports LaTeX, but if LyX has the features you need then it can save a lot of time. Complex stuff: Emacs with lots of patience, fustration, wasted time and WTFs. I also use a DVI viewer: xdvi, or a newer one. Make a Makefile which compiles your LaTeX document to a DVI file quickly (via an editor keybinding if you're savvy), and then hit whatever key refreshes the view in the DVI viewer. This saves a lot of time. I've seen other people create a PDF file each time and re-open it in a PDF viewer, which is an incredibly slow process. Gulik. -- http://gulik.pbwiki.com/

Nov. 22, 2009

Re: [Pharo-project] settings integration

by StÃ©phane Ducasse

Sounds excellent to me. Imagine a removable Preference class. Stef On Nov 22, 2009, at 5:53 PM, Alain Plantec wrote: > Dear list, > > I'm about to integrate some settings in replacement of some preferences, > and I would like to have your opinions about the way. > > The new setting package make it possible to completely separate a > setting value > from the setting browser. In fact, the setting browser package should be > removeable > without any modification elsewhere. > > As an example, let's consider the #annotationPanes preference. > The only mandatory thing is that there is a class variable or an > instance variable of a singleton > in the package which owns the setting along with corresponding get/set > accessors. > For #annotationPanes, I define the #BrowsersHaveAnnotationPane class > variable in CodeHolder. > In addition, I define CodeHolder class>>browsersHaveAnnotationPane and > CodeHolder class>>browsersHaveAnnotationPane:. > > In order to be able to manage this setting from the setting browser, we > have to define a setting declaration for it. > Because the setting browser must be removeable, I would create a new > package for it. > Let's Tools-Base-Settings be this new package which then includes the > CodeHolderSettings class with the following declaration: > > CodeHolderSettings class>>browsersHaveAnnotationPaneSetting > <setting> > ^ (SettingManager newSetting: 'Show annotation pane' translated) > parent: #codeBrowsingSettingNode; > default: false; > target: CodeHolder; > setSelector: #browsersHaveAnnotationPane:; > getSelector: #browsersHaveAnnotationPane; > description: 'If checked then the annotation pane is shown > in browsers; it is dynamically updated with useful informations about > the code which is currently browsed' translated > > Is it ok like that ? > > Thanks > Alain > > > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 22, 2009

Re: [Pharo-project] (no subject)

by Schwab,Wilhelm K

Lukas, I'm not accusing you of snobbery, but it has been _obvious_ elsewhere, and it certainly has not helped advance the cause. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, November 22, 2009 1:32 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] (no subject) > 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. 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. 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. 22, 2009

Re: [Pharo-project] (no subject)

by Lukas Renggli

> 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. 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. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 22, 2009

[Pharo-project] settings integration

by Alain Plantec

Dear list, I'm about to integrate some settings in replacement of some preferences, and I would like to have your opinions about the way. The new setting package make it possible to completely separate a setting value from the setting browser. In fact, the setting browser package should be removeable without any modification elsewhere. As an example, let's consider the #annotationPanes preference. The only mandatory thing is that there is a class variable or an instance variable of a singleton in the package which owns the setting along with corresponding get/set accessors. For #annotationPanes, I define the #BrowsersHaveAnnotationPane class variable in CodeHolder. In addition, I define CodeHolder class>>browsersHaveAnnotationPane and CodeHolder class>>browsersHaveAnnotationPane:. In order to be able to manage this setting from the setting browser, we have to define a setting declaration for it. Because the setting browser must be removeable, I would create a new package for it. Let's Tools-Base-Settings be this new package which then includes the CodeHolderSettings class with the following declaration: CodeHolderSettings class>>browsersHaveAnnotationPaneSetting <setting> ^ (SettingManager newSetting: 'Show annotation pane' translated) parent: #codeBrowsingSettingNode; default: false; target: CodeHolder; setSelector: #browsersHaveAnnotationPane:; getSelector: #browsersHaveAnnotationPane; description: 'If checked then the annotation pane is shown in browsers; it is dynamically updated with useful informations about the code which is currently browsed' translated Is it ok like that ? Thanks Alain

Nov. 22, 2009