Re: Convert array to custom type when passing function argument
On Wednesday, 17 April 2019 at 23:44:42 UTC, Adam D. Ruppe wrote:
In C++, if you define a struct/class, and constructors apply
for this.
struct Test {
Test(const char* foo) {}
};
void cool(Test t) {}
cool("string"); // works
That works in C++, unless you mark that constructor with
`explicit`
struct Test {
explicit Test(const char* foo) {} // this opts out of the
cool thing above
};
Yes, thanks. :)
Actually, I asked initially because in C++ you can do the thing I
described.
I thought that you meant something I missed with out-out.
- Stefanos
Re: How to debug long-lived D program memory usage?
On Wednesday, 17 April 2019 at 23:57:41 UTC, Meta wrote: Not at all what you want, but it may be useful for figuring out where the leaks are. Have you tried compiling with -vgc? That wouldn't help me much here because I know parts are GC allocating, and I'm ok with that. What I want to know are the parts the GC is not collecting for whatever reason. These parts may be malloc'd too; it isn't necessary the GC's fault.
Re: How to debug long-lived D program memory usage?
On Wednesday, 17 April 2019 at 22:37:38 UTC, Adam D. Ruppe wrote: On Wednesday, 17 April 2019 at 19:07:46 UTC, Jacob Carlborg wrote: Perhaps try some of these flags [1] and [2]. oooh, those are very interesting too. What I was kinda hoping is it would have stats for which file and line of code was responsible for most allocations; a detailed profile. But even so, this is an interesting gem. Not at all what you want, but it may be useful for figuring out where the leaks are. Have you tried compiling with -vgc? https://dlang.org/dmd-windows.html#switch-vgc
Re: Convert array to custom type when passing function argument
On Wednesday, 17 April 2019 at 23:26:16 UTC, Stefanos Baziotis
wrote:
I argue C++'s mistake was *out-out* implicit construction
What do you mean by out-out?
In C++, if you define a struct/class, and constructors apply for
this.
struct Test {
Test(const char* foo) {}
};
void cool(Test t) {}
cool("string"); // works
That works in C++, unless you mark that constructor with
`explicit`
struct Test {
explicit Test(const char* foo) {} // this opts out of the cool
thing above
};
Re: Convert array to custom type when passing function argument
On Wednesday, 17 April 2019 at 16:33:17 UTC, Adam D. Ruppe wrote: [...] Thanks for the info! I argue C++'s mistake was *out-out* implicit construction What do you mean by out-out? - Stefanos
Re: How to debug long-lived D program memory usage?
On Wednesday, 17 April 2019 at 19:07:46 UTC, Jacob Carlborg wrote: Perhaps try some of these flags [1] and [2]. oooh, those are very interesting too. What I was kinda hoping is it would have stats for which file and line of code was responsible for most allocations; a detailed profile. But even so, this is an interesting gem. There's no documentation and there's no generic `--DRT-help` flag. It's a mess. Indeed, we need to fix that. But I'm too lazy to do it myself :(
Re: How to debug long-lived D program memory usage?
On Wednesday, 17 April 2019 at 16:57:51 UTC, Julian wrote: It might be something obvious on visual inspection. Huh, indeed this got me the biggest obvious-in-retrospect-but-i-didnt-think-to-look-there win of the day - the memory dump showed a super-bloated scrollback buffer in my terminal emulator. I removed 24 bit color support and slashed that in half, then instituted some limits to bring the peak down a bit more. Still have more to go, but this little thing actually added up to a whopping gigabyte across my whole system. You can dump memory with thanks for the tip!
Re: How to debug long-lived D program memory usage?
On Wednesday, 17 April 2019 at 17:03:20 UTC, Martin Krejcirik wrote: Do you run GC.minimize ? Not explicitly, but I did try `call gc_minimize()` from the debugger when attached to processes and it made no difference. Maybe I'll add a hook to the program to call that on a hotkey press for the future though, I can see some situations where it might make a difference. (though I'd be kinda surprised if it didn't at least sometimes run automatically...)
Re: How to debug long-lived D program memory usage?
On 2019-04-17 18:27, Adam D. Ruppe wrote: I am willing to recompile and run again, though I need to actually use the programs, so if instrumenting makes them unusable it won't really help. Is there a magic --DRT- argument perhaps? Or some trick with gdb attaching to a running process I don't know? Perhaps try some of these flags [1] and [2]. I tried to look for other `--DRT-` flags but unfortunately it's spread across the druntime code base and not handled in a single place. There's no documentation and there's no generic `--DRT-help` flag. It's a mess. [1] https://dlang.org/changelog/2.067.0.html#gc-options [2] https://dlang.org/changelog/2.068.0.html#gc-api-profile -- /Jacob Carlborg
Re: How to debug long-lived D program memory usage?
On Wednesday, 17 April 2019 at 16:27:02 UTC, Adam D. Ruppe wrote: Each individual process eats ~30-100 MB, but that times 60 = trouble. They start off small, like 5 MB, and grow over weeks or months, so it isn't something I can easily isolate in a Do you run GC.minimize ?
Re: How to debug long-lived D program memory usage?
On Wednesday, 17 April 2019 at 16:27:02 UTC, Adam D. Ruppe wrote: D programs are a vital part of my home computer infrastructure. I run some 60 D processes at almost any time and have recently been running out of memory. Each individual process eats ~30-100 MB, but that times 60 = trouble. They start off small, like 5 MB, and grow over weeks or months, so it isn't something I can easily isolate in a debugger after recompiling. I'm pretty sure this is the result of wasteful code somewhere in my underlying libraries, but nothing is obviously jumping out at me in the code. So I want to look at some of my existing processes and see just what is responsible for this. I tried attaching to one and `call gc_stats()` in gdb... and it segfaulted. Whoops. I am willing to recompile and run again, though I need to actually use the programs, so if instrumenting makes them unusable it won't really help. Is there a magic --DRT- argument perhaps? Or some trick with gdb attaching to a running process I don't know? What I'm hoping to do is get an idea of which line of code allocates the most that isn't subsequently freed. One thing you can try, without recompiling, is using pmap -x on one of the bloated processes, and then dumping a large memory region to file, and then just looking at the binary. It might be something obvious on visual inspection. You can dump memory with gdb -p $pid --eval-command 'dump binary memory file.bin 0xfromLL 0xtoLL' -batch
Re: Convert array to custom type when passing function argument
On Wednesday, 17 April 2019 at 15:23:06 UTC, Stefanos Baziotis wrote: Sorry if this has been asked again, I didn't find anything. Do we know the reason why it is not supported? Basically implicit construction was considered a mistake in C++ and D didn't want to repeat that mistake. Most code guides for C++ say to always (or almost always) mark your constructors with `explicit`, so D just makes that the only option. I argue C++'s mistake was *out-out* implicit construction, not the concept in general - I kinda wish D would allow it if you specifically asked for it in the type. Walter also says though implicit construction complicates function overloading rules and compiler error messages, and he doesn't think it is worth the cost to even try it with a new keyword (IIRC, I haven't had this chat with him for a while, so I might be misremembering). Again, his experience with it in C++ on several levels was negative and he wanted to simplify D so people are more likely to do the right thing. I actually agree with him 90% of the time... just I wish it was available there for the other cases still.
How to debug long-lived D program memory usage?
D programs are a vital part of my home computer infrastructure. I run some 60 D processes at almost any time and have recently been running out of memory. Each individual process eats ~30-100 MB, but that times 60 = trouble. They start off small, like 5 MB, and grow over weeks or months, so it isn't something I can easily isolate in a debugger after recompiling. I'm pretty sure this is the result of wasteful code somewhere in my underlying libraries, but nothing is obviously jumping out at me in the code. So I want to look at some of my existing processes and see just what is responsible for this. I tried attaching to one and `call gc_stats()` in gdb... and it segfaulted. Whoops. I am willing to recompile and run again, though I need to actually use the programs, so if instrumenting makes them unusable it won't really help. Is there a magic --DRT- argument perhaps? Or some trick with gdb attaching to a running process I don't know? What I'm hoping to do is get an idea of which line of code allocates the most that isn't subsequently freed.
Re: Convert array to custom type when passing function argument
On Wednesday, 17 April 2019 at 12:48:52 UTC, Adam D. Ruppe wrote:
This is the "implicit construction" I sometimes talk about
and D doesn't support it, by design (alas).
Sorry if this has been asked again, I didn't find anything.
Do we know the reason why it is not supported?
There's two options you can do:
1) offer an overload to your function that does the conversion:
void test(Buf!int arr) { /* impl here */ }
void test(int[] arr) { test(Buf!int(arr)); } // just forward to
the other
or
2) Offer a helper construction function you can call, like:
Buf!int toBuf(int[] a) { return Buf!int(a); }
and then you can call the function like
test([1, 2, 3].toBuf); // calling your function at the end
Yes, I had done the 2), which means for 50 functions, I have
another 50 functions.
Because of the constructor these are one-liners but still, it's
kind of ugly.
I didn't know about the 3) thanks! I think it's not a very good
solution for this
kind of problems but cool otherwise.
- Stefanos
Re: Instantiating an Object with the Same Object as an Argument?
btw if you haven't seen my version of the gtk-d docs, check it out: http://gtk-d.dpldocs.info/gtk.Adjustment.Adjustment.html It does various cross-referencing the official versions don't, among other things. You can see the GtkAdjustment there is not linked, because it is the C version, whereas references to gtk.Adjustment are links to the D classes.
Re: Instantiating an Object with the Same Object as an Argument?
On Wednesday, 17 April 2019 at 15:05:22 UTC, Adam D. Ruppe wrote: On Wednesday, 17 April 2019 at 14:49:33 UTC, Ron Tarrant wrote: For instance, one of the Adjustment constructors looks like this: public this(GtkAdjustment* gtkAdjustment, bool ownedRef Those aren't the same thing! One is Adjustment, the D wrapper class, and the other is GtkAdjustment*, the C structure pointer. This constructor is for cases when you have an existing object made via the C api and you want the D wrapper to adopt it. Ah! Thanks for clearing that up, Adam. I shall go blush now for not reading more closely.
Re: Instantiating an Object with the Same Object as an Argument?
On Wednesday, 17 April 2019 at 14:49:33 UTC, Ron Tarrant wrote: For instance, one of the Adjustment constructors looks like this: public this(GtkAdjustment* gtkAdjustment, bool ownedRef Those aren't the same thing! One is Adjustment, the D wrapper class, and the other is GtkAdjustment*, the C structure pointer. This constructor is for cases when you have an existing object made via the C api and you want the D wrapper to adopt it.
Instantiating an Object with the Same Object as an Argument?
I've come across this a few times in the wrapper code for GtkD
where one of the constructors for an object takes an argument of
the same type the constructor produces.
For instance, one of the Adjustment constructors looks like this:
public this(GtkAdjustment* gtkAdjustment, bool ownedRef = false)
{
this.gtkAdjustment = gtkAdjustment;
super(cast(GObject*)gtkAdjustment, ownedRef);
}
I have a vague memory of finding out how to use this type of
constructor from a while back, but I can't remember how. And if I
did find out, I neglected to take notes, apparently (shame on me)
but I may also have dreamed it.
And I can't find a cogent example.
At first glance, this form of constructor seems impossible to
use. I mean, how can I instantiate an object passing the object
(which doesn't exist) as an argument?
Or is this not actually a constructor?
Or maybe there's some magic going on here that I'd understand if
I knew D better?
I keep running across this, so I'm hoping someone can give me a
leg up.
Re: Convert array to custom type when passing function argument
On Wednesday, 17 April 2019 at 12:20:49 UTC, Stefanos Baziotis
wrote:
I want to be able to make it work array-like to have compact
function calls.
Something like this:
test([1,2,3]);
This is the "implicit construction" I sometimes talk about
and D doesn't support it, by design (alas).
There's two options you can do:
1) offer an overload to your function that does the conversion:
void test(Buf!int arr) { /* impl here */ }
void test(int[] arr) { test(Buf!int(arr)); } // just forward to
the other
or
2) Offer a helper construction function you can call, like:
Buf!int toBuf(int[] a) { return Buf!int(a); }
and then you can call the function like
test([1, 2, 3].toBuf); // calling your function at the end
Convert array to custom type when passing function argument
I have a custom Buf struct (working as a simple vector)
struct Buf(T) {
size_t cap, len;
T *data;
@nogc
this(T[] arr) {
reserve(arr.length);
foreach(item; arr) {
push(item);
}
}
...
};
And I have a function like this:
void test(Buf!(int) buf) {
}
I want to be able to make it work array-like to have compact
function calls.
Something like this:
test([1,2,3]);
Currently I have the constructor shown and with that I do:
test(Buf!(int)([1,2,3]);
which is compact but can it be done differently? Meaning, if a
function takes
a Buf!(T), can it also take a T[] and construct a Buf!(T) using
some constructor?
Thanks in advance!
