Re: Can I measure how much memory is used in total, grouped by type?
On Sunday, 11 October 2020 at 20:58:22 UTC, drathier wrote: I think I'm using way to much memory for pointers, so I'd like to see how much of my memory usage is taken up by pointers. I've calculated the answer, but I wonder if the compiler/runtime could do it for me, to get a faster and more exact number? More specifically, can I do this for a single value? E.g. how much memory is used by pointer types in this specific variable?
Can I measure how much memory is used in total, grouped by type?
I think I'm using way to much memory for pointers, so I'd like to see how much of my memory usage is taken up by pointers. I've calculated the answer, but I wonder if the compiler/runtime could do it for me, to get a faster and more exact number?
Re: Timeout around function call
On Wednesday, 23 September 2020 at 20:58:00 UTC, Imperatorn wrote: On Wednesday, 23 September 2020 at 20:54:51 UTC, Imperatorn wrote: On Wednesday, 23 September 2020 at 20:44:51 UTC, Ali Çehreli wrote: On 9/23/20 1:19 PM, Imperatorn wrote: > [...] send a > [...] with timeout. [...] Sorry, I can't see the problem. Could you be more specific about what you want to achieve? Oops, I meant to reply to drathier I need to: - call a side-effect-free fn with a huge argument that I don't want to copy; this argument is then returned mostly unmodified wrapped in a new value - stop executing it if it runs for more than x seconds - get the return value from it if it finishes within x seconds (99.9% of time time) - let the main thread know what happened - the main thread should block until the fn call returns - the fn call should for sure stop executing before the main thread carries on - the size and complexity of the fn makes it pretty much impossible to add timeout checks everywhere to make it exit nicely; I need to kill it to be sure I didn't miss a case
Re: Timeout around function call
On Tuesday, 22 September 2020 at 21:55:51 UTC, Imperatorn wrote: On Tuesday, 22 September 2020 at 09:32:13 UTC, drathier wrote: What's the obvious way to put a timeout around a function call? I'm thinking a 5 or 30 second timeout, and I'm expecting it to pretty much never time out. You have several options. Either you use the actor model (spawn[Linked]) and send a termination message after a specified time. Or you use a task and check for yourTask.done(). Or you could create a Thread and check isRunning. (You didn't specify what you wanted to happen and if blocking was allowed or not) Blocking is perfectly fine. I'm wondering if I need things to be shared now or something? Not used to programming with threads. Adding a shared modifier recursively onto every piece of data that needs it is a ton of work though. I don't want to copy the data around since it's many gigabytes, but I'm sure there won't be any data races; main thread will start 2 threads, one for running the timer and one running the function call. The main thread doesn't access the data until both the timer and function call threads have stopped completely.
Timeout around function call
What's the obvious way to put a timeout around a function call? I'm thinking a 5 or 30 second timeout, and I'm expecting it to pretty much never time out.
Proper way to exit with specific exit code?
What's the proper way to exit with a specific exit code? I found a bunch of old threads discussing this, making sure destructors run and the runtime terminates properly, all of which seemingly concluding that it's sad that there isn't a way to do this easily, but hopefully things have changed in the last 5-10 years and I'm just missing the obvious solution.
Re: std.conv.ConvException from double to uint64_t, but only locally in a large project
Replaced all mentions of uint64_t with ulong, and now it works. Must have an enum called uint64_t defined somewhere in a library I depend on or something? Really wish this was clearer.
Re: std.conv.ConvException from double to uint64_t, but only locally in a large project
On Tuesday, 4 August 2020 at 17:37:56 UTC, drathier wrote: ``` std.conv.ConvException@/usr/local/opt/dmd/include/dlang/dmd/std/conv.d(2054): Value (1596) does not match any member value of enum '__c_ulonglong' ``` well, ``` std.conv.ConvException@/usr/local/opt/dmd/include/dlang/dmd/std/conv.d(2054): Value (42) does not match any member value of enum '__c_ulonglong' ``` but the specific value doesn't matter full stack trace: ``` std.conv.ConvException@/usr/local/opt/dmd/include/dlang/dmd/std/conv.d(2054): Value (42) does not match any member value of enum '__c_ulonglong' source/app.d:864 @safe core.stdc.config.__c_ulonglong std.conv.toImpl!(core.stdc.config.__c_ulonglong, double).toImpl(double) [0x10fa540f8] source/app.d:864 @safe core.stdc.config.__c_ulonglong std.conv.to!(core.stdc.config.__c_ulonglong).to!(double).to(double) [0x10fa54072] source/app.d:262 int app.processFromOffset(std.socket.Socket, app.KafkerMode, app.RuntimeState, core.stdc.config.__c_ulonglong, core.stdc.config.__c_ulonglong) [0x10f9d06b5] source/app.d:175 _Dmain [0x10f9cfcae] ```
Re: std.conv.ConvException from double to uint64_t, but only locally in a large project
``` std.conv.ConvException@/usr/local/opt/dmd/include/dlang/dmd/std/conv.d(2054): Value (1596) does not match any member value of enum '__c_ulonglong' ``` well, ``` std.conv.ConvException@/usr/local/opt/dmd/include/dlang/dmd/std/conv.d(2054): Value (42) does not match any member value of enum '__c_ulonglong' ``` but the specific value doesn't matter
std.conv.ConvException from double to uint64_t, but only locally in a large project
I'm getting a crash when I'm converting a double to an uint64_t. ``` std.conv.ConvException@/usr/local/opt/dmd/include/dlang/dmd/std/conv.d(2054): Value (1596) does not match any member value of enum '__c_ulonglong' ``` I've narrowed down the code to this: ``` static import std.conv; double thing = 42.0; std.conv.to!(uint64_t)(thing); ``` which works just fine on https://run.dlang.io/ or in a single-file dmd invocation. When I compile and run it locally on my mac as part of a specific large app using dub, it always crashes like this. Where would I even start debugging this? DMD64 D Compiler v2.093.0 DUB version 1.22.0, built on Jul 9 2020
Re: dmd release schedule?
On Sunday, 28 June 2020 at 10:44:26 UTC, drathier wrote: Is there a release schedule anywhere for DMD? Any list of tasks to be the next release? I'm only finding 5+ year old things when searching. Yes: https://dlang.org/changelog/release-schedule.html
dmd release schedule?
Is there a release schedule anywhere for DMD? Any list of tasks to be the next release? I'm only finding 5+ year old things when searching.
Re: Recursive delegate inside template?
On Friday, 26 June 2020 at 15:10:07 UTC, Adam D. Ruppe wrote:
On Friday, 26 June 2020 at 14:12:00 UTC, drathier wrote:
I'm trying to get this to compile, without much luck:
You might be able to make it a function:
bool foo()
{
auto fn(A)()
{
A delegate(A) fn;
fn = delegate A(A a)
{
return fn(a);
};
return fn;
}
return fn!(bool)()(true);
}
I tried this, but it gives me `Error: non-constant expression
` which I don't understand. Is ctfe kicking in even though
this is inside a function?
```
void foo2()
{
auto fn(A) = std.functional.toDelegate(({
A fn(A)(A a)
{
return a;
}
return !(A);
}()));
}
```
but I need the function to be polymorphic, so I need the
template.
I don't really understand your need though, can you post more
context?
I'm generating code, compiling a strict pure functional language
to D. The code that I'm trying to compile is this example
function:
```
fn a =
let
_ = fn a
in a
```
which gets the type `forall a. a -> a` inferred.
That's something like
```
A delegate(A) fn(A) = delegate A (A a)
{
auto _ = fn!(A)(a);
return a;
};
```
in D syntax, if it would compile. Well, it compiles, but the
linker fails `error: TLS relocation against invalid instruction`.
It's a simplified example that still tests these features:
- recursion
- polymorphism
- functions as values (closures/delegates)
Recursive delegate inside template?
I'm trying to get this to compile, without much luck:
```
bool foo()
{
template fn(A)
{
A delegate(A) fn;
fn = delegate A(A a)
{
return fn(a);
};
}
return fn!(bool)(true);
}
```
What am I missing here? How can I define a recursive delegate
inside another function like this? I even got a gold linker error
from run.dlang.io at one point: "TLS relocation against invalid
instruction".
Removing the template works fine:
```
bool foo()
{
alias A = bool;
A delegate(A) fn;
fn = delegate A(A a) { return fn(a); };
return fn(true);
}
```
but I need the function to be polymorphic, so I need the template.
Unused template arguments; what type to use?
How can I tell the compiler that I will never create a value of type X, while still being able to write code that uses it? Using void as a template parameter is where I started, but I still need to be able to declare variables inside this unreachable function, like `T foo;` even when `T == void`. Can I get any closer to what I want than an empty struct?
Re: Fastest way to check using if identifier has already been defined, using static if or similar?
On Wednesday, 3 June 2020 at 09:03:22 UTC, drathier wrote:
I'm generating some code. Some of the generated types need to
be overridden, so I define them manually at the top of the
generated file. Then I need to guard against redefining the
identifier (type/value/function) later on, in the generated
code.
I'm currently using `static if (!__traits(compiles, thingy)) {`
to avoid redefining things twice.
Of course the proper fix is to not generate code for the
identifiers which are already manually defined, and not
generate any `static if`s at all, but until then, is there a
faster way than `static if (__traits(compiles, ...` to check if
a type/value/function has already been defined?
This seems more complicated than I initially assumed. Is there a
faster way if we separate the question to find just one of types,
templates or top-level values at a time, into three different
solutions? The definitions and static ifs are always always top
level definitions/statements in my case.
Re: Is there a list of things which are slow to compile?
On Wednesday, 3 June 2020 at 17:02:35 UTC, H. S. Teoh wrote: On Wed, Jun 03, 2020 at 09:36:52AM +, drathier via Digitalmars-d-learn wrote: I'm wondering if there's a place that lists things which are slower/faster to compile? DMD is pretty famed for compiling quickly, but I'm not seeing particularly high speed at all, and I want to fix that. The two usual culprits are: - Recursive/chained templates - Excessive CTFE ... T Thanks for the comprehensive answer! I'm not using CTFE at all, because as you thought, Variants aren't supported in CTFE. I had to go out of my way to avoid CTFE running, since it crashes on Variants. I'm not using UFCS, and the long identifiers I was talking about are like 50 characters long, from mangling package name + module name + variable name together in the source language. I'm guessing it's mainly templates from my code gen then, and there's not much I can do about that; I'm doing code gen from a functional language where polymorphism is literally everywhere, and so are templates then. Regarding std.format, std.regex and such, would it be possible to put those into their own package or something, so `dub` doesn't rebuild them every time? It feels like that'd save a lot of time.
Re: Is there a list of things which are slow to compile?
On Wednesday, 3 June 2020 at 09:36:52 UTC, drathier wrote: Currently at ~1ksloc/s of d input without optimizing anything, which corresponds to 350ksloc/s if measuring by `-vcg-ast` output instead of d source input, while using the same time measurement from before, so the flag doesn't cost time. Sorry, that should read `44ksloc/s`, not `350ksloc/s`.
Is there a list of things which are slow to compile?
I'm wondering if there's a place that lists things which are slower/faster to compile? DMD is pretty famed for compiling quickly, but I'm not seeing particularly high speed at all, and I want to fix that. Currently at ~1ksloc/s of d input without optimizing anything, which corresponds to 350ksloc/s if measuring by `-vcg-ast` output instead of d source input, while using the same time measurement from before, so the flag doesn't cost time. Here's my learnings so far: - CTFE is obviously unboundedly slow, since it runs arbitrary code - Template expansion is presumably O(n) in the size of the generated code, and the `-vcg-ast` flag helps a bit to see how much it's expanding. I'm not convinced it's the reason my code compiles slowly, though. - no idea how expensive static if's on traits are - std.regex compiles really slowly - CTFE always runs on all top-level value definitions (even if they contain things which cannot be executed at compile-time, and I hate this so so much) What other things are there? - identifier lengths? - comments? - aliases? - delegates? - Variants?
Fastest way to check using if identifier has already been defined, using static if or similar?
I'm generating some code. Some of the generated types need to be
overridden, so I define them manually at the top of the generated
file. Then I need to guard against redefining the identifier
(type/value/function) later on, in the generated code.
I'm currently using `static if (!__traits(compiles, thingy)) {`
to avoid redefining things twice.
Of course the proper fix is to not generate code for the
identifiers which are already manually defined, and not generate
any `static if`s at all, but until then, is there a faster way
than `static if (__traits(compiles, ...` to check if a
type/value/function has already been defined?
Re: Order of static this() execution?
On Sunday, 23 February 2020 at 14:36:56 UTC, Johan Engelen wrote: It's not clear from the language specification, but in this case with templates, I am not surprised that the order of execution is not the same as in the source file. Probably it does fit with the order in the source file if you take into account where the template is instantiated in that file (but you shouldn't depend on that). I strongly recommend not to depend on the order of multiple static this execution, by either rewriting things or by including some logic to make sure things are called in the right order (checking that something has already run, and running it if not, or cancel running it if it already ran) -Johan This is generated code, so all defs are already topo-sorted. The template is instantiated before it's used, and in the .d.cg file it's also seemingly in the expected order. I'd be happy to put all initialisation code into a single static this(), but I'm not sure how to do that when templates get involved. Since it's generated code, the set of things that are easy/hard to do kinda swap around.
Re: Order of static this() execution?
On Sunday, 23 February 2020 at 11:41:25 UTC, Johan Engelen wrote:
On Sunday, 23 February 2020 at 09:59:45 UTC, drathier wrote:
I'm having some trouble with the order in which `static
this()` runs. This is the order defined in the source file,
numbered for convenience:
To avoid confusion: you have all `static this()` in a single
source file? Or across several source files?
-Johan
They're all in a single source file. The `[template]` prints are
inside templates, like this:
```
template none(msg) {
T!(msg) none;
static this() {
none = ((std.functional.toDelegate(!(msg) )))(X!(T!(msg)
));
}
}
```
The whole reason I have `static this()` is to avoid ctfe crashing
from trying to run `toDelegate` at compile time:
```
std/functional.d(1501,22): Error: dummyDel.funcptr cannot be
evaluated at compile time
```
Re: Order of static this() execution?
Well, like this, rather:
```
template none(msg) {
T!(msg) none;
static this() {
logInfo("static this 4 cmd none [template:%s]", typeid(msg));
none = ((std.functional.toDelegate(!(msg)
)))(X!(T!(msg) ));
logInfo("static this 4 cmd none [template:%s] done",
typeid(msg));
}
}
```
Re: Speeding up compilation of template-heavy code
On Saturday, 22 February 2020 at 17:44:52 UTC, Stefan Koch wrote: no. -vcg-ast runs directly before codegen. All ast-rewriteing has already happend at that point. The reason it contains the template declarations is because they are still in the ast. There is no point in removing them. Thanks, I didn't even consider the possibility of a compiler mutating the ast in-place. Spent too much time writing Haskell, I guess.
Order of static this() execution?
I'm having some trouble with the order in which `static this()`
runs. This is the order defined in the source file, numbered for
convenience:
```
logInfo("static this 1 initialModel");
logInfo("static this 1 initialModel done");
logInfo("static this 2 array branchfactor");
logInfo("static this 2 array branchfactor done");
logInfo("static this 3 array shiftstep");
logInfo("static this 3 array shiftstep done");
logInfo("static this 4 cmd none [template:%s]", typeid(msg));
logInfo("static this 4 cmd none [template:%s] done", typeid(msg));
logInfo("static this 5 main");
logInfo("static this 5 main done");
```
It's also the same order that `-vcg-ast` outputs. However, at
runtime, I'm consistently seeing this order, where 5 and 4 are
swapped:
```
[main() INF] static this 1 initialModel
[main() INF] static this 1 initialModel done
[main() INF] static this 2 array branchfactor
[main() INF] static this 2 array branchfactor done
[main() INF] static this 3 array shiftstep
[main() INF] static this 3 array shiftstep done
[main() INF] static this 5 main
[main() INF] static this 5 main done
[main() INF] static this 4 cmd none
[template:delm.output.MsgT]
[main() INF] static this 4 cmd none
[template:delm.output.MsgT] done
```
which leads to segfaults later on since static this 5 reads
variables set up by static this 4.
The spec says that "The static constructors are run in lexical
order" https://dlang.org/spec/module.html#staticorder . Is
lexical order the same as the order things are defined in the
source file?
I'm running `DMD64 D Compiler v2.090.1` on macos 10.14.6, in case
that matters. I'm seeing the same issue with LDC `(1.19.0) based
on DMD v2.089.1 and LLVM 9.0.0`
Re: Speeding up compilation of template-heavy code
On Saturday, 22 February 2020 at 11:53:38 UTC, Dennis wrote: On Saturday, 22 February 2020 at 11:26:19 UTC, Per Nordlöw wrote: Is there a dmd flag that shows the code after template instantiations has been performed? The -vcg-ast flag does that. The d.cg files still contain templates, so it appears like they're instantiated after -vcg-ast?
