[Pharo-project] [Jenkins] New issue status for real problems.

Henrik Sperre Johansen henrik.s.johansen at veloxit.no
Wed Jul 11 10:37:53 EDT 2012


On 11.07.2012 15:41, Camillo Bruni wrote:
> On 2012-07-11, at 15:28, Henrik Sperre Johansen wrote:
>
>> On 11.07.2012 15:14, Camillo Bruni wrote:
>>> On 2012-07-11, at 15:02, Stéphane Ducasse wrote:
>>>
>>>> On Jul 11, 2012, at 11:05 AM, Camillo Bruni wrote:
>>>>
>>>>> That was a weird bug... but I fixed it.
>>>>> We need a Debugger for the announcement system!
>>>> What do you mean?
>>>> Because what I know is that debugging the test of announcement can be a pain because registrations are done in another world.
>>> the problem is, that on:fork: and co are used in the WeakMessageSends
>>> and thus lose the complete reference to where they came from..
>>>
>>>>> I tried to refactoring a bit so you can get a clue what's going on when stepping through with the debugger…
>>>> What you describe is more related to the state of the debugger and yes it was on our todo to fix the debugger.
>>> no no, when you do SubscriptionRegistry >> #deliver:
>>> you create a complete copy of the subscriptions collection.
>>> This is not very useful, since you can filter them while copying => less items to copy, easier to inspect
>> Not threadsafely.
> ? this has absolutely nothing to do with thread safeness....
You're right, I'd forgotten exactly what we'd done :)
In my mind it still read something like:

deliver: anAnnouncement
      subscriptions copy do: [:each | each deliver: anAnnouncement ],

relying on atomicity implicit through copy primitives rather than 
explicitly with a mutex.

Filtering with the standard collection methods leaves you with an 
IdentitySet though, so you'd have to either convert it afterwards, 
change the curtailing code in deliver:to: (which uses Sequenceable 
protocol).
Either probably has some tradeoff in readability/performance compared to 
the current delivery.

Cheers,
Henry




More information about the Pharo-dev mailing list