Is there any plans to make working signals in D?
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
Re: immutable constructor and semantics of two construction syntaxes
On 04/14/2013 02:48 AM, Ali Çehreli wrote:
When immutable constructors are implemented, will there be a difference
between the two syntaxes below?
struct MyStruct
{
int i;
// ... assume that MyStruct has both
// mutable and immutable constructors ...
}
auto s0 = immutable(MyStruct)("some parameter");
immutable s1 = MyStruct("some parameter");
The former syntax constructs an immutable literal, so the type of s0 is
deduced to be immutable.
The latter syntax constructs a mutable literal and blits it to the
immutable s1.
Should the former syntax call the immutable constructor and the latter
syntax call the mutable constructor?
Ali
I guess so. But it does not really make sense to declare an immutable
constructor if the struct instances implicitly convert between mutable
and immutable.
Re: Is there any plans to make working signals in D?
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 >
Re: immutable constructor and semantics of two construction syntaxes
On Sunday, 14 April 2013 at 08:03:16 UTC, Timon Gehr wrote:
On 04/14/2013 02:48 AM, Ali Çehreli wrote:
When immutable constructors are implemented, will there be a
difference
between the two syntaxes below?
struct MyStruct
{
int i;
// ... assume that MyStruct has both
// mutable and immutable constructors ...
}
auto s0 = immutable(MyStruct)("some parameter");
immutable s1 = MyStruct("some parameter");
The former syntax constructs an immutable literal, so the type
of s0 is
deduced to be immutable.
The latter syntax constructs a mutable literal and blits it to
the
immutable s1.
Should the former syntax call the immutable constructor and
the latter
syntax call the mutable constructor?
Ali
I guess so. But it does not really make sense to declare an
immutable constructor if the struct instances implicitly
convert between mutable and immutable.
I was about to answer exactly the same.
Note that s1 should fail is immutable => mutable conversion can't
be done implicitly (if MyStruct contains references).
Re: Template parameter deduction for constructors?
On Saturday, 13 April 2013 at 15:52:01 UTC, David Nadlinger wrote:
On Saturday, 13 April 2013 at 08:40:15 UTC, Peter Alexander
wrote:
This just seems like a bandaid solution to the problem. If it
works in this case then beginners will think it works in every
case, and will be even more confused when it stops working.
When would it stop working? You might want to add any such
example to http://d.puremagic.com/issues/show_bug.cgi?id=6082.
Something like this:
struct Foo(T)
{
static if (is(T == int))
this(string x) {}
else
this(T x) {}
}
T is ambiguous for Foo("bar")
Also this:
struct Foo(T)
{
this(T x) {}
this(int x) {}
}
Calls to Foo(x) are ambiguous when is(typeof(x) : int).
Allowing deduction in this case would be frustrating. Imagine
having a struct where this worked, and then you wanted to add a
new constructor, or maybe just modify the constructor for one
instantiation. You would then have to change all calls to
explicitly specify parameters.
The complexity is already there, in the form of (free) ITFI
functions.
Unfortunately you are right because of the eponymous template
hack. Without it, normal functions are non-complex.
void foo(T)(T x) {}
void foo(string x) {}
Here, foo("bar") is unambiguously the second call. (D compilers
don't allow template/non-template overloads at the moment due to
a bug, but this should work).
Unfortunately the eponymous hack falls down quite easily. For
example, IFTI on this function fails:
template foo(T)
{
static if (true)
void foo(T)(T x) {}
}
So it is just as fragile as this proposal.
Re: Is there any plans to make working signals in D?
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
Bus error on 32bit OSX, not 64bit
This code: http://pastebin.com/U5XdFfDq Will result in a bus error when compiled as 32bit. Three ways the bus error won't happen: * If I compile as 64bit everything works fine * If the function "foo" is moved inline in the "main" function everything works fine * If store the return value of "fp" in "foo" in a temporary variable and then return it DMD 2.062 Mac OS X 10.8.2 -- /Jacob Carlborg
Re: DMD-64 2.062 and GCC can't pass >8byte structs?
http://d.puremagic.com/issues/show_bug.cgi?id=5570
Re: Bus error on 32bit OSX, not 64bit
On Sunday, 14 April 2013 at 14:48:40 UTC, Jacob Carlborg wrote: This code: http://pastebin.com/U5XdFfDq Will result in a bus error when compiled as 32bit. Three ways the bus error won't happen: * If I compile as 64bit everything works fine * If the function "foo" is moved inline in the "main" function everything works fine * If store the return value of "fp" in "foo" in a temporary variable and then return it DMD 2.062 Mac OS X 10.8.2 http://d.puremagic.com/issues/enter_bug.cgi
Re: Template parameter deduction for constructors?
On 04/13/2013 01:00 AM, bearophile wrote:
This is one of the few C++14 core language proposals that seem
interesting for D:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3602.html
The purpose of this idea is to avoid the helper functions that are
currently used in D to build template structs/classes. Even if this
feature is restricted to only a subset of all the templated
structs/classes it seems useful to avoid some boilerplate code.
Is this idea adaptable to D?
Bye,
bearophile
I think the differences to be accounted for are basically that D has
n-ary default constructors, static opCall, and static if. Furthermore,
with IFTI, it is possible to only specify the prefix of the template
arguments.
---
struct S(T...){
T data;
}
S(1,2,3); // ?
S!double(1,2,3); // ?
---
struct S(T...){
T data;
static if(T.length){
this(T x){ }
}
}
S(1,2,3); // ?
---
struct S(T...){
static opCall(T)(T args){ }
}
S(1,2,3); // ?
---
Re: Bus error on 32bit OSX, not 64bit
On 2013-04-14 17:13, Peter Alexander wrote: http://d.puremagic.com/issues/enter_bug.cgi I was hoping someone would have an idea what's wrong so I can create a proper bugzilla entry. Filed an issue anyway: http://d.puremagic.com/issues/show_bug.cgi?id=9931 -- /Jacob Carlborg
Re: Is there any plans to make working signals in D?
> 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
Re: Bus error on 32bit OSX, not 64bit
On Sunday, 14 April 2013 at 14:48:40 UTC, Jacob Carlborg wrote: This code: http://pastebin.com/U5XdFfDq Will result in a bus error when compiled as 32bit. Three ways the bus error won't happen: * If I compile as 64bit everything works fine * If the function "foo" is moved inline in the "main" function everything works fine * If store the return value of "fp" in "foo" in a temporary variable and then return it DMD 2.062 Mac OS X 10.8.2 Have you tried any debugging? Disassembly? It's quite hard for me (or anyone else for that matter) to diagnose when it's not a separately compilable example and there's no extra info.
Re: Is there any plans to make working signals in D?
Am Sun, 14 Apr 2013 19:07:58 +0200 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 ) 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.
Re: Bus error on 32bit OSX, not 64bit
On 2013-04-14 19:12, John Colvin wrote: Have you tried any debugging? Disassembly? It's quite hard for me (or anyone else for that matter) to diagnose when it's not a separately compilable example and there's no extra info. This is the dissassembly for the 64bit version: http://pastebin.com/L30u3tMu 32bit version: http://pastebin.com/tKVCTeZV This is what Clang produces for basically the same code: http://pastebin.com/JBcNupfs The C code looks like: http://pastebin.com/KS9QwB3A -- /Jacob Carlborg
Re: dmd goes epic
On 2013-04-14 20:15, "Luís Marques" " wrote: http://starlogs.net/#D-Programming-Language/dmd Haha, cool :) -- /Jacob Carlborg
Re: Is there any plans to make working signals in D?
> 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
Re: dmd goes epic
On Sun, 14 Apr 2013 20:15:06 +0200 "Luís Marques" wrote: > http://starlogs.net/#D-Programming-Language/dmd I don't get it, even with JS on, it's just an image of some stars...???
Re: Is there any plans to make working signals in D?
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.
Re: dmd goes epic
On Sunday, 14 April 2013 at 21:26:05 UTC, Nick Sabalausky wrote: On Sun, 14 Apr 2013 20:15:06 +0200 "Luís Marques" wrote: http://starlogs.net/#D-Programming-Language/dmd I don't get it, even with JS on, it's just an image of some stars...??? It's a Star Wars style view at the git commit log. It uses HTML5 elements, such as audio. IIRC I remember you mentioning you were using Firefox 3.6, which (I think) doesn't support those tags.
Re: Vote for std.process
On Friday, 12 April 2013 at 04:46:52 UTC, Jesse Phillips wrote: It is that time, If you would like to see the proposed std.process include into Phobos please vote yes. If one condition must be met specify under what condition, otherwise vote no. Yes
Re: Bus error on 32bit OSX, not 64bit
On Sunday, 14 April 2013 at 18:50:52 UTC, Jacob Carlborg wrote: On 2013-04-14 19:12, John Colvin wrote: Have you tried any debugging? Disassembly? It's quite hard for me (or anyone else for that matter) to diagnose when it's not a separately compilable example and there's no extra info. This is the dissassembly for the 64bit version: http://pastebin.com/L30u3tMu 32bit version: http://pastebin.com/tKVCTeZV This is what Clang produces for basically the same code: http://pastebin.com/JBcNupfs The C code looks like: http://pastebin.com/KS9QwB3A That's a start. The relative offsets are missing from the calls though (I think), which makes it rather hard to decipher. What are you using to disassemble? "objdump -M intel -dr file.o" will give you more info. It's the standard linux tool for the job, available from macports. Also, it would be good if you ran it with gdb, when it bus errors type 'disas' and post that. Then we'd be able to see what instruction it's occurring at (hopefully).
Re: dmd goes epic
On Sun, 14 Apr 2013 23:33:33 +0200 "Kapps" wrote: > On Sunday, 14 April 2013 at 21:26:05 UTC, Nick Sabalausky wrote: > > On Sun, 14 Apr 2013 20:15:06 +0200 > > "Luís Marques" wrote: > > > >> http://starlogs.net/#D-Programming-Language/dmd > > > > I don't get it, even with JS on, it's just an image of some > > stars...??? > > It's a Star Wars style view at the git commit log. It uses HTML5 > elements, such as audio. IIRC I remember you mentioning you were > using Firefox 3.6, which (I think) doesn't support those tags. I used Opera. (Normally I use FF2, but I do switch over and muddle through with Opera if I really need to, for example whenever I use GitHub.) It's not working in IE9 either, just FWIW. It works in Iron.
Re: dmd goes epic
On Sun, Apr 14, 2013 at 06:09:41PM -0400, Nick Sabalausky wrote: > On Sun, 14 Apr 2013 23:33:33 +0200 > "Kapps" wrote: > > > On Sunday, 14 April 2013 at 21:26:05 UTC, Nick Sabalausky wrote: > > > On Sun, 14 Apr 2013 20:15:06 +0200 > > > "Luís Marques" wrote: > > > > > >> http://starlogs.net/#D-Programming-Language/dmd > > > > > > I don't get it, even with JS on, it's just an image of some > > > stars...??? > > > > It's a Star Wars style view at the git commit log. It uses HTML5 > > elements, such as audio. IIRC I remember you mentioning you were > > using Firefox 3.6, which (I think) doesn't support those tags. > > I used Opera. [...] It works on my Opera (12.15). T -- Freedom of speech: the whole world has no right *not* to hear my spouting off!
Where should I put a `condp` like function?
I'm replicating `condp` from Clojure(http://clojuredocs.org/clojure_core/1.2.0/clojure.core/condp). Basically, it's like a `switch` statement without lookup table, only it's an expression(so it returns a value) and you can choose your own predicate(the default will be "a == b"). For example: writeln(2.predSwitch!"a < b"( 1, "less then 1", 5, "less then 5", 10, "less then 10", "greater or equal to 10")); Now, I've got it working(the example actually compiles and prints "less then 5"), and I want to make a pull request to put it in Phobos(because it's a useful function) but I don't really know where to put it. None of the existing modules seems fit, and I don't want to open a new module(std.monad?) for a single function. Any suggestions?
Re: Where should I put a `condp` like function?
Idan Arye: (because it's a useful function) I think you should explain why you think it's useful. Bye, bearophile
Re: Where should I put a `condp` like function?
On Sunday, 14 April 2013 at 23:54:57 UTC, bearophile wrote: Idan Arye: (because it's a useful function) I think you should explain why you think it's useful. Bye, bearophile Well, `predSwitch` has two main advantages on regular `switch`. The first is being able to choose your own predicate. `switch` is preferable to a chain of `if`-`else if` because it's a clearer syntax(and because of the usage of lookup tables, but `predSwitch` does not have that), but not all `if`-`else if` chains are about simple equality checking - sometimes you need to check for other things, like which collection contains a value. Choosing your own predicate is helpful for that. The second advantage - which I consider much more important - it that `predSwitch` returns a value. This means you can use it mid-expression - for example, to initialize a constant, or to determine a function argument. You can't do those things with `switch` because it's a statement. If you try to initialize a constant in a `switch` statement, the constant's scope will be limited to the `case` where it is defined, and if you want to use `switch` to determine a function argument, you're gonna have to write the rest of the function call in each `case`.
Re: Where should I put a `condp` like function?
Idan Arye: You can't do those things with `switch` because it's a statement. In various Reddit threads I see people almost angry against the statement-expression distinction in contemporary programming languages. I am just starting to understand them. Bye, bearophile
Re: Where should I put a `condp` like function?
On Mon, 15 Apr 2013 02:48:27 +0200 "bearophile" wrote: > Idan Arye: > > > You can't do those things with `switch` because it's a > > statement. > > In various Reddit threads I see people almost angry against the > statement-expression distinction in contemporary programming > languages. I am just starting to understand them. > I've never seen a big problem with the statement vs expression distinction, and I think the "statements == expresions" languages sometimes takes things slightly overboard in the process of forcing them into the same mold. However, I've *definitely* wished on many occasions that D's switch could be used as an expression like in Haxe.
Re: Is there any plans to make working signals in 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.
NG server slow today?
Is it just my NG client, or has the NG server been quite slow for roughly the past 12 or so hours?
Re: Where should I put a `condp` like function?
On Sun, Apr 14, 2013 at 11:46:04PM -0400, Nick Sabalausky wrote:
> On Mon, 15 Apr 2013 02:48:27 +0200
> "bearophile" wrote:
>
> > Idan Arye:
> >
> > > You can't do those things with `switch` because it's a
> > > statement.
> >
> > In various Reddit threads I see people almost angry against the
> > statement-expression distinction in contemporary programming
> > languages. I am just starting to understand them.
[...]
I think C was one of the early innovators in treating all function calls
as expressions (or equivalently, allowing function calls to be
statements). Many languages of that era differentiated between functions
and procedures (== void functions), and treat calls to the latter
strictly as statements.
> I've never seen a big problem with the statement vs expression
> distinction, and I think the "statements == expresions" languages
> sometimes takes things slightly overboard in the process of forcing
> them into the same mold. However, I've *definitely* wished on many
> occasions that D's switch could be used as an expression like in Haxe.
Allowing arbitrary predicates and switch-as-expression allows you to
write code that shows intent very clearly:
// In pseudo-D syntax
void fill(T)(T image, int x, int y) {
image[x,y] = switch {
case isFillable(image,x,y): fillColor;
case isBorder(image,x,y): borderColor;
default: defaultColor;
};
}
This can help readability a lot when the outer expression is
complicated.
It's reminiscient of Dijkstra's guarded command language, which has a
condition statement that contains a bunch of predicate-statement pairs;
during execution, one statement is chosen from the conditional block
whose predicate evaluates to true. At least one predicate must be true
at any time, otherwise it is an error (similar to D's final switches).
If more than one predicate evaluates to true, the choice is
non-deterministic. The implementation can choose to provide a built-in
uniform randomizer for this case.
This lets you state the preconditions of statements up-front, thereby
reducing mistakes caused by implicit assumptions that fail to hold. With
code that is continually being revised, this can help prevent a lot of
bugs.
T
--
Fact is stranger than fiction.
Re: Is there any plans to make working signals in D?
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
Re: Is there any plans to make working signals in D?
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
Re: NG server slow today?
On 2013-04-15 05:49, Nick Sabalausky wrote: Is it just my NG client, or has the NG server been quite slow for roughly the past 12 or so hours? Seems pretty slow. I got 53 new post in the learn group since last night. But only 19 in the D group. -- /Jacob Carlborg
