- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Fancier Debugger

by Bernat Romagosa

I'd use it :) 2011/7/18 Camillo Bruni <camillo.bruni(a)inria.fr> > 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 > -- Bernat Romagosa.

July 18, 2011

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

by Philippe Marschall

On 07/17/2011 08:26 PM, StÃ©phane Ducasse wrote: > Hi lukas > > in 1.3 we introduced on:fork: to ensure that for example a system announcement is processed even if a user announcement would break for the same registry. Every time you try to be clever you introduce new problems, so don't try to be clever. The only way to fix broken code is to fix broken code, not by adding additional hacks. Cheers Philippe

July 18, 2011

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

by Michael Roberts

is MyClass a domain class or a (unit) test class? thanks, Mike On Sun, Jul 17, 2011 at 10:45 PM, Sean P. DeNigris <sean(a)clipperadams.com> 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

[Pharo-project] Fancier Debugger

by Camillo Bruni

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 17, 2011