September 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Building a run loop that can continue after an unhanded exception

by Henrik Sperre Johansen

On 07.09.2012 10:17, Joe Rickerby wrote: > Hi all, > > I'm having a problem trying to build a run loop. If an exception is > signalled within one of the run loop tasks, the exception escapes > through the loop and terminates the process. > > I know I can catch the exception, and do something like print the > message on the Transcript, but I was hoping to build something that > was more helpful in development, allowing me to look through the > stack, but if I press 'abandon' on that dialog, the run loop would > continue from where I caught the exception. > > Isn't that exactly what happens if you don't handle the error, and use the proceed button in (pre and normal) debugger windows? Cheers, Henry

Sept. 7, 2012

[Pharo-project] Building a run loop that can continue after an unhanded exception

by Joe Rickerby

Hi all, I'm having a problem trying to build a run loop. If an exception is signalled within one of the run loop tasks, the exception escapes through the loop and terminates the process. I know I can catch the exception, and do something like print the message on the Transcript, but I was hoping to build something that was more helpful in development, allowing me to look through the stack, but if I press 'abandon' on that dialog, the run loop would continue from where I caught the exception. The code: startRunLoop self stopRunLoop. self runLoop: ( [ [ self doTimedTasks ] on: Exception do: [ :err | " show the exception notifier " ] ] repeatEvery: 0.1 seconds named: 'BrTimeline run loop' ) where repeatEvery:named: is implemented as such: repeatEvery: aDuration named: aProcessName ^ [ [ self value. aDuration asDelay wait ] repeat ] forkNamed: aProcessName Thanks, Joe

Sept. 7, 2012

Re: [Pharo-project] Building a run loop that can continue after an unhanded exception

by Mariano Martinez Peck

On Fri, Sep 7, 2012 at 10:17 AM, Joe Rickerby <joe.rickerby(a)square-i.net>wrote: > Hi all, > > I'm having a problem trying to build a run loop. If an exception is > signalled within one of the run loop tasks, the exception escapes through > the loop and terminates the process. > > I know I can catch the exception, and do something like print the > message on the Transcript, but I was hoping to build something that was > more helpful in development, allowing me to look through the stack, but if > I press 'abandon' on that dialog, the run loop would continue from where I > caught the exception. > > Try with Exception >> #resume > The code: > > *startRunLoop* > self stopRunLoop. > self runLoop: ( > [ [ self doTimedTasks ] > on: Exception > do: [ :err | " show the exception notifier " > err resume > ] ] > repeatEvery: 0.1 seconds named: 'BrTimeline run loop' ) > > where repeatEvery:named: is implemented as such: > > *repeatEvery:* aDuration *named:* aProcessName > ^ [ [ self value. > aDuration asDelay wait ] repeat ] forkNamed: aProcessName > > Thanks, > Joe > > -- Mariano http://marianopeck.wordpress.com

Sept. 7, 2012

Re: [Pharo-project] nil key in last literal in instance side methods (reproducible)

by Camillo Bruni

On 2012-09-06, at 22:26, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2012/9/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> On Thu, Sep 6, 2012 at 9:45 PM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> A bot providing simple diffs would help more eyes reviewing code... >>> By now this important work is restricted to a narrow team of busy >>> active developpers. >>> Of course, CI may help a bit, but monkeys don't read code they just >>> evaluate it. >>> >> >> I am not sure if the changes in this slice are important. I think it just >> happens that for certain reason, we have this problem of the last literal. >> > > I just can't tell if it would help or not, without diff I'm totally blind ;) > But sure, a correct code can uncover a bug elsewhere... Sorry I don't get it? where do you want a diff? on the google code website? -> we thought once about writing an external website doing that - list the changes - list the results from code review - list the test results basically each bugfix should result in a "review" image which can be downloaded and checked... but then again, somebody has to write it...

Sept. 7, 2012

Re: [Pharo-project] Who broke UTF8TextConverter?

by phil＠highoctane.be

Ah, I love when a project has a Soul. What a great initiative to be part of. I feel rejuvenated every time I work with Pharo :-) [Seems we'll need a philosophical page one of these days, or we can do that in the vein of venerable C2: http://c2.com/cgi/wiki?SmalltalkLanguage] Pharo is here: http://c2.com/cgi/wiki?PharoSmalltalk Phil 2012/9/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Yes ! > > >> Pharo manifesto > >> - Better for the better > >> - Beauty to learn from > >> - Not backward compatible *** > >> - Clean, lean and fast > >> > > > > Every wtf we leave in the system limits the human expression of ourselves > > and our users. For one thing, aesthetics count. Emotions are hugely > > important to the quality of one's work, and unless we are all inspired > by a > > beautiful system, our discontent will be reflected in code written in > and on > > top of Pharo. Also, while crusty old Pharo wizards may know where all > these > > little land mines are that must be avoided, new users may waste > hours/days > > before finding out that things don't work the way one would naturally > expect > > them too. > > > > If we can operate on RPackage in a live system, breaking code committing > and > > loading, we can change *anything*. I've definitely felt the pain in 2.0, > but > > this is what we're working for. Let's rip the bandaid off and have the > > system of our dreams. If anything, I believe the question should *never* > be > > "do we leave this crap in the system or not?", but merely "how do we ease > > the pain of making this better?", whether via deprecations, RB > > transformations, or whatever; and we seem to be making steady progress on > > that front. > > > > > > > > -- > > View this message in context: > http://forum.world.st/Who-broke-UTF8TextConverter-tp4645473p4646399.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > >

Sept. 7, 2012

Re: [Pharo-project] nil key in last literal in instance side methods (reproducible)

by StÃ©phane Ducasse

thanks to raise this issue again. So what concretely do you think would help? Emitting a diff? and sending it to the mailing-list stef On Sep 6, 2012, at 9:45 PM, Nicolas Cellier wrote: > A bot providing simple diffs would help more eyes reviewing code... > By now this important work is restricted to a narrow team of busy > active developpers. > Of course, CI may help a bit, but monkeys don't read code they just evaluate it. > > Nicolas > > 2012/9/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Hi guys. So we have a case where we can reproduce the problem. See >> http://code.google.com/p/pharo/issues/detail?id=6644 >> >> If you take a Pharo 20274 and load this slice: >> SLICE-Issue-6635-Removing-class-does-not-remove-class-tag-CamilloBruni.1 , >> the #testInstanceSideMethodsWithNilKeyInLastLiteral starts to fail and we >> have lots of instance side methods with nil in the last literal (in fact, >> from the package that the slide installs). >> I tried to debug the #basicLoad and MC friends to see if I come to the real >> problem but no luck so far. >> If anyone wants to take a look, it would be great since I think this is a >> really important bug. >> >> Thanks, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

Sept. 7, 2012

Re: [Pharo-project] Who broke UTF8TextConverter?

by StÃ©phane Ducasse

Yes ! >> Pharo manifesto >> - Better for the better >> - Beauty to learn from >> - Not backward compatible *** >> - Clean, lean and fast >> > > Every wtf we leave in the system limits the human expression of ourselves > and our users. For one thing, aesthetics count. Emotions are hugely > important to the quality of one's work, and unless we are all inspired by a > beautiful system, our discontent will be reflected in code written in and on > top of Pharo. Also, while crusty old Pharo wizards may know where all these > little land mines are that must be avoided, new users may waste hours/days > before finding out that things don't work the way one would naturally expect > them too. > > If we can operate on RPackage in a live system, breaking code committing and > loading, we can change *anything*. I've definitely felt the pain in 2.0, but > this is what we're working for. Let's rip the bandaid off and have the > system of our dreams. If anything, I believe the question should *never* be > "do we leave this crap in the system or not?", but merely "how do we ease > the pain of making this better?", whether via deprecations, RB > transformations, or whatever; and we seem to be making steady progress on > that front. > > > > -- > View this message in context: http://forum.world.st/Who-broke-UTF8TextConverter-tp4645473p4646399.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Sept. 7, 2012

Re: [Pharo-project] nil key in last literal in instance side methods (reproducible)

by Nicolas Cellier

2012/9/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Thu, Sep 6, 2012 at 9:45 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> A bot providing simple diffs would help more eyes reviewing code... >> By now this important work is restricted to a narrow team of busy >> active developpers. >> Of course, CI may help a bit, but monkeys don't read code they just >> evaluate it. >> > > I am not sure if the changes in this slice are important. I think it just > happens that for certain reason, we have this problem of the last literal. > I just can't tell if it would help or not, without diff I'm totally blind ;) But sure, a correct code can uncover a bug elsewhere... >> >> Nicolas >> >> 2012/9/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > Hi guys. So we have a case where we can reproduce the problem. See >> > http://code.google.com/p/pharo/issues/detail?id=6644 >> > >> > If you take a Pharo 20274 and load this slice: >> > SLICE-Issue-6635-Removing-class-does-not-remove-class-tag-CamilloBruni.1 >> > , >> > the #testInstanceSideMethodsWithNilKeyInLastLiteral starts to fail and >> > we >> > have lots of instance side methods with nil in the last literal (in >> > fact, >> > from the package that the slide installs). >> > I tried to debug the #basicLoad and MC friends to see if I come to the >> > real >> > problem but no luck so far. >> > If anyone wants to take a look, it would be great since I think this is >> > a >> > really important bug. >> > >> > Thanks, >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > > > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 6, 2012

Re: [Pharo-project] nil key in last literal in instance side methods (reproducible)

by Mariano Martinez Peck

On Thu, Sep 6, 2012 at 9:45 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > A bot providing simple diffs would help more eyes reviewing code... > By now this important work is restricted to a narrow team of busy > active developpers. > Of course, CI may help a bit, but monkeys don't read code they just > evaluate it. > > I am not sure if the changes in this slice are important. I think it just happens that for certain reason, we have this problem of the last literal. > Nicolas > > 2012/9/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi guys. So we have a case where we can reproduce the problem. See > > http://code.google.com/p/pharo/issues/detail?id=6644 > > > > If you take a Pharo 20274 and load this slice: > > SLICE-Issue-6635-Removing-class-does-not-remove-class-tag-CamilloBruni.1 > , > > the #testInstanceSideMethodsWithNilKeyInLastLiteral starts to fail and > we > > have lots of instance side methods with nil in the last literal (in fact, > > from the package that the slide installs). > > I tried to debug the #basicLoad and MC friends to see if I come to the > real > > problem but no luck so far. > > If anyone wants to take a look, it would be great since I think this is a > > really important bug. > > > > Thanks, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 6, 2012

Re: [Pharo-project] FFI & Python

by Igor Stasenko

On 6 September 2012 00:58, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: > Hi all! > > I'm currently working in a project related with ROS (robot operative > system), which already have a library to develop in C++ and other to do the > same at Python. So, there a lot of variables to contrast to make a choice > (performance, code-easy-to-prototype, flexibility, and a lot more), but the > main variable is the accessibility from Pharo, then the question is, is > there any project that use python from pharo? Or, if i select python i > should write a library in C that bootstrap python and give access to pharo > via FFI? > C++ or C? If it C you can use FFI to speak with. > I looked in the list's mails and in google without any success. > > Thanks in advance! > > Santiago. > -- Best regards, Igor Stasenko.

Sept. 6, 2012