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

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

by Schwab,Wilhelm K

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] 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

Nov. 23, 2009

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

by vicnet

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.

Nov. 23, 2009

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

by Simon Denier

On 23 nov. 2009, at 08:59, Schwab,Wilhelm K wrote: > If nothing else, it deserves a section, probably after bocks, > conditionals and loops. If nobody else wants to be bothered, I can > draft something. Dont even start! There is already one, although it is scheduled for the 2nd edition of PBE. So you have to download the latex sources and compile it yourself (note: each chapter of the book can be compiled independently of the others) > > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of Bart Gauquie > Sent: Monday, November 23, 2009 3:06 AM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Pharo by Example - chapter about Exception > - Error - Notification - Abort? > > 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 -- Simon

Nov. 23, 2009

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

by Schwab,Wilhelm K

If nothing else, it deserves a section, probably after bocks, conditionals and loops. If nobody else wants to be bothered, I can draft something. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Bart Gauquie Sent: Monday, November 23, 2009 3:06 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Pharo by Example - chapter about Exception - Error - Notification - Abort? 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

Lukas Renggli a Ã©crit : >> 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. >> > > 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). > You convinced me on that point > Also consider that with a builder you can define the tree and the > settings at the same time. One package could define: > > " #groupNamed: creates a new group lazily or returns an existing > one, this allows to extend and reuse existing groups. #groupNamed: > does not depend on order, so the settings tree can be built in any > order. " > (aBuilder groupNamed: #codeBrowser) with: [ > (aBuilder groupNamed: #highlight) > label: 'Highlighting'; > description: 'The Shout Syntax Highlighter'; > with: [ > #(charLiteral stringLiteral numberLiteral blockArg > blockTemp ...) do: [ :e | > aBuilder setting ... ] ] ] > ok, but I still don't like having to express the entire absolute path. What about this : CodeHolderSetting class>>browserSettingsOn: aBuilder <setting> (aBuilder groupNamed: #highlight) parent: #codeBrowser; "create it lazily or get the existing one" label: 'Highlighting'; description: 'The Shout Syntax Highlighter'; with: [ #(charLiteral stringLiteral ...blockTemp ...) do: [ :e | aBuilder setting ... ] ] then the two solutions can live together. I will give it a try. Thanks Alain > Lukas > >

Nov. 23, 2009

Re: [Pharo-project] Conseils for develop a grid

by Alain Plantec

nullPointer a Ã©crit : > Many many thanks. I didnÂ´t see that property. > > PD. I know of existence of another "DataSet" morphs. The problem is the > integration in my UIBuilder. Really i prefer than all widgets working of > same way, without differences in behavior and public interfaces of ones > respect others. > Of course, it is better to have uniform interfaces. If you speak about MorphTreeMorph, just ask, I can adapt it to your need. Cheers Alain > Regards, and many thanks again :) > > > > Alain Plantec-4 wrote: > >> nullPointer a Ã©crit : >> >>> The problem is than scroller left never change when scrollbar is >>> scrolled. >>> IÂ´m seeing the state of scrollpane and donÂ´t see a change in a var when >>> is >>> scrolled. My purpose with that is change position of row header to same X >>> of >>> rows panel. >>> >>> >> Hi nullPointer, >> >> argh, yes, you're right, sorry for this bad answer :( >> The good answer is that you can use the scroller offset. >> In order to update the position of the header when the horizontal >> scrollbar is changed, >> you can redefine Scrollpane>>hScrollBarValue: >> >> YourGridClass>>hScrollBarValue: scrollValue >> super hScrollBarValue: scrollValue. >> self updateHeader "makes use of 'scroller offset x' in order to >> change header position" >> >> hope that it will help this time. >> >> Cheers >> Alain >> >> >> >> _______________________________________________ >> 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] Conseils for develop a grid

by nullPointer

Many many thanks. I didnÂ´t see that property. PD. I know of existence of another "DataSet" morphs. The problem is the integration in my UIBuilder. Really i prefer than all widgets working of same way, without differences in behavior and public interfaces of ones respect others. Regards, and many thanks again :) Alain Plantec-4 wrote: > > nullPointer a Ã©crit : >> >> The problem is than scroller left never change when scrollbar is >> scrolled. >> IÂ´m seeing the state of scrollpane and donÂ´t see a change in a var when >> is >> scrolled. My purpose with that is change position of row header to same X >> of >> rows panel. >> > Hi nullPointer, > > argh, yes, you're right, sorry for this bad answer :( > The good answer is that you can use the scroller offset. > In order to update the position of the header when the horizontal > scrollbar is changed, > you can redefine Scrollpane>>hScrollBarValue: > > YourGridClass>>hScrollBarValue: scrollValue > super hScrollBarValue: scrollValue. > self updateHeader "makes use of 'scroller offset x' in order to > change header position" > > hope that it will help this time. > > Cheers > Alain > > > > _______________________________________________ > 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/Conseils-for-develop-a-grid-tp4028690p4050447.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 23, 2009

Re: [Pharo-project] settings integration

by Lukas Renggli

> 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. 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). > 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. 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. Also consider that with a builder you can define the tree and the settings at the same time. One package could define: " #groupNamed: creates a new group lazily or returns an existing one, this allows to extend and reuse existing groups. #groupNamed: does not depend on order, so the settings tree can be built in any order. " (aBuilder groupNamed: #codeBrowser) with: [ (aBuilder groupNamed: #highlight) label: 'Highlighting'; description: 'The Shout Syntax Highlighter'; with: [ #(charLiteral stringLiteral numberLiteral blockArg blockTemp ...) do: [ :e | aBuilder setting ... ] ] ] Lukas -- 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

Great! Thank you very much! 2009/11/23 Lukas Renggli <renggli(a)gmail.com>: > 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 >

Nov. 23, 2009

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

by Adrian Lienhard

What exactly has changed in the networking code in Pharo compared to Squeak 3.9/3.10? Adrian On Nov 23, 2009, at 01:13 , Ramiro Diaz Trepat wrote: > 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 >> > _______________________________________________ > 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