July 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] How to interactively add items to a tree widget?

by Rob Rothwell

Benjamin, Thanks for the encouragement! > This is probably a pretty newbie question, but can anyone point me towards > > creating some code to right click on a tree item and add a pop-up menu so > I > > can prompt for some input and create a new child of that node? > > > > > I figured out how to change the contents of the tree in UITheme > > exampleBasicControls by creating a Dictionary with some child > Dictionaries > > containing some objects, but now I seem to have a few challenges: > > > > 1. The items are not being highlighted when I click on them (they aren't > > in > > the example either). > > > > I have the same problem, so if you find how to make it works i'm listening > ^^ > I think we can learn a lot from FileList, which uses the superclass of TreeListMorph (SimpleHierarchicalListMorph). It properly highlights, and SimpleHierarchicalListMorph has a context menu as well. It's all there, I am just not that good at reading Smalltalk code in general and morphic code specifically! Also, SimpleHierarchicalListMorph submorphs example displays the same behavior we have noted, but you can see WHY since a proper selection method is not given during initialization. I'm going to try to expand the submorphs example to have the functionality that the FileList drive volume pane does, and go from there... > > > 2. I need a nudge in the right direction to capture the right click. > > > > > Maybe you should rewrite the mouseDown: method and add a test like > > event yellowButtonPressed (or the button you want) > ifTrue: [ "popup a menu" ] > We don't even need this for a popup menu...the functionality is built in, I think! > > > > > 3. If I do that and successfully add a new child to a node, I don't know > > how to tell the tree to refresh itself... > > > > > Send the message updateList to your MorphTreeMorph. If you have correctly > build your tree it works great ( but the highlighting doesn't work :s ) > I was using TreeListMorph, one of the Polymorph controls, for which you seem to specifiy a #changeSelected: method... > > > Good luck > > Benjamin > Thanks! Rob

July 28, 2010

[Pharo-project] ProcessWrapper BUGs

by Denis Kudriashov

Hello I found bugs in ProcessWrapper try externalKiosk := ProcessWrapper new. externalKiosk startWithCommand: 'notepad'. Do "externalKiosk terminate" twice. And image crashed without any logs Do "externalKiosk finalize" twice.And image crashed without any logs but not immediately. Besides I found that multiple starting and terminating ProcessWrapper and then saving image can corrupt it. And restarting image crashed by some failure of finalization process in ProcessWrapper plugin. (I see it in crash log). I test it in Pharo 1.1 with stardart and cog VM

July 28, 2010

Re: [Pharo-project] How do I enter Cyrillic letters in Pharo 1.1 / Seaside3.0rc images

by Andrey Larionov

In Pharo1.1 by default installed Bitmap fonts, which dosen't contains unicode glyphs. In preference browser you can select TrueType fonts as you like, which will correctly diaplays cyrillic glyphs. On Wed, Jul 28, 2010 at 00:17, Stanislav Paskalev <kshorg(a)gmail.com> wrote: > Hello, > Using the PBE 1.0 image, entering and displaying cyrillic characters > works fine. However in Pharo 1.1 or the seaside image, all I get are > question marks. I copied over the DejaVu fonts folder, selected > "Install bitmap DejaVu fonts", but I'm still getting ???. Â What should > I do so I can have them working ? > > Best regards, > Stanislav Paskalev > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 28, 2010

[Pharo-project] SpellChecker problem [WAS] [ANN 1.1] One-Click 1.1 release

by Mariano Martinez Peck

On Tue, Jul 27, 2010 at 5:09 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > I added the following methods: > > RBMacSpellChecker>>primitiveSetLanguage: data > <primitive: 'primitiveSetLanguage' module: 'SpellingPlugin'> > self primitiveFailed > > RBMacSpellChecker>>primitiveGetLanguage > <primitive:'primitiveGetLanguage' module: 'SpellingPlugin'> > > self primitiveFailed > > I do not understand why : > > checker := RBMacSpellChecker new. > checker primitiveSetLanguage: 'fr'. > result := checker check: 'How are you ?'. > checker primitiveSetLanguage: 'en'. > result > > returns an OrderedCollection() > > and : > > checker := RBMacSpellChecker new. > checker primitiveSetLanguage: 'fr'. > checker primitiveGetLanguage. > result := checker check: 'How are you ?'. > checker primitiveSetLanguage: 'en'. > result > > returns the correct answer: an OrderedCollection('How' 'you') > > Any ideas ? Something wrong with the SpellingPlugin ? > > > On Mon, Jul 26, 2010 at 3:46 PM, Serge Stinckwich > <serge.stinckwich(a)gmail.com> wrote: > > On Mon, Jul 26, 2010 at 2:05 PM, Serge Stinckwich > > <serge.stinckwich(a)gmail.com> wrote: > >> 2010/7/25 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >>> > >>> > >>> On Sun, Jul 25, 2010 at 4:02 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > >>>> > >>>> Hm, the link doesn't work for me. I just get an empty response... > >>>> > >>> > >>> https://gforge.inria.fr/frs/download.php/27303/Pharo-1.1-OneClick.zip > >>> > >>> works ok here > >> > >> Works ok for me also. > >> > >> 9764 tests, 9693 passes, 53 expected failures, 17 failures, 1 error > >> on Mac OS X 10.6.4. Most of the failures reported are inside > RBSpellingRuleTest. > >> Tests like: > >> > >> testPerfectSentence > >> | result | > >> result := self checker > >> check: 'This is an english sentence without problems.'. > >> self assert: result isCollection. > >> self assert: result isEmpty > >> > >> could not work on my machine, because by default i'm using the french > >> speller ... > >> I made some modifications to switch the speller to english and came > >> back to the original language after the tests. I put my modifications > >> here: http://code.google.com/p/pharo/issues/detail?id=2714 > >> > >> After that all RBSpellingRuleTest are green. > > > > Hum in fact no ... there is still some problems. > > > > -- > > Serge Stinckwich > > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > > Every DSL ends up being Smalltalk > > http://doesnotunderstand.org/ > > > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 27, 2010

Re: [Pharo-project] Nested Configurations

by Mariano Martinez Peck

Yes, the tutorial include Project references. It is the second class. In addition, you may want to see the draft I attach of the Metacello chapter we wrote for PBE2 Feedback is welcome! mariano On Tue, Jul 27, 2010 at 10:42 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > > Good point... I've created it a critical tutorial task for it.... > > Else I forgot to say that your tutorial is very well done and quite useful. > Very good job. I should do one for Mondrian... > > Alexandre > > > > > > Dale > > > > Alexandre Bergel wrote: > >> Hi Dale, > >> I tried your tutorial some times ago. This was not featured. Maybe this > is something useful to have... > >> Cheers, > >> Alexandre > >> On 27 Jul 2010, at 21:44, Dale Henrichs wrote: > >>> Denis Kudriashov wrote: > >>>> Hello > >>>> Can I use configurations inner my configurations to set dependencies > between packages. > >>>> For example, my application depends on XmlParser. In > ConfigurationOfMyApp I need set "requires: 'XmlParser'". > >>>> But I load XmlParser to my image by ConfigurationOfXmlParser. And I > dont want inspect ConfigurationOfXmlParser to see what packages I need load > for XmlParser. > >>>> Can I refer to ConfigurationOfXmlParser in ConfigurationOfMyApp? > >>> Denis, > >>> > >>> You can refer to the XML config with the following statement in your > baseline method define the project reference and the dependencies: > >>> > >>> ... > >>> spec > >>> project: 'XML Parser' with: [ > >>> spec > >>> className: 'ConfigurationOfXMLSupport'; > >>> loads: #('Core'); > >>> repository: 'http://www.squeaksource.com/MetacelloRepository' ]. > >>> ... > >>> spec package: 'myPackage' with: [ > >>> spec requires: #('XML Parser'). > >>> ... > >>> > >>> Then in your version method specify the particular version of the XML > Parser that you want to use: > >>> > >>> ... > >>> spec project: 'XML Parser' with: '1.0'. > >>> .... > >>> > >>> Dale > >>> > >>> _______________________________________________ > >>> 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 27, 2010

Re: [Pharo-project] Object>>doesNotUnderstand:

by Denis Kudriashov

> > In either case control should not return to the point of error. If you > want to log errors and then continue you need to continue from some > well-defined point, not merely return control to the point of error. So if > your approach is to catch and log errors, after logging you need to transfer > control back to some starting point, e.g. by throwing some ResumeExecution > exception. > Thanks, It really work

July 27, 2010

Re: [Pharo-project] Object>>doesNotUnderstand:

by Eliot Miranda

2010/7/27 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/7/27 Denis Kudriashov <dionisiydk(a)gmail.com> > >> This is intentional. Martin's reply is one half of the issue, that you >>> want to be able to proceed after defining a method in the debugger. The >>> otehr half is that you want to be able to catch doesNotUnderstand: in an >>> exception handler and proceed with a result, e.g. >>> >> >> [nil zork] >> on: MessageNotUnderstood >> do: [:ex| >> ex message selector == #zork ifTrue: >> [ex resume: #ok]. >> ex pass] >> >> evaluates to #ok. >> >> >> This all work correct with ProtoObject implementation >> >> ProtoObject>>doesNotUnderstand: aMessage >> >> ^ MessageNotUnderstood new >> message: aMessage; >> receiver: self; >> signal >> > > Right, but you can't redefine and continue. The Object implementation does > both. It used to only allow redefinition, not catching. > I mean the Object implementation used to not allow catching and proceeding, only catching and aborting. cheers Eliot > >> >> 28 Ð¸ÑÐ»Ñ 2010 Ð³. 0:48:18 UTC+4 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ dionisiydk < >> dionisiydk(a)gmail.com> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >> >> I think that the bug is that you haven't modified the system to quit on >>>> an UnhandledException. i.e. in a headless context control should never get >>>> back to the doesNotUnderstand: method if the MessageNotUnderstood exception >>>> is not caught. How should one continue after an unhandled error? >>>> >>> >>> With my approach I have "null object message eating" behavior. And when >>> any unhandled errors raised in system user will see nothing. Only log file >>> will contain it. >>> >>> 2010/7/28 Eliot Miranda <eliot.miranda(a)gmail.com> >>> >>>> >>>> >>>> 2010/7/27 Denis Kudriashov <dionisiydk(a)gmail.com> >>>> >>>> Hello, >>>>> >>>>> I found method doesNotUnderstand have very strange implementation >>>>> >>>>> Object>>doesNotUnderstand: aMessage >>>>> | exception resumeValue | >>>>> (exception := MessageNotUnderstood new) >>>>> message: aMessage; >>>>> receiver: self. >>>>> resumeValue := exception signal. >>>>> ^exception reachedDefaultHandler >>>>> ifTrue: [aMessage sentTo: self] >>>>> ifFalse: [resumeValue] >>>>> >>>>> When Error has no handlers #defaultAction is executed. For >>>>> MessageNotUnderstood #defaultAction is UnhandledError signal. And for >>>>> UnhandledError #defaultAction is opening debugger. >>>>> If you change it to do nothing (^self) you get infinite loop on any >>>>> MessageNotUnderstood signal. >>>>> It is because "ifTrue" branch executed in doesNotUnderstood method and >>>>> message resend to receiver. >>>>> >>>>> Why method implemented such way? Why it is differ from ProtoObject >>>>> implementation. I think It's bug implementation. >>>>> >>>> >>>> This is intentional. Martin's reply is one half of the issue, that you >>>> want to be able to proceed after defining a method in the debugger. The >>>> otehr half is that you want to be able to catch doesNotUnderstand: in an >>>> exception handler and proceed with a result, e.g. >>>> >>>> [nil zork] >>>> on: MessageNotUnderstood >>>> do: [:ex| >>>> ex message selector == #zork ifTrue: >>>> [ex resume: #ok]. >>>> ex pass] >>>> >>>> evaluates to #ok. >>>> >>>> >>>>> >>>>> I found this problem when I try implement stuff to turn off openning >>>>> debugger on unhandled error (and write it to log) >>>>> >>>>> UnhandledError>>defaultAction >>>>> "The current computation is terminated. The cause of the error >>>>> should be logged or reported to the user. If the program is operating in an >>>>> interactive debugging environment the computation should be suspended and >>>>> the debugger activated." >>>>> ^ToolSet debugError: exception. >>>>> >>>>> ToolSet class>>debugError: anError >>>>> "Handle an otherwise unhandled error" >>>>> self default ifNil:[ | ctx | >>>>> Smalltalk >>>>> logError: anError description >>>>> inContext: (ctx := anError signalerContext) >>>>> to: 'PharoDebug.log'. >>>>> self inform: (anError description, String cr, ctx shortStack). >>>>> ^anError return]. >>>>> ^self default debugError: anError >>>>> >>>>> I just implement subclass of StandartToolSet with empty method >>>>> #debugError:. Then I do "ToolSet default: MyToolSet". And now unhandled >>>>> errors raise infinit loop and never return. >>>>> >>>>> I fix that by: >>>>> >>>>> MyToolSet>>debugError: anError >>>>> anError class = MessageNotUnderstand ifTrue: [anError >>>>> reachedDefaultHandler: true]. >>>>> >>>>> I think this is hack. But it is work. No errors show to user.And all >>>>> work good. >>>>> >>>>> What do you think? >>>>> >>>> >>>> I think that the bug is that you haven't modified the system to quit on >>>> an UnhandledException. i.e. in a headless context control should never get >>>> back to the doesNotUnderstand: method if the MessageNotUnderstood exception >>>> is not caught. How should one continue after an unhandled error? >>>> >>>> HTH >>>> Eliot >>>> >>>> >>>>> Best regards, >>>>> Denis >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > >

July 27, 2010

Re: [Pharo-project] Object>>doesNotUnderstand:

by Eliot Miranda

2010/7/27 Denis Kudriashov <dionisiydk(a)gmail.com> > This is intentional. Martin's reply is one half of the issue, that you >> want to be able to proceed after defining a method in the debugger. The >> otehr half is that you want to be able to catch doesNotUnderstand: in an >> exception handler and proceed with a result, e.g. >> > > [nil zork] > on: MessageNotUnderstood > do: [:ex| > ex message selector == #zork ifTrue: > [ex resume: #ok]. > ex pass] > > evaluates to #ok. > > > This all work correct with ProtoObject implementation > > ProtoObject>>doesNotUnderstand: aMessage > > ^ MessageNotUnderstood new > message: aMessage; > receiver: self; > signal > Right, but you can't redefine and continue. The Object implementation does both. It used to only allow redefinition, not catching. > > 28 Ð¸ÑÐ»Ñ 2010 Ð³. 0:48:18 UTC+4 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ dionisiydk < > dionisiydk(a)gmail.com> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > > I think that the bug is that you haven't modified the system to quit on an >>> UnhandledException. i.e. in a headless context control should never get >>> back to the doesNotUnderstand: method if the MessageNotUnderstood exception >>> is not caught. How should one continue after an unhandled error? >>> >> >> With my approach I have "null object message eating" behavior. And when >> any unhandled errors raised in system user will see nothing. Only log file >> will contain it. >> >> 2010/7/28 Eliot Miranda <eliot.miranda(a)gmail.com> >> >>> >>> >>> 2010/7/27 Denis Kudriashov <dionisiydk(a)gmail.com> >>> >>> Hello, >>>> >>>> I found method doesNotUnderstand have very strange implementation >>>> >>>> Object>>doesNotUnderstand: aMessage >>>> | exception resumeValue | >>>> (exception := MessageNotUnderstood new) >>>> message: aMessage; >>>> receiver: self. >>>> resumeValue := exception signal. >>>> ^exception reachedDefaultHandler >>>> ifTrue: [aMessage sentTo: self] >>>> ifFalse: [resumeValue] >>>> >>>> When Error has no handlers #defaultAction is executed. For >>>> MessageNotUnderstood #defaultAction is UnhandledError signal. And for >>>> UnhandledError #defaultAction is opening debugger. >>>> If you change it to do nothing (^self) you get infinite loop on any >>>> MessageNotUnderstood signal. >>>> It is because "ifTrue" branch executed in doesNotUnderstood method and >>>> message resend to receiver. >>>> >>>> Why method implemented such way? Why it is differ from ProtoObject >>>> implementation. I think It's bug implementation. >>>> >>> >>> This is intentional. Martin's reply is one half of the issue, that you >>> want to be able to proceed after defining a method in the debugger. The >>> otehr half is that you want to be able to catch doesNotUnderstand: in an >>> exception handler and proceed with a result, e.g. >>> >>> [nil zork] >>> on: MessageNotUnderstood >>> do: [:ex| >>> ex message selector == #zork ifTrue: >>> [ex resume: #ok]. >>> ex pass] >>> >>> evaluates to #ok. >>> >>> >>>> >>>> I found this problem when I try implement stuff to turn off openning >>>> debugger on unhandled error (and write it to log) >>>> >>>> UnhandledError>>defaultAction >>>> "The current computation is terminated. The cause of the error >>>> should be logged or reported to the user. If the program is operating in an >>>> interactive debugging environment the computation should be suspended and >>>> the debugger activated." >>>> ^ToolSet debugError: exception. >>>> >>>> ToolSet class>>debugError: anError >>>> "Handle an otherwise unhandled error" >>>> self default ifNil:[ | ctx | >>>> Smalltalk >>>> logError: anError description >>>> inContext: (ctx := anError signalerContext) >>>> to: 'PharoDebug.log'. >>>> self inform: (anError description, String cr, ctx shortStack). >>>> ^anError return]. >>>> ^self default debugError: anError >>>> >>>> I just implement subclass of StandartToolSet with empty method >>>> #debugError:. Then I do "ToolSet default: MyToolSet". And now unhandled >>>> errors raise infinit loop and never return. >>>> >>>> I fix that by: >>>> >>>> MyToolSet>>debugError: anError >>>> anError class = MessageNotUnderstand ifTrue: [anError >>>> reachedDefaultHandler: true]. >>>> >>>> I think this is hack. But it is work. No errors show to user.And all >>>> work good. >>>> >>>> What do you think? >>>> >>> >>> I think that the bug is that you haven't modified the system to quit on >>> an UnhandledException. i.e. in a headless context control should never get >>> back to the doesNotUnderstand: method if the MessageNotUnderstood exception >>> is not caught. How should one continue after an unhandled error? >>> >>> HTH >>> Eliot >>> >>> >>>> Best regards, >>>> Denis >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >

July 27, 2010

Re: [Pharo-project] Object>>doesNotUnderstand:

by Denis Kudriashov

> > This is intentional. Martin's reply is one half of the issue, that you > want to be able to proceed after defining a method in the debugger. The > otehr half is that you want to be able to catch doesNotUnderstand: in an > exception handler and proceed with a result, e.g. > [nil zork] on: MessageNotUnderstood do: [:ex| ex message selector == #zork ifTrue: [ex resume: #ok]. ex pass] evaluates to #ok. This all work correct with ProtoObject implementation ProtoObject>>doesNotUnderstand: aMessage ^ MessageNotUnderstood new message: aMessage; receiver: self; signal 28 Ð¸ÑÐ»Ñ 2010 Ð³. 0:48:18 UTC+4 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ dionisiydk <dionisiydk(a)gmail.com>Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > I think that the bug is that you haven't modified the system to quit on an >> UnhandledException. i.e. in a headless context control should never get >> back to the doesNotUnderstand: method if the MessageNotUnderstood exception >> is not caught. How should one continue after an unhandled error? >> > > With my approach I have "null object message eating" behavior. And when any > unhandled errors raised in system user will see nothing. Only log file will > contain it. > > 2010/7/28 Eliot Miranda <eliot.miranda(a)gmail.com> > >> >> >> 2010/7/27 Denis Kudriashov <dionisiydk(a)gmail.com> >> >> Hello, >>> >>> I found method doesNotUnderstand have very strange implementation >>> >>> Object>>doesNotUnderstand: aMessage >>> | exception resumeValue | >>> (exception := MessageNotUnderstood new) >>> message: aMessage; >>> receiver: self. >>> resumeValue := exception signal. >>> ^exception reachedDefaultHandler >>> ifTrue: [aMessage sentTo: self] >>> ifFalse: [resumeValue] >>> >>> When Error has no handlers #defaultAction is executed. For >>> MessageNotUnderstood #defaultAction is UnhandledError signal. And for >>> UnhandledError #defaultAction is opening debugger. >>> If you change it to do nothing (^self) you get infinite loop on any >>> MessageNotUnderstood signal. >>> It is because "ifTrue" branch executed in doesNotUnderstood method and >>> message resend to receiver. >>> >>> Why method implemented such way? Why it is differ from ProtoObject >>> implementation. I think It's bug implementation. >>> >> >> This is intentional. Martin's reply is one half of the issue, that you >> want to be able to proceed after defining a method in the debugger. The >> otehr half is that you want to be able to catch doesNotUnderstand: in an >> exception handler and proceed with a result, e.g. >> >> [nil zork] >> on: MessageNotUnderstood >> do: [:ex| >> ex message selector == #zork ifTrue: >> [ex resume: #ok]. >> ex pass] >> >> evaluates to #ok. >> >> >>> >>> I found this problem when I try implement stuff to turn off openning >>> debugger on unhandled error (and write it to log) >>> >>> UnhandledError>>defaultAction >>> "The current computation is terminated. The cause of the error should >>> be logged or reported to the user. If the program is operating in an >>> interactive debugging environment the computation should be suspended and >>> the debugger activated." >>> ^ToolSet debugError: exception. >>> >>> ToolSet class>>debugError: anError >>> "Handle an otherwise unhandled error" >>> self default ifNil:[ | ctx | >>> Smalltalk >>> logError: anError description >>> inContext: (ctx := anError signalerContext) >>> to: 'PharoDebug.log'. >>> self inform: (anError description, String cr, ctx shortStack). >>> ^anError return]. >>> ^self default debugError: anError >>> >>> I just implement subclass of StandartToolSet with empty method >>> #debugError:. Then I do "ToolSet default: MyToolSet". And now unhandled >>> errors raise infinit loop and never return. >>> >>> I fix that by: >>> >>> MyToolSet>>debugError: anError >>> anError class = MessageNotUnderstand ifTrue: [anError >>> reachedDefaultHandler: true]. >>> >>> I think this is hack. But it is work. No errors show to user.And all work >>> good. >>> >>> What do you think? >>> >> >> I think that the bug is that you haven't modified the system to quit on an >> UnhandledException. i.e. in a headless context control should never get >> back to the doesNotUnderstand: method if the MessageNotUnderstood exception >> is not caught. How should one continue after an unhandled error? >> >> HTH >> Eliot >> >> >>> Best regards, >>> Denis >>> >>> >>> >>> _______________________________________________ >>> 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 >> > >

July 27, 2010

Re: [Pharo-project] Object>>doesNotUnderstand:

by Eliot Miranda

2010/7/27 Denis Kudriashov <dionisiydk(a)gmail.com> > I think that the bug is that you haven't modified the system to quit on an >> UnhandledException. i.e. in a headless context control should never get >> back to the doesNotUnderstand: method if the MessageNotUnderstood exception >> is not caught. How should one continue after an unhandled error? >> > > With my approach I have "null object message eating" behavior. And when any > unhandled errors raised in system user will see nothing. Only log file will > contain it. > In either case control should not return to the point of error. If you want to log errors and then continue you need to continue from some well-defined point, not merely return control to the point of error. So if your approach is to catch and log errors, after logging you need to transfer control back to some starting point, e.g. by throwing some ResumeExecution exception. HTH Eliot > 2010/7/28 Eliot Miranda <eliot.miranda(a)gmail.com> > > >> >> 2010/7/27 Denis Kudriashov <dionisiydk(a)gmail.com> >> >> Hello, >>> >>> I found method doesNotUnderstand have very strange implementation >>> >>> Object>>doesNotUnderstand: aMessage >>> | exception resumeValue | >>> (exception := MessageNotUnderstood new) >>> message: aMessage; >>> receiver: self. >>> resumeValue := exception signal. >>> ^exception reachedDefaultHandler >>> ifTrue: [aMessage sentTo: self] >>> ifFalse: [resumeValue] >>> >>> When Error has no handlers #defaultAction is executed. For >>> MessageNotUnderstood #defaultAction is UnhandledError signal. And for >>> UnhandledError #defaultAction is opening debugger. >>> If you change it to do nothing (^self) you get infinite loop on any >>> MessageNotUnderstood signal. >>> It is because "ifTrue" branch executed in doesNotUnderstood method and >>> message resend to receiver. >>> >>> Why method implemented such way? Why it is differ from ProtoObject >>> implementation. I think It's bug implementation. >>> >> >> This is intentional. Martin's reply is one half of the issue, that you >> want to be able to proceed after defining a method in the debugger. The >> otehr half is that you want to be able to catch doesNotUnderstand: in an >> exception handler and proceed with a result, e.g. >> >> [nil zork] >> on: MessageNotUnderstood >> do: [:ex| >> ex message selector == #zork ifTrue: >> [ex resume: #ok]. >> ex pass] >> >> evaluates to #ok. >> >> >>> >>> I found this problem when I try implement stuff to turn off openning >>> debugger on unhandled error (and write it to log) >>> >>> UnhandledError>>defaultAction >>> "The current computation is terminated. The cause of the error should >>> be logged or reported to the user. If the program is operating in an >>> interactive debugging environment the computation should be suspended and >>> the debugger activated." >>> ^ToolSet debugError: exception. >>> >>> ToolSet class>>debugError: anError >>> "Handle an otherwise unhandled error" >>> self default ifNil:[ | ctx | >>> Smalltalk >>> logError: anError description >>> inContext: (ctx := anError signalerContext) >>> to: 'PharoDebug.log'. >>> self inform: (anError description, String cr, ctx shortStack). >>> ^anError return]. >>> ^self default debugError: anError >>> >>> I just implement subclass of StandartToolSet with empty method >>> #debugError:. Then I do "ToolSet default: MyToolSet". And now unhandled >>> errors raise infinit loop and never return. >>> >>> I fix that by: >>> >>> MyToolSet>>debugError: anError >>> anError class = MessageNotUnderstand ifTrue: [anError >>> reachedDefaultHandler: true]. >>> >>> I think this is hack. But it is work. No errors show to user.And all work >>> good. >>> >>> What do you think? >>> >> >> I think that the bug is that you haven't modified the system to quit on an >> UnhandledException. i.e. in a headless context control should never get >> back to the doesNotUnderstand: method if the MessageNotUnderstood exception >> is not caught. How should one continue after an unhandled error? >> >> HTH >> Eliot >> >> >>> Best regards, >>> Denis >>> >>> >>> >>> _______________________________________________ >>> 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 >

July 27, 2010