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

[Pharo-project] DateAndTime/TimeStamp can't handle times with nanoseconds - although Time does

by Udo Schneider

All, while writing a log file parser which parses log entries with nano-second timestamps I hit the following issue: Time instances can handle times down to nanosecond level. So something like this t := Time hour: 12 minute: 34 second: 56 nanoSecond: 1. is valid and works w/o problems. However DateAndTime and subclasses are not able to deal with Time instances whose nanoCount is ~= 0. E.g. the following fails: dt := DateAndTime date: Date today time: t. ts := TimeStamp date: Date today time: t. I've opened an issue for this: http://code.google.com/p/pharo/issues/detail?id=1487 CU, Udo

Nov. 23, 2009

Re: [Pharo-project] RB doesn't preserve code formatting even in the simplest cases.

by Lukas Renggli

Aha, I see. Renaming reformats the implementors, but not the senders. This is fixed in Refactoring-Core-lr.78. Name: Refactoring-Core-lr.78 Author: lr Time: 23 November 2009, 11:11:43 am UUID: 411320fe-57e6-4e6e-ae64-a9ab37f2d178 Ancestors: Refactoring-Core-lr.77 - don't reformat method signatures when renaming a method, when extracting a method, when inlining a method and when moving a method 2009/11/23 George Herolyants <george.herolyants(a)gmail.com>: > Rename of the temp variable works fine, but rename of the method still > breaks formatting (in preview and after applying too). Checked in > pharo-dev 09.11.4 on BitBltTest>>testAlphaCompositing. > > 2009/11/23 Lukas Renggli <renggli(a)gmail.com>: >> I cannot reproduce. Can you try to rename a variable or class, because >> that should always work. Also make sure that you actually apply the >> refactoring, because in the changes browser the output is typically >> pretty printed for improved diffs. >> >> Lukas >> >> On Monday, November 23, 2009, George Herolyants >> <george.herolyants(a)gmail.com> wrote: >>> Just an example: given there is a method without arguments which has >>> several statements separated by empty lines. If you then try to rename >>> this method you lose all the empty lines. >>> >>> I've checked it in the latest pharo-dev and in pharo-core 10491 with >>> the latest AST-Core-lr.30, Refactoring-Core-lr.77 and >>> OB-Refactory-lr.170. >>> >>> I've opened an issue: http://code.google.com/p/pharo/issues/detail?id=1493 >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 23, 2009

Re: [Pharo-project] RB doesn't preserve code formatting even in the simplest cases.

by George Herolyants

Rename of the temp variable works fine, but rename of the method still breaks formatting (in preview and after applying too). Checked in pharo-dev 09.11.4 on BitBltTest>>testAlphaCompositing. 2009/11/23 Lukas Renggli <renggli(a)gmail.com>: > I cannot reproduce. Can you try to rename a variable or class, because > that should always work. Also make sure that you actually apply the > refactoring, because in the changes browser the output is typically > pretty printed for improved diffs. > > Lukas > > On Monday, November 23, 2009, George Herolyants > <george.herolyants(a)gmail.com> wrote: >> Just an example: given there is a method without arguments which has >> several statements separated by empty lines. If you then try to rename >> this method you lose all the empty lines. >> >> I've checked it in the latest pharo-dev and in pharo-core 10491 with >> the latest AST-Core-lr.30, Refactoring-Core-lr.77 and >> OB-Refactory-lr.170. >> >> I've opened an issue: http://code.google.com/p/pharo/issues/detail?id=1493 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > 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] RB doesn't preserve code formatting even in the simplest cases.

by Lukas Renggli

I cannot reproduce. Can you try to rename a variable or class, because that should always work. Also make sure that you actually apply the refactoring, because in the changes browser the output is typically pretty printed for improved diffs. Lukas On Monday, November 23, 2009, George Herolyants <george.herolyants(a)gmail.com> wrote: > Just an example: given there is a method without arguments which has > several statements separated by empty lines. If you then try to rename > this method you lose all the empty lines. > > I've checked it in the latest pharo-dev and in pharo-core 10491 with > the latest AST-Core-lr.30, Refactoring-Core-lr.77 and > OB-Refactory-lr.170. > > I've opened an issue: http://code.google.com/p/pharo/issues/detail?id=1493 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 23, 2009

[Pharo-project] RB doesn't preserve code formatting even in the simplest cases.

by George Herolyants

Just an example: given there is a method without arguments which has several statements separated by empty lines. If you then try to rename this method you lose all the empty lines. I've checked it in the latest pharo-dev and in pharo-core 10491 with the latest AST-Core-lr.30, Refactoring-Core-lr.77 and OB-Refactory-lr.170. I've opened an issue: http://code.google.com/p/pharo/issues/detail?id=1493

Nov. 23, 2009

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

by Bart Gauquie

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

Nov. 23, 2009

Re: [Pharo-project] settings integration

by Alain Plantec

> ok, thank you very much for this design tips. > but as far as I understand it is not so useful here. > re-tought a little bit: CodeHolderSetting class>>browserSettingsOn: aManager <setting> ^ aManager newLevel parent: #userInterfaceSettings withAll: { aManager newSetting: 'Annotation Pane'; selector: #annotationPane. aManager newSetting: 'Auto format'; selector: #autoFormat. .... } is the best solution. Alain

Nov. 23, 2009

Re: [Pharo-project] settings integration

by Alain Plantec

Lukas Renggli a Ã©crit : >> SystemSettingBrowser browse: 'seaside|systemsetting' "for seaside and >> systemsetting settings" >> > > I thought that there is a tree that already provides a kind of > grouping of settings. yes there is. > Why do you need another concept here? no new concept. It only makes use of a regexp instead of a string. I only didn't want a "hardcoded" keyword (setting) and be able to change it because I suspected that "setting" would not be ok for every one. There is a default which is now "setting", which will be "systemsetting" if we want and "SystemSettingBrowser open" allows you to browse the default settings. But imagine that someone do not want it's application setting to be browsed together with system settings. (debug, Free type, halo setting). It is simply possible because the keywords a setting browser is using can be passed as parameter. > I assume > that one could just display all settings from the root yes > , or starting at > an arbitrary node in the tree. > not for now but I can add it easily > I don't want an extra package just with the settings for every package > I write. so, do as you want. If you want your settings to be declared together with the rest of the code you simply can. But it is interesting because this is mainly what I asked and I have an answer. > Also I don't want to have unreferenced classes in any of my > packages. > > >> 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. >> > > 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. No, this is exactly what we want to avoid. CodeHolder have its own class variable and do not depend on any other package regarding the setting management. But there are some case where you can have to define some class variable for the setting browsing only (so only useful when the setting browser is available). I can give you an example if you want. Then, I think it is better to declare this class variable in another package for better separation of concerns. > Loading and unloading in the right order will be a > nightmare (without having the transcript full of undeclared warnings). > no, you can load the Tool-Base package without having to load the Tool-Base-Settings package. Tool-Base-Settings is only loaded if you want the setting browser. Imagine an image used headless. It does not need Tool-Base-Settings. > My suggestion completely decouples the setting declaration from the > setting framework. Metacello is following that pattern for its project > definitions with great success. > I like the builder solution. I find it very clean myself. The problem is that I think we don't need it if we keep the setting declaration as it is now. Regarding your suggestion concerning the way settings are declared, then yes a builder is a good solution. >> 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? > yes and also to know the kind of value if we have nil in the class variable representing the setting. But it is optional because one can also indicate the type explicitely in a declaration. > >> > > Who defines that tree?Who defines the labels of this tree? Who > defines the icons of that tree? > for a setting, all is given in a single setting declaration (except the icon but good idea, I will add this possibility) >> 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. > > At a first time, I liked that solution very much but now I don't. If I understand well, if we use this pattern, then settings are not discovered on the fly anymore (and with it, I don't see the utility of the pragma using except for root declarations). the tree is hard coded is such #settingOn: methods and then you introduce dependencies between settings. >> - 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. you only do that one time thought. but ok, I think I can easily allow several declarations in one method. something like: CodeHolderSetting class>>browserSettings <setting> ^ SettingManager newLevel parent: #userInterfaceSettings withAll: { SettingManager newSetting: 'Annotation Pane'; selector: #annotationPane. SettingManager newSetting: 'Auto format'; selector: #autoFormat. .... } which is ok if you declare your settings in a specific package or CodeHolderSetting class>>browserSettingsOn: aManager <setting> ^ aManager newLevel parent: #userInterfaceSettings withAll: { aManager newSetting: 'Annotation Pane'; selector: #annotationPane. aManager newSetting: 'Auto format'; selector: #autoFormat. .... } which is better if you do not want any setting specific package. is it ok like that ? if yes, the only point would be the #parent symbol. > 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. > ok, thank you very much for this design tips. but as far as I understand it is not so useful here. again, thank you for this discussion. Cheers Alain > Cheers, > Lukas > >

Nov. 23, 2009

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

by Ramiro Diaz Trepat

I am having the same issues trying to connet a Magma Client and a Magma Server in "localhost" using the latest Pharo on Snow Leopard (Mac). It is this issue with NetNameResolver, I couldn't find a work around yet. Forcing '127.0.0.1' for localhost used to work before, but not anymore. Same image and code seemed to run fine under Linux though. Cheers r 2009/11/22 Bart Gauquie <bart.gauquie(a)gmail.com> > 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 > > _______________________________________________ > 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

>> 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" I thought that there is a tree that already provides a kind of grouping of settings. Why do you need another concept here? I assume that one could just display all settings from the root, or starting at an arbitrary node in the tree. >> 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. 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. > 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. 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). 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

Nov. 22, 2009