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

Re: [Pharo-project] About testing that ensure works

by Henrik Sperre Johansen

On 26.04.2011 17:37, Igor Stasenko wrote: > On 26 April 2011 15:11, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 24.04.2011 12:05, StÃ©phane Ducasse wrote: >>>> i am puzzled. You wanna to be sure that ensure block are executed? >>>> It is. >>> I want to write a test that shows and tests the withOrganizer:do: >>> semantics. >>> In particular that the ensure is executed and that the context set by the >>> withOrganizer: is only present >>> in the do: block. >>> >> In other words, another use case probably written more cleanly using the >> non-existing >> Announcer>> #suspend: subscriber while: aBlock >> > What is potential implementation? > > Announcer>>suspend: subscriber while: aBlock > | subscriptions | > > subscriptions := OrderedCollection new. > > registry subscriptionsOf: subscriber do: [:each | > subscriptions add: each > ]. > registry removeSubscriber: subscriber. > > ^ aBlock ensure: [ subscriptions do: [:ea | registry add: ea ] ] > > > The problem is that its not doing exactly what is said: > - it suspends existing subscriptions instead of suspending subscriber. > > The difference between those are subtle but important: > a suspended subscriber should not receive any announcements during > block evaluation, > even if it may want to subscribe to new ones during given block evaluation. > And the code above not handling this case , as well as it doesn't > handling the case when subscriber may want > to occasionally unsubscribe from some announcements during block evaluation. > > So, for doing this correctly, a subscription registry should keep a > list of suspended subscribers somewhere, > and then in #deliver: > it should check if subscription's subscriber are not in that list, and > only then let it deliver an announcement. > > The problem is that delivery time will slowdown considerably, because > for every subscription you should check > if it's subscriber are not in 'suspended subscribers' list. > > > So, it is really depends on intent. Suspending a concrete subscription > will require adding 'suspended' flag to subscription state. > But suspending a concrete subscriber and to guarantee that it won't > receive any announcements (even if it will subscribe for > a new ones during suspension time), can't be solved by having > 'suspended' ivar on subscription. You have to manage suspended > subscribers list separately. > That'a a rather farfetched usecase it'd be nice to note in a method comment is NOT supported at the moment, nothing more imho :) Simply providing something like: suspend(SubscriptionsOf): subscriber while: aBlock |oldSubs| oldSubs := subscriptionRegistry removeSubscriber: subscriber. aBlock ensure: [oldSubs do: [ :each | subscriptionRegistry add: each]] is better than nothing. Cheers, Henry

April 26, 2011

Re: [Pharo-project] What is a well documented class?

by StÃ©phane Ducasse

I did not imply anything special. I just remember when lukas started to write comments on seaside while I was driving on the high way to Nice. I said ok let us start :) But I regularly got burned by comments absence and I spend time writing them because I like when the code tell: stef you are so smart, you guess well what I'm doing. Because comments are about reinforcement of hypothesis. Stef > > StÃ©phane Ducasse wrote: >> >> >> yes but.... let us write more comments. >> All the rest is arguments not to write them which is far easier as usual. >> >> Stef >> > > Absolutely. Sorry, I didn't mean to imply otherwise. > > Mike > > -- > View this message in context: http://forum.world.st/What-is-a-well-documented-class-tp3470956p3475730.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 26, 2011

Re: [Pharo-project] Hudson version 2.0 is available

by Henrik Sperre Johansen

On 26.04.2011 17:32, DougEdmunds wrote: > Pharo is being developed on a Hudson 1.358 server (2010/05/14). > Hudson has recently released version 2.0 (2011/04/21). > http://hudson-ci.org/ > > -- > View this message in context: http://forum.world.st/Hudson-version-2-0-is-available-tp3475761p3475761.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > Takes some time to get INRIA operations to approve and do installation of new versions apparently :) Anyways, I suspect the next installed version will be of Jenkins, not Hudson. Cheers, Henrt

April 26, 2011

Re: [Pharo-project] About testing that ensure works

by Igor Stasenko

On 26 April 2011 15:11, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 24.04.2011 12:05, StÃ©phane Ducasse wrote: >>> >>> i am puzzled. You wanna to be sure that ensure block are executed? >>> It is. >> >> I want to write a test that shows and tests the withOrganizer:do: >> semantics. >> In particular that the ensure is executed and that the context set by the >> withOrganizer: is only present >> in the do: block. >> > In other words, another use case probably written more cleanly using the > non-existing > Announcer >> #suspend: subscriber while: aBlock > What is potential implementation? Announcer >>suspend: subscriber while: aBlock | subscriptions | subscriptions := OrderedCollection new. registry subscriptionsOf: subscriber do: [:each | subscriptions add: each ]. registry removeSubscriber: subscriber. ^ aBlock ensure: [ subscriptions do: [:ea | registry add: ea ] ] The problem is that its not doing exactly what is said: - it suspends existing subscriptions instead of suspending subscriber. The difference between those are subtle but important: a suspended subscriber should not receive any announcements during block evaluation, even if it may want to subscribe to new ones during given block evaluation. And the code above not handling this case , as well as it doesn't handling the case when subscriber may want to occasionally unsubscribe from some announcements during block evaluation. So, for doing this correctly, a subscription registry should keep a list of suspended subscribers somewhere, and then in #deliver: it should check if subscription's subscriber are not in that list, and only then let it deliver an announcement. The problem is that delivery time will slowdown considerably, because for every subscription you should check if it's subscriber are not in 'suspended subscribers' list. So, it is really depends on intent. Suspending a concrete subscription will require adding 'suspended' flag to subscription state. But suspending a concrete subscriber and to guarantee that it won't receive any announcements (even if it will subscribe for a new ones during suspension time), can't be solved by having 'suspended' ivar on subscription. You have to manage suspended subscribers list separately. -- Best regards, Igor Stasenko AKA sig.

April 26, 2011

[Pharo-project] Hudson version 2.0 is available

by DougEdmunds

Pharo is being developed on a Hudson 1.358 server (2010/05/14). Hudson has recently released version 2.0 (2011/04/21). http://hudson-ci.org/ -- View this message in context: http://forum.world.st/Hudson-version-2-0-is-available-tp3475761p3475761.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 26, 2011

Re: [Pharo-project] What is a well documented class?

by Michael J. Forster

StÃ©phane Ducasse wrote: > > > yes but.... let us write more comments. > All the rest is arguments not to write them which is far easier as usual. > > Stef > Absolutely. Sorry, I didn't mean to imply otherwise. Mike -- View this message in context: http://forum.world.st/What-is-a-well-documented-class-tp3470956p3475730.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 26, 2011

Re: [Pharo-project] Better debugging...

by Toon Verwaest

> I am not sure if I understood correctly, but you may want to take a > look to Gemstone. As far as I remember they can have not only > different versions of a certain class at the same time, but also > instances of a specific class version all living together at the same > time. Thanks for the pointer, but yeah, I know about Gemstone. Our ideas are slightly different however... The idea is more to have multiple versions of the same live instance at the same time in memory; depending on the version of the code they are related to. This threads running in different versions can look at the same instances but have a slightly different view on the object graph. The only objects that will have different versions are global objects, hence the thread-local pools to avoid overhead when unnecessary. Then since threads are related to versions, we would have different heaps for the different versions of the global space. For example in the case of the alias debugger, the debugger has a view on the world that is completely aliased. Its version of the heap will look like that. The rest of the code would however immediately break if it would access the global state in that format since the alias-wrappers are unexpected. So we have 2 versions of the global heap, 1 with aliases and 1 without. For further reading, look at Erwann's active context. cheers, Toon

April 26, 2011

Re: [Pharo-project] Better debugging...

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 1:54 PM, Toon Verwaest <toon.verwaest(a)gmail.com>wrote: > I'm working on porting this idea already to the Glamour debugger. > > The idea is basically to use meta-circular interpreters as a way to specify > what semantics you want, but for speed reasons you might want to flatten out > the interpretation by combining both. This however should all be done behind > the scenes, independent of the definition of the debugger. > > More elaborate debuggers such as the alias debugger can be implemented but > there's no good way yet to separate the data spaces involved. That's where > me and Erwann are looking at how to maybe use a GC that can run multiple > different versions code at the same time while synchronizing the shared data > between the versions of the code. > I am not sure if I understood correctly, but you may want to take a look to Gemstone. As far as I remember they can have not only different versions of a certain class at the same time, but also instances of a specific class version all living together at the same time. > For example in the case of the alias debugger, that needs aliases > everwhere; but all the global data (classes, methods, ...) is not aliased. > To make this work you actually want to have a "copy" of the global data that > is aliased, but kept in sync with the original data. Here it starts making a > lot of sense to have thread-local heaps + a versioned but synced global > heap. > > Of course that's all still wishful thinking... step by step :) > > cheers, > Toon > > > On 04/25/2011 11:29 PM, Camillo Bruni wrote: > >> I think a nice way to have a decent debugger is to run the program on top >> of a changeable interpreter. Since a classical debugger is nothing else but >> an interpreter with slightly changed semantics. >> >> The object flow VM does a great job at tracing back stuff.. however it >> might pose a massive overhead since it collects tons and tons of data. >> >> In Pinocchio[1] we implemented very nice and simple debuggers by "just" >> changing the current interpreter to take a user-action into account on each >> message send. Since this is implemented on top of a metacircular interpreter >> this was quite simple to achieve. So the whole implementation of the known >> debugger functionality (step, over...) maybe took an afternoon. Since you >> have access to the full interpreter protocol it is very easy to intercept >> different sorts of actions. As described in the linked paper, it was very >> easy to implement the object-flow behavior in Pinocchio. >> >> So for me there is only one real way to have a decent debugger. And that >> means that it is a first-class interpreter whose semantics I can change at >> will. Thus I can create a specific debugger for my applications. >> >> But I guess that making the first-class interpreters work right away in >> Pharo will take a while to do, hence I propose the following additions to >> the current interpreter to make it partly useable: >> >> - interception of message sends >> - per thread [ok] >> - of specific classes [missing] >> - of specific instances [missing] >> >> - interception of instance variable access, read/write >> - per thread [missing] >> - of specific classes [missing] >> - of specific instances [missing] >> - of specific instance variables [missing] >> >> Furthermore I really want to be able to script all of that stuff, eg. >> provide a simple test block that gets invoked on each message send. >> Returning true => halt, Returning false => continue execution. >> >> >> [1] http://scg.unibe.ch/archive/papers/Verw10aPinocchio.pdf >> > > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

Re: [Pharo-project] Henrik should we include Settings-Sound ?

by StÃ©phane Ducasse

On Apr 26, 2011, at 3:32 PM, Henrik Sperre Johansen wrote: > On 26.04.2011 15:27, StÃ©phane Ducasse wrote: >> but henrik I would not rever the change. >> If I remember correctly I change them because they were incorrect. >> >> Stef > No, they were not incorrect, you tried to sort out a dependency, which I tried to point out was just as well solved by changing the package structure. I'm not convinced and I do not have the time now to work on it. But I'm sure that this was not only the problem of the package structure. There was something fondamentally wrong in the way it was done. > For example, now: > - Changing "sound enabled" in the Settings Browser is now broken. > - Backwards compatability with 1.0 and 1.1 for new packages based on the changes in core was broken, due to moving API from instance to class side. > > Cheers, > Henry >

April 26, 2011

Re: [Pharo-project] Henrik should we include Settings-Sound ?

by Henrik Sperre Johansen

On 26.04.2011 15:27, StÃ©phane Ducasse wrote: > but henrik I would not rever the change. > If I remember correctly I change them because they were incorrect. > > Stef No, they were not incorrect, you tried to sort out a dependency, which I tried to point out was just as well solved by changing the package structure. For example, now: - Changing "sound enabled" in the Settings Browser is now broken. - Backwards compatability with 1.0 and 1.1 for new packages based on the changes in core was broken, due to moving API from instance to class side. Cheers, Henry

April 26, 2011