Re: Garbage collection and closures.
On Saturday, 17 June 2017 at 17:15:50 UTC, Adam D. Ruppe wrote:
On Saturday, 17 June 2017 at 14:19:34 UTC, ANtlord wrote:
Excuse me, I can't get what does it mean "deepest-referenced".
What the deep you mean? The deep of a closure or deep of the
function where the variable is defined. Can you give an
example code?
Where the variable is defined that is referenced in the closure.
So:
---
void uses(void delegate() dg);
void foo() {
int a;
foreach(b; 0 .. 10) {
uses( () { a++; } ); // #1
uses( () { b++; } ); // #2
}
}
---
In that case, #1 would only be allocated once, at the start of
the foo() function. It only uses `a`, so it doesn't have to
allocate again after the point a is defined.
But #2 might allocate each time through the loop. (It currently
doesn't, but this is filed as an open bug because it is
supposed to.) Since it uses `b` which is defined inside the
loop, it will have to allocate a new copy for each iteration.
Is this function called every time when allocation happens in
a heap?
Not any allocation, it is just the function the compiler uses
when it needs to make a closure.
Thanks a lot, Adam! Everything is clear. Except for the bug. I've
got an expected result of a value of the variable from #2. The
value equals to number from sequence plus one in each iteration.
There are ten iterations.
What's wrong? Are there should be five iterations? It doesn't
make sense for me due to the variable assigned value from the
sequence 0..10. Or do I look at the wrong place? Can you give me
a link to the bug?
Thank you again!
Re: Garbage collection and closures.
On Saturday, 17 June 2017 at 14:19:34 UTC, ANtlord wrote:
Excuse me, I can't get what does it mean "deepest-referenced".
What the deep you mean? The deep of a closure or deep of the
function where the variable is defined. Can you give an example
code?
Where the variable is defined that is referenced in the closure.
So:
---
void uses(void delegate() dg);
void foo() {
int a;
foreach(b; 0 .. 10) {
uses( () { a++; } ); // #1
uses( () { b++; } ); // #2
}
}
---
In that case, #1 would only be allocated once, at the start of
the foo() function. It only uses `a`, so it doesn't have to
allocate again after the point a is defined.
But #2 might allocate each time through the loop. (It currently
doesn't, but this is filed as an open bug because it is supposed
to.) Since it uses `b` which is defined inside the loop, it will
have to allocate a new copy for each iteration.
Is this function called every time when allocation happens in a
heap?
Not any allocation, it is just the function the compiler uses
when it needs to make a closure.
Re: Garbage collection and closures.
On Saturday, 17 June 2017 at 13:13:17 UTC, Adam D. Ruppe wrote: On Saturday, 17 June 2017 at 13:03:28 UTC, ANtlord wrote: Is GC called every iteration of this loop? No, it will once on scope entry; where the deepest-referenced variable that is actually captured is defined. The compiler allocates heap space instead of stack space for the locals, then runs the function normally using that space. Excuse me, I can't get what does it mean "deepest-referenced". What the deep you mean? The deep of a closure or deep of the function where the variable is defined. Can you give an example code? It will only alloc once. You can prove this with a debugger btw, set a breakpoint on `_d_allocmemory`. Is this function called every time when allocation happens in a heap? Thank you. Sorry if my English is not clear.
Re: Garbage collection and closures.
On Saturday, 17 June 2017 at 13:03:28 UTC, ANtlord wrote: Is GC called every iteration of this loop? No, it will once on scope entry; where the deepest-referenced variable that is actually captured is defined. The compiler allocates heap space instead of stack space for the locals, then runs the function normally using that space. The current implementation doesn't quite do this - it actually will alloc only once, on function entry, even when there's a variable inside a loop that is supposed to be independent. This is the cause of the commonly-referenced bug with foreach(i; whatever) capture(i); all showing the same number. When that bug is fixed, it is possible to allocate on each loop... but your code doesn't anyway, so you're ok. It will only alloc once. You can prove this with a debugger btw, set a breakpoint on `_d_allocmemory`.
Garbage collection and closures.
Hello! I can't understand one thing related to closures and
calling of GC. I have the following demo snippet, where a closure
is passed to `receive` function in a loop.
bool isDone = false;
while(!isDone)
receive((bool val){ isDone = val });
Is GC called every iteration of this loop?
I know that I can move the code to a method of a struct and make
the closure and variable "isDone" as fields of the struct. It
avoids GC calling definitely. But I want to get how many times GC
is called in case of a closure in a loop.
Thanks.
Re: Simple c header => Dlang constants using mixins in compile time
On Saturday, 17 June 2017 at 11:23:52 UTC, Cym13 wrote: On Saturday, 17 June 2017 at 11:20:53 UTC, Igor Shirkalin wrote: [...] I'm sure others will have cleaner solutions as as a quick hack you can read the file at compile time, modify it, and compile the D code on the go: [...] Thanks a lot! That what I was looking for.
Re: Simple c header => Dlang constants using mixins in compile time
On Saturday, 17 June 2017 at 11:20:53 UTC, Igor Shirkalin wrote:
On Saturday, 17 June 2017 at 11:10:47 UTC, Igor wrote:
On Saturday, 17 June 2017 at 10:56:52 UTC, Igor Shirkalin
wrote:
Hello!
I have a simple C header file that looks like:
#define Name1 101
#define Name2 122
#define NameN 157
It comes from resource compiler and I need all these
constants to be available in my Dlang program in compile
time. It seems to me it is possible. I know I can simply
write external program (in python, for example) that does it,
but it means I should constantly run it after every change
before D compilation.
Please, can anyone help to direct me how to realize it?
Thank you in advance!
Igor Shirkalin
Maybe I am not quite understanding what you are asking but
can't you just use:
enum Name1 = 101;
enum Name2 = 122;
...
No, I need the original header file to be used in other
applications (say, resource compiler). Therefore this file is
primary. I think some pretty short code can be written in D
that use such a file to generate constants (enum Name1 = 101)
in compile time.
I'm sure others will have cleaner solutions as as a quick hack
you can read the file at compile time, modify it, and compile the
D code on the go:
import std.stdio;
import std.array;
import std.algorithm;
// Normal function that takes a list of #define and
transforms them in enum
// constants textually.
string enumify(string header) {
return header.split("\n")
.filter!(x => x.startsWith("#define Name"))
.map!(x => x.split(" "))
.map!(s => "enum " ~ s[1] ~ " = " ~ s[2] ~
";")
.join("\n");
}
unittest {
string txt = "#define Name1 101\n#define Name2 122";
assert(txt.enumify == "enum Name1 = 101;\nenum Name2 =
122;");
}
/* Our file header.h
#define Name1 101
#define Name2 122
#define Name3 157
*/
// We import the content of the file, enumify it producing D
code, and mix it
// in place to declare our constants.
//
// The string import requires compiling with
-Jpath/to/dir/with/header.h
mixin(enumify(import("header.h")));
void main(string[] args) {
writeln(Name3); // 157 // Yep, that works
pragma(msg, Name2); // 122 // Yep, that works at compile
time too
}
Re: Simple c header => Dlang constants using mixins in compile time
On Saturday, 17 June 2017 at 11:10:47 UTC, Igor wrote: On Saturday, 17 June 2017 at 10:56:52 UTC, Igor Shirkalin wrote: Hello! I have a simple C header file that looks like: #define Name1 101 #define Name2 122 #define NameN 157 It comes from resource compiler and I need all these constants to be available in my Dlang program in compile time. It seems to me it is possible. I know I can simply write external program (in python, for example) that does it, but it means I should constantly run it after every change before D compilation. Please, can anyone help to direct me how to realize it? Thank you in advance! Igor Shirkalin Maybe I am not quite understanding what you are asking but can't you just use: enum Name1 = 101; enum Name2 = 122; ... No, I need the original header file to be used in other applications (say, resource compiler). Therefore this file is primary. I think some pretty short code can be written in D that use such a file to generate constants (enum Name1 = 101) in compile time.
Re: Simple c header => Dlang constants using mixins in compile time
On Saturday, 17 June 2017 at 10:56:52 UTC, Igor Shirkalin wrote: Hello! I have a simple C header file that looks like: #define Name1 101 #define Name2 122 #define NameN 157 It comes from resource compiler and I need all these constants to be available in my Dlang program in compile time. It seems to me it is possible. I know I can simply write external program (in python, for example) that does it, but it means I should constantly run it after every change before D compilation. Please, can anyone help to direct me how to realize it? Thank you in advance! Igor Shirkalin Maybe I am not quite understanding what you are asking but can't you just use: enum Name1 = 101; enum Name2 = 122; ...
Simple c header => Dlang constants using mixins in compile time
Hello! I have a simple C header file that looks like: #define Name1 101 #define Name2 122 #define NameN 157 It comes from resource compiler and I need all these constants to be available in my Dlang program in compile time. It seems to me it is possible. I know I can simply write external program (in python, for example) that does it, but it means I should constantly run it after every change before D compilation. Please, can anyone help to direct me how to realize it? Thank you in advance! Igor Shirkalin
Re: GStreamer and D
On 06/17/2017 01:34 AM, Jay Norwood wrote:
gst_plugin_feature_get_name
This is a macro, the alternative:
```
import gobject.Value;
Value name;
feature.getProperty("name", name);
name.getString();
```
or if you don't want to use GValue.
```
to!string((cast(GstObject)feature.getPluginFeatureStruct()).name);
```
g_list_next
https://github.com/gtkd-developers/GtkD/blob/master/generated/gtkd/glib/ListG.d#L75
g_return_if_fail
Also a macro, witch basically does this:
```
if ( !expression )
return;
```
g_value_get_boolean
https://github.com/gtkd-developers/GtkD/blob/master/generated/gtkd/gobject/Value.d#L245
--
Mike Wey
Re: Calling delegate in a dll callback fails silently
On Saturday, 17 June 2017 at 03:35:42 UTC, Adam D. Ruppe wrote: On Friday, 16 June 2017 at 22:17:07 UTC, Andre Pany wrote: [...] What is the type of dg there? This looks horribly, horribly wrong to me. [...] Thanks a lot for the explanation and the link. Now it makes sense why it not works. Kind regards André
