www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is there any plans to make working signals in D?

reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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
Apr 14 2013
next sibling parent reply Robert <jfanatiker gmx.at> writes:
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
 

Apr 14 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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
Apr 14 2013
next sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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
Apr 14 2013
prev sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 14.04.2013 19:07, schrieb 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 )

My memories tell me that I was never able to make a _thread safe_ weak reference, though. I don't remember exactly, but I think that it was because the dispose event happens after all threads have already restarted. This means that some thread could extract a strong reference from the weak reference before the weak reference knows that the underlying object has been destroyed, thus creating a dangling pointer.
Apr 15 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
 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
Apr 14 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
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.
Apr 14 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
 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
Apr 14 2013
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
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.
Apr 14 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Apr 14 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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
Apr 14 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
15.04.2013 13:07, Robert пишет:
 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 still don't understand what that buys us. Having a closure being an object would make it possible to use a weak reference, but why would you want that? The signal would be the only one to hold a reference to the lamdas context, if this reference was a weak one, then the memory would be claimed immediately. This is why std.signals2 holds a strong ref to the delegate context of a wrapping closure and a weak ref to the target object.

With your `std.signals2` one can't e.g. forward delegate connection like this: --- /// Usage: don't pass struct pointer delegates as `del`. void f(void delegate() del) { obj.event.connect(del); } --- as you require explicit passing an object owning a delegate. But it is completely unnecessary as delegate do know where it was born from and the fact this information isn't tracked when a closure is created is a language design issue. One of those fixing which is easy, will not break any code and will improve things a lot. -- Денис В. Шеломовский Denis V. Shelomovskij
Apr 15 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
15.04.2013 20:15, deadalnix пишет:
 On Monday, 15 April 2013 at 12:07:19 UTC, Denis Shelomovskij wrote:
 15.04.2013 13:07, Robert пишет:
 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 still don't understand what that buys us. Having a closure being an object would make it possible to use a weak reference, but why would you want that? The signal would be the only one to hold a reference to the lamdas context, if this reference was a weak one, then the memory would be claimed immediately. This is why std.signals2 holds a strong ref to the delegate context of a wrapping closure and a weak ref to the target object.

With your `std.signals2` one can't e.g. forward delegate connection like this: --- /// Usage: don't pass struct pointer delegates as `del`. void f(void delegate() del) { obj.event.connect(del); } --- as you require explicit passing an object owning a delegate. But it is completely unnecessary as delegate do know where it was born from and the fact this information isn't tracked when a closure is created is a language design issue. One of those fixing which is easy, will not break any code and will improve things a lot.

Even with that explanation, I still don't see the problem.

Do you mean that tracking an object with a delegate whenever it goes to just know where it's outer scope is destroyed is not a problem? -- Денис В. Шеломовский Denis V. Shelomovskij
Apr 15 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
16.04.2013 10:10, deadalnix пишет:
 On Tuesday, 16 April 2013 at 05:39:32 UTC, Denis Shelomovskij wrote:
 Do you mean that tracking an object with a delegate whenever it goes
 to just know where it's outer scope is destroyed is not a problem?

Delegate context is allocated on the heap, unless compiler can prove it can do it on stack. context is destroyed when no live pointer point to it. You still didn't explain why an object is better than the actual delegate mecanism.

Sorry, I really don't understand what you don't understand. Let's consider example from Issue 9603 Comment 2 [1]. Do you think such code must not work? Also you can look through Issue 9601 discussion. [1] http://d.puremagic.com/issues/show_bug.cgi?id=9603#c2 [2] http://d.puremagic.com/issues/show_bug.cgi?id=9601 -- Денис В. Шеломовский Denis V. Shelomovskij
Apr 16 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
16.04.2013 13:17, deadalnix пишет:
 On Tuesday, 16 April 2013 at 07:55:51 UTC, Denis Shelomovskij wrote:
 Sorry, I really don't understand what you don't understand.

 Let's consider example from Issue 9603 Comment 2 [1]. Do you think
 such code must not work?

 Also you can look through Issue 9601 discussion.

 [1] http://d.puremagic.com/issues/show_bug.cgi?id=9603#c2
 [2] http://d.puremagic.com/issues/show_bug.cgi?id=9601

The code in 9603 is completely broken. It should compile and run, but what it does is undefined as o is finalized when delegates have reference to it. I don't see how changing delegate into object would change anything, as the code would be broken in the same way for the same reason.

Current behaviour when delegates stays alive when its outer scope is destroyed is just a bad language design. Let's assume there is a "magic" way to make code in Issue 9603 work. Do you think this is usable? So, the "magic": I propose to make an object on closure creation (i.e. just prepend allocated closure with few hidden fields) and add "finalize the closure" to outer scope dispose event. And I already described it in Issue 9601 and its comments. What is non-obvious here? Note: This can work just the same way if there is no GC-allocated closure. -- Денис В. Шеломовский Denis V. Shelomovskij
Apr 16 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
17.04.2013 10:43, deadalnix пишет:
 On Wednesday, 17 April 2013 at 06:15:43 UTC, Denis Shelomovskij wrote:
 Current behaviour when delegates stays alive when its outer scope is
 destroyed is just a bad language design.

No, destroying is unsafe by definition, and this is why GC solve a lot of problems.

I mead destroying by GC.
 Can you explain what is the problem ?

Code in Issue 9603 doesn't work.
 What does creating an object change except adding 2 pointers into the frame
pointer ?

It will make code in Issue 9603 work. -- Денис В. Шеломовский Denis V. Shelomovskij
Apr 17 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/17/2013 12:35 PM, Denis Shelomovskij wrote:
 ...

 It will make code in Issue 9603 work.

You have to argue why this is the correct way to fix it. Why would lifetime control necessarily be linked to implicit object field overhead?
Apr 17 2013
parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
17.04.2013 15:26, Timon Gehr пишет:
 On 04/17/2013 12:35 PM, Denis Shelomovskij wrote:
 ...

 It will make code in Issue 9603 work.

You have to argue why this is the correct way to fix it. Why would lifetime control necessarily be linked to implicit object field overhead?

0. I do like this approach, it looks straight and consistent IMO. 1. I see no other ways to fix the issue. 2. I see no important overhead in my proposal as wasting a few bytes is nothing in contrast with GC allocation process/memory overhead. 3. I think added functionality is very usable and even already required. Everyone is free to propose a better approach. By the way, almost every technical idea we know is incorrect and will be likely superceeded in the future with a better one as history shows. -- Денис В. Шеломовский Denis V. Shelomovskij
Apr 18 2013
prev sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
17.04.2013 19:47, deadalnix пишет:
 On Wednesday, 17 April 2013 at 10:35:08 UTC, Denis Shelomovskij wrote:
 Can you explain what is the problem ?

Code in Issue 9603 doesn't work.

That is not explaining what is the problem. This should contains at least : - Why it doesn't work.

No ability to tell when a delegate will be destroyed (currently it isn't even destroyed when it should, see Issue 9602). http://d.puremagic.com/issues/show_bug.cgi?id=9602
   - What is the fundamental problem.

When a delegate is created information about it's outer scope is lost instead of being stored in it's ptr.
   - Why this fundamental problem is a language issue and not a lib one.

Looks self-evident.
   - How does you proposition solve it.

It stores the information about delegate's outer scope wasting (oh God, how many, especially in contrast to GC allocation) a few bytes.
 Right now, the only element you have been able to provide are :
   - signal accept delegate from object.
   - So we must make all delegate object.

 This is a very poor argumentation as the only reasonable answer to 1
 without more input is go fix signal or raise a bug about signal.

As everything I have written above is known, I still don't understand why you are telling about signal fixing as a main problem as it is just an example of problems that occurs when we throw away outer scope information without any practical reason, IMO. -- Денис В. Шеломовский Denis V. Shelomovskij
Apr 18 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
18.04.2013 18:21, deadalnix пишет:
 On Thursday, 18 April 2013 at 13:25:32 UTC, Denis Shelomovskij wrote:
  - What is the fundamental problem.

When a delegate is created information about it's outer scope is lost instead of being stored in it's ptr.

That doesn't mean anything. No information is stored into a ptr except an address in memory.

A joke? Of course I mean "stored into a memory ptr point to".
  - Why this fundamental problem is a language issue and not a lib one.


I don't care about the cost. You have made no point in 3 pages in favor of the change you propose. Not even an invalid point I can disagree on.
 As everything I have written above is known, I still don't understand
 why you are telling about signal fixing as a main problem as it is
 just an example of problems that occurs when we throw away outer scope
 information without any practical reason, IMO.

It is an example of a library interface issue (very real). To propose a language change, you must show that this limitation is in fact a symptom of a deeper cause, which it at language level (so that must be fixed at language level).

Another try to describe the problem: When I get a delegate, I'd like to use it unless it become invalid. -- Денис В. Шеломовский Denis V. Shelomovskij
Apr 19 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
19.04.2013 11:45, deadalnix пишет:
 On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote:
 Another try to describe the problem:

 When I get a delegate, I'd like to use it unless it become invalid.

How does using an object solve that ?

Unless this is a struct-member delegate (which is not often used anyway and can be marked as dangerous e.g.): --- T delegate(A) del = ...; rt_attachDisposeEvent(_d_toObject(del.ptr), &onDelegateDisposed); --- -- Денис В. Шеломовский Denis V. Shelomovskij
Apr 24 2013
parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
24.04.2013 12:47, deadalnix пишет:
 On Wednesday, 24 April 2013 at 08:27:15 UTC, Denis Shelomovskij wrote:
 19.04.2013 11:45, deadalnix пишет:
 On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote:
 Another try to describe the problem:

 When I get a delegate, I'd like to use it unless it become invalid.

How does using an object solve that ?

Unless this is a struct-member delegate (which is not often used anyway and can be marked as dangerous e.g.): --- T delegate(A) del = ...; rt_attachDisposeEvent(_d_toObject(del.ptr), &onDelegateDisposed); ---

I still see many possibilities without changing the language. For instance, allowing to attach dispose event to something else than an object.

Thus making that "something else" almost class but not class and I don't see why not just use class instead of creating a new entity. -- Денис В. Шеломовский Denis V. Shelomovskij
Apr 26 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
 My memories tell me that I was never able to make a _thread safe_ weak
 reference, though. I don't remember exactly, but I think that it was
 because the dispose event happens after all threads have already
 restarted. This means that some thread could extract a strong reference
 from the weak reference before the weak reference knows that the
 underlying object has been destroyed, thus creating a dangling pointer.
 

gets called before threads are resumed. It is not an issue for std.signals2 because it is not meant to be thread safe. Best regards, Robert
Apr 15 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
 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.
 

If an array of weak references works this way, then it is also easily implementable in the library. For thread safe weak references another hook would be necessary though, as Soenke has pointed out. My current approach is to use a /simplified/*) lock-free list. Simplified because I make use of the way the GC works, so it is not thread safe in general. The lazy approach would make this unnecessary. Maybe I go for lazy, the more sophisticated solution can be implemented later on if really deemed necessary. *) It is still brain-fuck though.
Apr 15 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
 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 still don't understand what that buys us. Having a closure being an object would make it possible to use a weak reference, but why would you want that? The signal would be the only one to hold a reference to the lamdas context, if this reference was a weak one, then the memory would be claimed immediately. This is why std.signals2 holds a strong ref to the delegate context of a wrapping closure and a weak ref to the target object.
Apr 15 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 15 April 2013 at 12:07:19 UTC, Denis Shelomovskij 
wrote:
 15.04.2013 13:07, Robert пишет:
 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 still don't understand what that buys us. Having a closure being an object would make it possible to use a weak reference, but why would you want that? The signal would be the only one to hold a reference to the lamdas context, if this reference was a weak one, then the memory would be claimed immediately. This is why std.signals2 holds a strong ref to the delegate context of a wrapping closure and a weak ref to the target object.

With your `std.signals2` one can't e.g. forward delegate connection like this: --- /// Usage: don't pass struct pointer delegates as `del`. void f(void delegate() del) { obj.event.connect(del); } --- as you require explicit passing an object owning a delegate. But it is completely unnecessary as delegate do know where it was born from and the fact this information isn't tracked when a closure is created is a language design issue. One of those fixing which is easy, will not break any code and will improve things a lot.

Even with that explanation, I still don't see the problem.
Apr 15 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 16 April 2013 at 05:39:32 UTC, Denis Shelomovskij 
wrote:
 Do you mean that tracking an object with a delegate whenever it 
 goes to just know where it's outer scope is destroyed is not a 
 problem?

Delegate context is allocated on the heap, unless compiler can prove it can do it on stack. context is destroyed when no live pointer point to it. You still didn't explain why an object is better than the actual delegate mecanism.
Apr 15 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 16 April 2013 at 07:55:51 UTC, Denis Shelomovskij 
wrote:
 Sorry, I really don't understand what you don't understand.

 Let's consider example from Issue 9603 Comment 2 [1]. Do you 
 think such code must not work?

 Also you can look through Issue 9601 discussion.

 [1] http://d.puremagic.com/issues/show_bug.cgi?id=9603#c2
 [2] http://d.puremagic.com/issues/show_bug.cgi?id=9601

The code in 9603 is completely broken. It should compile and run, but what it does is undefined as o is finalized when delegates have reference to it. I don't see how changing delegate into object would change anything, as the code would be broken in the same way for the same reason.
Apr 16 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Sun, 14 Apr 2013 21:29:07 +0200
schrieb Robert <jfanatiker gmx.at>:

 
 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

But what if my only reference to the handler is in the signal and I don't want it to get disconnected / cleaned up? struct FileLogger { File f; void onSomething() { f.writeln("Something happened"); } } a.onSomething ~= &(new FileLogger()).onSomething; (The FileLogger should only get destroyed if a is destroyed) I have used that concept quite often in C#. Of course it's also dangerous as it could cause memory leaks if used wrong. But I think we should at least have the option of doing things like these. (Allowong both strong & weak references as suggested by Kapps seems to be a good solution)
Apr 16 2013
prev sibling next sibling parent "Robert" <jfanatiker gmx.at> writes:
 (Allowong
 both strong & weak references as suggested by Kapps seems to be 
 a good
 solution)

std.signals2 supports both, just use strongConnect(). Best regards, Robert
Apr 16 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 17 April 2013 at 06:15:43 UTC, Denis Shelomovskij 
wrote:
 Current behaviour when delegates stays alive when its outer 
 scope is destroyed is just a bad language design.

No, destroying is unsafe by definition, and this is why GC solve a lot of problems. Can you explain what is the problem ? What does creating an object change except adding 2 pointers into the frame pointer ?
Apr 16 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 17 April 2013 at 10:35:08 UTC, Denis Shelomovskij 
wrote:
 Can you explain what is the problem ?

Code in Issue 9603 doesn't work.

That is not explaining what is the problem. This should contains at least : - Why it doesn't work. - What is the fundamental problem. - Why this fundamental problem is a language issue and not a lib one. - How does you proposition solve it. Right now, the only element you have been able to provide are : - signal accept delegate from object. - So we must make all delegate object. This is a very poor argumentation as the only reasonable answer to 1 without more input is go fix signal or raise a bug about signal.
Apr 17 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 18 April 2013 at 13:25:32 UTC, Denis Shelomovskij 
wrote:
  - What is the fundamental problem.

When a delegate is created information about it's outer scope is lost instead of being stored in it's ptr.

That doesn't mean anything. No information is stored into a ptr except an address in memory.
  - Why this fundamental problem is a language issue and not a 
 lib one.

Looks self-evident.

It look self evident to me that the earth is flat when I look through the window.
  - How does you proposition solve it.

It stores the information about delegate's outer scope wasting (oh God, how many, especially in contrast to GC allocation) a few bytes.

I don't care about the cost. You have made no point in 3 pages in favor of the change you propose. Not even an invalid point I can disagree on.
 As everything I have written above is known, I still don't 
 understand why you are telling about signal fixing as a main 
 problem as it is just an example of problems that occurs when 
 we throw away outer scope information without any practical 
 reason, IMO.

It is an example of a library interface issue (very real). To propose a language change, you must show that this limitation is in fact a symptom of a deeper cause, which it at language level (so that must be fixed at language level).
Apr 18 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij 
wrote:
 Another try to describe the problem:

 When I get a delegate, I'd like to use it unless it become 
 invalid.

How does using an object solve that ?
Apr 19 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 24 April 2013 at 08:27:15 UTC, Denis Shelomovskij 
wrote:
 19.04.2013 11:45, deadalnix пишет:
 On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij 
 wrote:
 Another try to describe the problem:

 When I get a delegate, I'd like to use it unless it become 
 invalid.

How does using an object solve that ?

Unless this is a struct-member delegate (which is not often used anyway and can be marked as dangerous e.g.): --- T delegate(A) del = ...; rt_attachDisposeEvent(_d_toObject(del.ptr), &onDelegateDisposed); ---

I still see many possibilities without changing the language. For instance, allowing to attach dispose event to something else than an object.
Apr 24 2013