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

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by StÃ©phane Ducasse

I think that the solution is to not catch exception but Unhandled ones. Stef On Jul 18, 2011, at 11:13 AM, Bernat Romagosa wrote: > Hi, > > I am having the exact same problem with an Iliad app, which stopped working in 1.3 because it loses the context when catching an announcement. I'd really love to know the solution to this, in the Iliad list we didn't manage to fix it. > > Cheers, > > 2011/7/18 Norbert Hartl <norbert(a)hartl.name> > > Am 17.07.2011 um 22:06 schrieb StÃ©phane Ducasse: > > >> It is just that everybody should be aware of the problem and have its own "simple" > >> announcements when using any of the frameworks above. > > > > you know that this is not the good solution. So probably it was a bad idea to catch > > everything and probably UnhandledError is a better choice. > > Now again without feedback we will just progress but much slower. > > Why is the usage of on:fork: not an option of the Announcer? We don't have one single Announcer in the system so I don't see the need why they should behave all the same. Over time I think there will be multiple announcers in the system that have different impact in case something goes wrong. For the core announcers on:fork: is probably a good idea to preserve consistency in the system. > For the rest it may be better to preserve stack to be able to debug and to reduce side effects. I think on:fork is targetted to an edge case so it should not be the default. > > my 2 cents, > > Norbert > > > > -- > Bernat Romagosa.

July 18, 2011

Re: [Pharo-project] Fancier Debugger

by StÃ©phane Ducasse

You should show us a demo :) Any improvement is welcome. On Jul 18, 2011, at 12:56 AM, Camillo Bruni wrote: > Hi everyone, > > last friday I spent some 20mins on improving the debugging experience (at least for me) by doing to following: > > - removed many "core" message sends from the context stack in the debugger > - automatically expand the context stack if the last stackframe is selected > > For the first task I added a method which filters out all message sends which IMO are mostly uninteresting when debugging (right now still a but dirty implemented..): > > - #ifTrue: #ifFalse.... and so forth > - iteration internals on Collections: #do: > - Message sends to Blocks / MethodContexts: #on:do: #value: ... > - Basic accessors on dicts: #at: #at:put: .... > > at least for me this helps me incredibly with locating important pieces of code in the debugger e.g. reducing the noise.. > > > So is there any interest in this to be added? (of course with a settings switch to turn it on/off... in case you work on the filtered messages) > > If so I will implement it a bit cleaner and add a decent settings entry... > > cami

July 18, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by Henrik Sperre Johansen

Another problem with the fork not mentioned yet, is the assumption all subscriber actions will have been carried out by the time next statement occurs. fork:'ing breaks that, and you can't make the assumption true without conflicting with the reason to fork: in the first place. Another argument in favor of only forking on unhandled exceptions I guess :) @#after: gripe in previous post: meh, ansi... -- View this message in context: http://forum.world.st/Problem-with-announcements-in-Seaside-when-using-Phar… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 18, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by Henrik Sperre Johansen

StÃ©phane Ducasse wrote: > > We will think hard and see what is a reasonable solution. > What we want is the garantee that announcements are processed, that UI > continue to work even if a piece of code break part of it, same for event > handling. > > Lukas suggestion of changing it to fork on UnhandledErrors is a perfectly reasonable solution. In case handlers outside the delivery mechanism itself don't resume, well, the ifCurtailed: block of deliver:to: takes care of delivery to the remaining subscriptions. :) (except there's a bug when asking for after: of last element... ifAbsent: block used _both_ when element not found, AND when there are none after it??) You can still break it though, by using a handler which enters an infinite loop/sleep forever, etc... I agree with Phillipe: "The only way to fix broken code is to fix broken code, not by adding additional hacks.". Robustness is desirable, but only to a certain extent. (IE guard against unforeseen errors, not those handled incorrectly) As for Lukas' concerns not addressed by switching to UnhandledError: In my experience when using announcements in VW, relying on delivery order of announcements isasking for trouble later on... The code paths get hard to follow, maintainability becomes a nightmare as adding new subscribers/modifying old ones might introduce subtle bugs, etc. For the use case you described in OB, why not split it into two announcements instead, the first one vetoable in the sense Vassily wrote about in the blog, and the second announced only if first not vetoed? Cheers, Henry -- View this message in context: http://forum.world.st/Problem-with-announcements-in-Seaside-when-using-Phar… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 18, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by Danie Roux

Hi Bernat, Until Pharo sorts our how they are going to fix it, we fixed it by overriding two methods. Also see this emial to the Pharo mailing list (that went nowhere): http://lists.gforge.inria.fr/pipermail/pharo-project/2011-July/051094.html AnnouncementSubscription>>deliver: anAnnouncement " Overridden code has a fork in here. Not good." ^ (self handles: anAnnouncement class) ifTrue: [ action cull: anAnnouncement cull: announcer ] SubscriptionRegistry>>deliver: anAnnouncement to: subs subs do: [ :each | each deliver: anAnnouncement ] On Mon, Jul 18, 2011 at 11:13 AM, Bernat Romagosa < tibabenfortlapalanca(a)gmail.com> wrote: > Hi, > > I am having the exact same problem with an Iliad app, which stopped working > in 1.3 because it loses the context when catching an announcement. I'd > really love to know the solution to this, in the Iliad list we didn't manage > to fix it. > > Cheers, > > 2011/7/18 Norbert Hartl <norbert(a)hartl.name> > >> >> Am 17.07.2011 um 22:06 schrieb StÃ©phane Ducasse: >> >> >> It is just that everybody should be aware of the problem and have its >> own "simple" >> >> announcements when using any of the frameworks above. >> > >> > you know that this is not the good solution. So probably it was a bad >> idea to catch >> > everything and probably UnhandledError is a better choice. >> > Now again without feedback we will just progress but much slower. >> >> Why is the usage of on:fork: not an option of the Announcer? We don't have >> one single Announcer in the system so I don't see the need why they should >> behave all the same. Over time I think there will be multiple announcers in >> the system that have different impact in case something goes wrong. For the >> core announcers on:fork: is probably a good idea to preserve consistency in >> the system. >> For the rest it may be better to preserve stack to be able to debug and to >> reduce side effects. I think on:fork is targetted to an edge case so it >> should not be the default. >> >> my 2 cents, >> >> Norbert >> > > > > -- > Bernat Romagosa. > -- Danie Roux *shuffle* Adore Unix - http://danieroux.com Email / Google Talk / Jabber - danie(a)danieroux.com

July 18, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by Bernat Romagosa

Hi, I am having the exact same problem with an Iliad app, which stopped working in 1.3 because it loses the context when catching an announcement. I'd really love to know the solution to this, in the Iliad list we didn't manage to fix it. Cheers, 2011/7/18 Norbert Hartl <norbert(a)hartl.name> > > Am 17.07.2011 um 22:06 schrieb StÃ©phane Ducasse: > > >> It is just that everybody should be aware of the problem and have its > own "simple" > >> announcements when using any of the frameworks above. > > > > you know that this is not the good solution. So probably it was a bad > idea to catch > > everything and probably UnhandledError is a better choice. > > Now again without feedback we will just progress but much slower. > > Why is the usage of on:fork: not an option of the Announcer? We don't have > one single Announcer in the system so I don't see the need why they should > behave all the same. Over time I think there will be multiple announcers in > the system that have different impact in case something goes wrong. For the > core announcers on:fork: is probably a good idea to preserve consistency in > the system. > For the rest it may be better to preserve stack to be able to debug and to > reduce side effects. I think on:fork is targetted to an edge case so it > should not be the default. > > my 2 cents, > > Norbert > -- Bernat Romagosa.

July 18, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by Norbert Hartl

Am 17.07.2011 um 22:06 schrieb StÃ©phane Ducasse: >> It is just that everybody should be aware of the problem and have its own "simple" >> announcements when using any of the frameworks above. > > you know that this is not the good solution. So probably it was a bad idea to catch > everything and probably UnhandledError is a better choice. > Now again without feedback we will just progress but much slower. Why is the usage of on:fork: not an option of the Announcer? We don't have one single Announcer in the system so I don't see the need why they should behave all the same. Over time I think there will be multiple announcers in the system that have different impact in case something goes wrong. For the core announcers on:fork: is probably a good idea to preserve consistency in the system. For the rest it may be better to preserve stack to be able to debug and to reduce side effects. I think on:fork is targetted to an edge case so it should not be the default. my 2 cents, Norbert

July 18, 2011

Re: [Pharo-project] Stubbing class-side methods

by Carlo

Personally when I come across cases like this I either break the (usually public) method into a public and internal method, the internal method contains the date so we can test the edge cases. E.g. MyClass>> doSomethingWorthTesting ... basicDoSomethingWorthTestingAt: DateAndTime now. ... My test then uses the internal method for testing where I can pass in different dates. Another option which you've probably decided against is to delegate to your current class or a Registry to ask for the class with which to use for date related tasks, a kind of factory in a way. MyClass>>>> doSomethingWorthTesting ... now := self class dateClass now. ... I personally feel Pharo is moving into a more pluggable direction with the work on the environment (Smalltalk environment) where we can provide our own environment for a particular context, something similar to Newspeaks nested classes and imports using the usingPlatform: construct. E.g. class MyClassModule usingPlatform: platform = ( private DateAndTime = platform time DateAndTime. private Error = platform exceptions Error. ) Hmm maybe we can do a lightweight version using DynamicBindling library myEnvironmentBinding bindDuring: [ ...your testcase... ] Cheers Carlo On 17 Jul 2011, at 11:45 PM, Sean P. DeNigris wrote: I keep coming up against this situation over and over in testing. MyClass>>doSomethingWorthTesting ... now := DateAndTime now. ... I want to control DateAndTime class>>now to make this test determinate and simulate interesting edge cases, but can't figure out a good way. In Ruby, I could easily stub it because it's not a live system (or use dependency injection), but here I don't want to mess with the real DateAndTime class in case something goes wrong and leaves my system dirty. I really hate using dependency injection for this kind of thing (especially without Ruby's default parameter values). I've been creating MyClass>>now and stubbing that. Am I being paranoid, should I just hijack the real class and fix it when I'm done? What's the best way to do this? Thanks. Sean -- View this message in context: http://forum.world.st/Stubbing-class-side-methods-tp3674065p3674065.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 18, 2011

Re: [Pharo-project] Fancier Debugger

by Damien Cassou

Dear Camillo, On Mon, Jul 18, 2011 at 12:56 AM, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > So is there any interest in this to be added? (of course with a settings switch to turn it on/off... in case you work on the filtered messages) that would be an awesome addition, please have it integrated. Also, if you have some expertise in the debugger, Doru would certainly appreciate some help in separating the model from the UI code. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 18, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by Damien Cassou

On Mon, Jul 18, 2011 at 9:01 AM, Philippe Marschall <philippe.marschall(a)netcetera.ch> wrote: > The only way to fix broken code is to fix broken code, not by adding > additional hacks. I do appreciate all the efforts of the development team. Please go on, try new ideas, and if they don't work you will still have time to revert them. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 18, 2011