For "working signals" I suppose will be enough fixing of both Issue 9606 [1] and Issue 9603 [2].

IMO, for the first issue we need weak references [3].
IMO, for the second issue we need to make regular D objects on closures [4] and fix Issue 9602 [5].

Any thoughts about my proposal to make signals working in D? Other proposals? Any (approximate) period for [proposal parts] to be implemented?

Also, does anybody think currently D has working signals and I'm just slander in the title?

P.S.
Also there is a proposal for new signals implementation without compiler changes [6].


[1] http://d.puremagic.com/issues/show_bug.cgi?id=9606
[2] http://d.puremagic.com/issues/show_bug.cgi?id=9603
[3] http://d.puremagic.com/issues/show_bug.cgi?id=4151
[4] http://d.puremagic.com/issues/show_bug.cgi?id=9601
[5] http://d.puremagic.com/issues/show_bug.cgi?id=9602
[6] http://d.puremagic.com/issues/show_bug.cgi?id=9347

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

There is: http://wiki.dlang.org/Review_Queue

It is currently blocked by: http://d.puremagic.com/issues/show_bug.cgi?id=8441

There is already a pull request for 8441, but it was not merged yet.

As soon as 8441 gets fixed, I am going to finish up the implementation to make it ready for review.

For an overview of fixes and improvements over the current implementation, simply search the forums for std.signals2.

Best regards,
Robert

On Sun, 2013-04-14 at 11:06 +0400, Denis Shelomovskij wrote:
> For "working signals" I suppose will be enough fixing of both Issue 9606 [1] and Issue 9603 [2].
> 
> IMO, for the first issue we need weak references [3].
> IMO, for the second issue we need to make regular D objects on closures
> [4] and fix Issue 9602 [5].
> 
> Any thoughts about my proposal to make signals working in D? Other proposals? Any (approximate) period for [proposal parts] to be implemented?
> 
> Also, does anybody think currently D has working signals and I'm just slander in the title?
> 
> P.S.
> Also there is a proposal for new signals implementation without compiler
> changes [6].
> 
> 
> [1] http://d.puremagic.com/issues/show_bug.cgi?id=9606
> [2] http://d.puremagic.com/issues/show_bug.cgi?id=9603
> [3] http://d.puremagic.com/issues/show_bug.cgi?id=4151
> [4] http://d.puremagic.com/issues/show_bug.cgi?id=9601
> [5] http://d.puremagic.com/issues/show_bug.cgi?id=9602
> [6] http://d.puremagic.com/issues/show_bug.cgi?id=9347
> 

14.04.2013 15:22, Robert пишет:
> There is: http://wiki.dlang.org/Review_Queue
>
> It is currently blocked by:
> http://d.puremagic.com/issues/show_bug.cgi?id=8441
>
> There is already a pull request for 8441, but it was not merged yet.
>
> As soon as 8441 gets fixed, I am going to finish up the implementation
> to make it ready for review.
>
> For an overview of fixes and improvements over the current
> implementation, simply search the forums for std.signals2.

Does it mean you disagree with proposed compiler changes and with the idea we have to create weak reference functionality instead of recreating it every time it is needed (beside of theoretical danger such approach already showed it as a bad thing with `std.stdio.File` as I wrote)?

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

> Does it mean you disagree with proposed compiler changes and with the idea we have to create weak reference functionality instead of recreating it every time it is needed (beside of theoretical danger such approach already showed it as a bad thing with `std.stdio.File` as I wrote)?
> 


A weak reference could actually be implemented in the library relatively easy. ( I basically did it for std.signals2 ) But for std.signals a weak ref is not really enough, because ideally the slot gets removed if the target gets destroyed, not only set to null. Updating a collection on destruction of an object is not that easy as you pointed out (thank you for that), but I don't see how weak references would help there.

But you just made me think: If it is ok that a signal does not release the memory for the slot immediately when the object gets destroyed but only on the next call to emit(), then the implementation would be much simpler ...

Best regards,
Robert

Am Sun, 14 Apr 2013 19:07:58 +0200
schrieb Robert <jfanatiker@gmx.at>:

> > Does it mean you disagree with proposed compiler changes and with the idea we have to create weak reference functionality instead of recreating it every time it is needed (beside of theoretical danger such approach already showed it as a bad thing with `std.stdio.File` as I wrote)?
> > 
> 
> 
> A weak reference could actually be implemented in the library relatively easy. ( I basically did it for std.signals2 ) But for std.signals a weak ref is not really enough, because ideally the slot gets removed if the target gets destroyed, not only set to null. Updating a collection on destruction of an object is not that easy as you pointed out (thank you for that), but I don't see how weak references would help there.
> 
> But you just made me think: If it is ok that a signal does not release the memory for the slot immediately when the object gets destroyed but only on the next call to emit(), then the implementation would be much simpler ...
> 
> Best regards,
> Robert
> 

IMHO if a object still is connected to a active signal it should not be collected. So the place where the signal stores the handler should be scanned by the GC as usual. Then just document clearly that you have to remove a handler to make sure that garbage collection can really kick in.

> IMHO if a object still is connected to a active signal it should not be collected. So the place where the signal stores the handler should be scanned by the GC as usual. Then just document clearly that you have to remove a handler to make sure that garbage collection can really kick in.

If you really want this behaviour, all you need is an array of delegates. But in my experience you don't usually want that, because you would have to take care of dropping any connections by hand, which is even more cumbersome than manual memory management in some regards.

Best regards,
Robert

On Sunday, 14 April 2013 at 17:35:00 UTC, Johannes Pfau wrote:
> IMHO if a object still is connected to a active signal it should not be
> collected. So the place where the signal stores the handler should be
> scanned by the GC as usual. Then just document clearly that you have to
> remove a handler to make sure that garbage collection can really kick
> in.

The caller should have the option to connect a strong reference or a weak reference. In C#, people forgetting to disconnect event handlers is the most common source of memory leaks. Let's not bring that to D.

On Sunday, 14 April 2013 at 07:06:12 UTC, Denis Shelomovskij wrote:
> For "working signals" I suppose will be enough fixing of both Issue 9606 [1] and Issue 9603 [2].
>
> IMO, for the first issue we need weak references [3].
> IMO, for the second issue we need to make regular D objects on closures [4] and fix Issue 9602 [5].
>
> Any thoughts about my proposal to make signals working in D? Other proposals? Any (approximate) period for [proposal parts] to be implemented?
>
> Also, does anybody think currently D has working signals and I'm just slander in the title?
>
> P.S.
> Also there is a proposal for new signals implementation without compiler changes [6].
>
>
> [1] http://d.puremagic.com/issues/show_bug.cgi?id=9606
> [2] http://d.puremagic.com/issues/show_bug.cgi?id=9603
> [3] http://d.puremagic.com/issues/show_bug.cgi?id=4151
> [4] http://d.puremagic.com/issues/show_bug.cgi?id=9601
> [5] http://d.puremagic.com/issues/show_bug.cgi?id=9602
> [6] http://d.puremagic.com/issues/show_bug.cgi?id=9347

Can you expand yourself on the subject ? I did followed discussion on the topic, and so this thread is quite hard to follow.

15.04.2013 7:46, deadalnix пишет:
> On Sunday, 14 April 2013 at 07:06:12 UTC, Denis Shelomovskij wrote:
>> For "working signals" I suppose will be enough fixing of both Issue
>> 9606 [1] and Issue 9603 [2].
>>
>> IMO, for the first issue we need weak references [3].
>> IMO, for the second issue we need to make regular D objects on
>> closures [4] and fix Issue 9602 [5].
>>
>> Any thoughts about my proposal to make signals working in D? Other
>> proposals? Any (approximate) period for [proposal parts] to be
>> implemented?
>>
>> Also, does anybody think currently D has working signals and I'm just
>> slander in the title?
>>
>> P.S.
>> Also there is a proposal for new signals implementation without
>> compiler changes [6].
>>
>>
>> [1] http://d.puremagic.com/issues/show_bug.cgi?id=9606
>> [2] http://d.puremagic.com/issues/show_bug.cgi?id=9603
>> [3] http://d.puremagic.com/issues/show_bug.cgi?id=4151
>> [4] http://d.puremagic.com/issues/show_bug.cgi?id=9601
>> [5] http://d.puremagic.com/issues/show_bug.cgi?id=9602
>> [6] http://d.puremagic.com/issues/show_bug.cgi?id=9347
>
> Can you expand yourself on the subject ? I did followed discussion on
> the topic, and so this thread is quite hard to follow.

My points was:

1. Implement a weak reference (and, better, a weak references array) as a general utility [3] and don't implement it in every case we need it (this will make `std.signals` fixing [1] trivial, one will just supersede incorrect internal weak ref implementation with standard one).

2. Make regular D objects on closures [4] to be able to know when delegate's outer scope is destroyed (this will auto-fix both [5] and [2], see Comment 2 of [2] for code example)


I think both points are relatively easy to implement and will improve things a lot.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

14.04.2013 21:07, Robert пишет:
>> Does it mean you disagree with proposed compiler changes and with the
>> idea we have to create weak reference functionality instead of
>> recreating it every time it is needed (beside of theoretical danger such
>> approach already showed it as a bad thing with `std.stdio.File` as I wrote)?
>>
>
>
> A weak reference could actually be implemented in the library relatively
> easy. ( I basically did it for std.signals2 ) But for std.signals a weak
> ref is not really enough, because ideally the slot gets removed if the
> target gets destroyed, not only set to null. Updating a collection on
> destruction of an object is not that easy as you pointed out (thank you
> for that), but I don't see how weak references would help there.

Array of weak references is what is needed.

>
> But you just made me think: If it is ok that a signal does not release
> the memory for the slot immediately when the object gets destroyed but
> only on the next call to emit(), then the implementation would be much
> simpler ...

Yes, this is how array of weak references will work because this is how weak references work. And this shows one mustn't implement general facilities in every case they are needed as he will do mistakes and will complicate thinks for himself.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij