Ok, forget backwards compatibility for a moment, it was just an
additional goody.
On Thu, 2013-02-07 at 19:38 -0500, Steven Schveighoffer wrote:
Not with @property
That's the point, it would no longer be a property but a simple function
returning ref.
front for arrays would not be a
eskimo:
The magic comes from the fact, that a signal has weak reference
semantics, which means if you drop all references to the target object,
it won't be kept in memory because of the connected signal, instead the
slot gets de-registered automatically.
What about weakref for objects
Actually it is to emulate weak references. Allocating the memory with
malloc is an easy way to have references ignored by the GC. I have
already written an improved version of std.signals. It already works,
but the template mixin frontend for easy integration into a class (with
private signal
The magic comes from the fact, that a signal has weak reference
semantics, which means if you drop all references to the target object,
it won't be kept in memory because of the connected signal, instead the
slot gets de-registered automatically.
Surprisingly a lot of people seem to be unaware
No, this would not solve the issue, except you are going to drop weak
ref semantics, which would reduce a signal to a simple array of
delegates and greatly defeats its usefulness. (To prevent memory leaks,
you would have to deregister all your objects from any signals they
might be connected to,
That is pretty much what I had in mind, but more concrete thought
through. I really like it :-) The only things to clear up would be, how
long must a release branch exist, before it is considered stable. Which
depends on how stable we want things to be.
On Thu, 2012-11-29 at 11:35 +0100, foobar
On Thu, 2012-11-29 at 12:45 +0100, eskimo wrote:
That is pretty much what I had in mind, but more concrete thought
through. I really like it :-) The only things to clear up would be, how
long must a release branch exist, before it is considered stable. Which
depends on how stable we want
Actually I figured it out - rdmd can simply read its own file argument
and look at the shebang line. Then there's no more issue of space
coalescing, line length limitations etc.
Smart! :-)
On Wed, 2012-11-28 at 13:02 -0600, 1100110 wrote:
Given that Phobos is still a moving target with new functionality
being
added on a regular basis, it could be a bit of a disappointment to
have
to wait as long as 6 months to see the latest new features.
Well either you want stable or
On Sat, 2012-11-17 at 04:20 +0100, Rob T wrote:
I don't see one for this bug either, probably why it's not fixed.
You should create it.
I just verified, the compiler swaps the struct contents, so it actually
does the right thing if you demand that structs are relocatable. So in
effect
Why would is(T == struct) be true but !isBuiltinType!T be false?
Exactly because of alias this. Your type is a struct and an integer at
the same time, so to speak. At least it behaves that way and that's what
its all about. If if looks like a duck, quacks like a duck, ... it is a
duck ;-)
This
I hit a strange problem, which seems to be a compiler bug, but I kind of
doubt it, because it is really serious and I did not find anything in
bugzilla. So here is the example code, that behaves really not as
expected and in my understanding just plain and seriously wrong:
---
#!/usr/bin/rdmd
opAssign(TTest other)
Thanks for highlighting this, now it is at least clear what happens.
The fact that opAssign called for: is not printed is, AFAIK, a
HUGE and old standing bug: The fields of the struct are bit
copied (!)
I now re-read the section in TDPL about move
On Fri, 2012-11-16 at 23:45 +0100, Rob T wrote:
This should be a compiler error or at the very least issue a
warning.
It seems to me that overridden sub-struct opAssign needs to be
chained together, and it's a compiler error if there's a break in
the chain, i.e., if a sub-level struct
On Thu, 2012-11-15 at 09:53 +0100, Joe wrote:
On Wednesday, 14 November 2012 at 09:31:47 UTC, eskimo wrote:
But first it is copied to every generic function that might be
called on
the way.
Ok, I guess it just doesn't do what I understood it to do (which
is too bad, but to be expected
Hey guys!
I just wanted to say that D is really really really awesome and I wanted
to thank everyone contributing to it.
I think what D needs the most at the moment is bug fixing so I am very
pleased to read the commit messages:
Fixed bug ...
Fixed bug ...
Fixed bug ...
Fixed bug ...
.
On Wed, 2012-11-14 at 18:31 -0800, Andrei Alexandrescu wrote:
array(map!a.dup(stdin.byLine()))
As it seems there is a good way of handling ranges with transient front
for algorithms that need a persistent front?
Why not simply document any transient range to be transient (should be
anyway) and
:-) Indeed, that is the only thing that surprised me too (but not as
much as in another language, because of D's capabilities). The solution
I think is this overload found in std.format of formatValue:
void formatValue(Writer, T, Char)(Writer w, auto ref T val, ref
FormatSpec!Char f)
if ((is(T ==
On Thu, 2012-11-15 at 10:56 -0800, H. S. Teoh wrote:
I don't like duplicating a whole bunch of algorithms in
transalgorithm.
If its true what you say, that usually there is no difference in
efficiency, than there is no need for any duplication. But it is
certainly better to offer an standard
In your particular case, which this definitely is a bug and if only for
missing documentation that you should only use it from classes, you
might regardless be better of with writeln(f.prop.get) because you avoid
the needless copy with memory allocation/deallocation (if done
correctly) of the
But wait! Due to alias get this;, f.prop shouldn't copy prop
but call get (which it does in the working - second - case)!
- Also here the struct is copied, but the signal has no content yet and
thus no memory allocation yet occurred. (So no double free)
How to check? Remove the alias and
Not a compiler bug. A bug in the implementation of std.signals.
writeln(f.prop);
Property is a struct and thus it is passed by value, which means that
the signal is copied. Signal does not define a postblit constructor,
because it was intended to be used in classes, so a bitwise copy is
I'm not sure I understand why you would hide a pointer from the GC.
As already suggested by Kapps, for weak references. I need that for my
new std.signals implementation.
Are there memory models in use
where the inverted pointer value might also be in GC memory?
Yes, that can
Yeah, you are right if all pointer bits are actually used it is far too
easy. On the other hand especially because less space is wasted for
pointers on 32 bit, I can easily afford an extra variable to solve this
problem (kind of).
I guess it is a pretty safe bet to assume that the lowest
You could use it, and come up with something else which also
works on x86, etc., but I'd look into storing your weak reference
(or whatever) in a page with the NO_SCAN attribute set. It will
cause the GC to ignore it entirely.
Thanks but that's no option for me, because I need the
You say the latest LTS, but the LTS are supported for five years. Don't
they release new LTS more often than that? According to this
https://wiki.ubuntu.com/LTS They release a new LTS every two years and
they're supported for five years.
I am sorry. I haven't quite said what I meant. I
Hey party people!
What is the current state? Is it enough to store a pointer in a
ptrdiff_t variable instead of a pointer for the GC to ignore it or is my
current trick of simply inverting its value required?
If the trick is required, is it safe? Are there memory models in use
where the inverted
_tab.closed.connect((sender,args)=this.Dispose());
If the closure dies prematurely, it won't free resources at all
or at the right time. Although you currently keep a strong
reference to closures, you claim it's a bug rather than feature.
You fix deterministic sloppiness of memory leaks
Having signals with weak reference semantics can be surprising
for a garbage collected language: AFAIK Java and C# use strong
reference semantics for observers. On the other hand one may want
strong reference semantics: if you have e.g. a button.click
listener, you don't want it to die
On Tue, 2012-11-06 at 14:13 +0100, Jacob Carlborg wrote:
obj.signal.connect(() { /* my very funny delegate. */ })
which would compile with the standard implementation but would fail
badly at runtime.
And why would it be bad to pass a delegate literal like this?
Because the connect
I've not read the code and I'm not 100% sure of the intentions of
std.signal but why not just call the delegate as is?
Signals are a way of a very loose coupling of components. This loose
coupling is the reason why people usually expect weak reference
semantics from signals. So people
On Tue, 2012-11-06 at 11:16 -0800, Sean Kelly wrote:
On Nov 5, 2012, at 5:36 AM, Robert jfanati...@gmx.at wrote:
I just developed a proof-of-concept implementation of an improved
std.signals.
Make sure that the behavior when calling std.signals operations from within a
callback is
Completely working version online, all unit tests pass:
https://github.com/eskimor/phobos/blob/new_signal/std/signals.d
Although I will add some more, especially for the new functionality.
I don't expect signals in D being as overused as in Qt (because we have
delegates which are often the
What happens when a callback removes itself from the signal when called?
What happens when it adds a new callback? Since these operations modify the
list that's currently being iterated across, the implementation typically has
to be done in a way that accounts for this.
Damn it. That's
34 matches
Mail list logo
