How make Executable Dlang EXE ask for "Run as Administrator"?
I created a program in Dlang and compiled to exe using dmd. But my program need administrator privileges. How can I make executable dlang program ask for administrator privileges on start up program?
Re: Is it possible to use DMD as a library to compile strings at runtime?
On Friday, 31 January 2020 at 14:25:30 UTC, Basile B. wrote: On Friday, 31 January 2020 at 11:19:37 UTC, Saurabh Das wrote: [...] Fundamentally DMD as a library is a front-end. Jitting is to the backend side. You'll be able to lex and parse the source to get an AST, to perform the semantic passes on this AST and that's all. Then to run this code you would need to make an AST visitor that will generate the binary code to execute. Even using a specialized library with jitting abilities, such as LLVM-d [1] or libfirm-d [2], this would be *quite* a journey. [1] https://github.com/MoritzMaxeiner/llvm-d [2] https://gitlab.com/basile.b/libfirm-d Thank you. That's enough to get me started tinkering! Saurabh
Re: Cannot implicitly convert expression [[0, -1, 2], [4, 11, 2]] of type int[][] to const(int[2])[]
On Friday, January 31, 2020 5:43:44 AM MST MoonlightSentinel via Digitalmars-d-learn wrote: > On Friday, 31 January 2020 at 12:37:43 UTC, Adnan wrote: > > What's causing this? > > You mixed up the array lengths: > > const int[3][2] matA = [[0, -1, 2], [4, 11, 2]]; > const int[2][3] matB = [[3, -1], [1, 2], [6, 1]]; > > matA is an SA containing <2> elements of type int[3]. > matB is an SA containing <3> elements of type int[2]. Specifically, the dimensions are read outwards from the variable name, so on the left-hand side, that means that they go right-to-left, whereas on the right-hand side, they go left-to-right. This is consistent with how it works with types in C/C++ except that there, they put the dimensions for static arrays on the right-hand side of the variable name, meaning that while you have to read stuff like pointer types from left-to-right in C/C++, you don't have to do that with static arrays. Ultimately, what D is doing is consistent but confusing. e.g. For C/C++ int** foo; // A pointer to a pointer to an int int foo[5][2]; // A 5 dimensional array of two dimensional arrays of int foo[4][1] = 7; and for D: int** foo; // A pointer to a pointer to an int int[2][5] foo; // A 5 dimensional array of two dimensional arrays of int foo[4][1] = 7; For C/C++, you often don't realize how the rules work until you have to read function pointers, because they put the static array lengths no the right-hand side, and they actually allow you to put stuff like const in multiple places instead of only in the place where it would be right right-to-left. e.g. if the rule were followed strictly, const int i = 0; wouldn't be legal in C/C++. Rather, it would have to be int const i = 0; In reality, both work, but people end up using the first one. So, ultimately, it adds to the confusion when dealing with more complex tyypes. D doesn't have that problem, but since it used parens with type qualifiers, it forces const to go on the left, making it less consistent. e.g. const int i = 0; or const(int) i = 0; So, neither C/C++ nor D is entirely consistent, but the basic rule is that types are read outwards from the variable name, which is why you get the weirdness with static array dimensions in D. - Jonathan M Davis
Re: Constant GC allocations when sending large messages to threads?
On 1/31/20 2:14 AM, cc wrote: On Wednesday, 29 January 2020 at 21:10:53 UTC, Steven Schveighoffer wrote: I'm pretty sure std.concurrency uses Variant to pass message data, which boxes when it gets over a certain size. You are probably crossing that threshold. The allocations should level out eventually when the GC starts collecting them. Is there a way to pre-allocate a buffer or something to be used? Ideally I'd like to avoid too many garbage collections happening, in my application these thread messages happen almost every frame and are quickly adding up to 100s of kilobytes in allocations every few seconds. You could use RefCounted to build a struct that then is sendable with the data you need. RefCounted allocates using C malloc, not the GC. It might actually be reasonable to modify std.concurrency to use RefCounted instead of GC memory (i.e. it needs to be a specialized Variant). -Steve
Re: Template Usage with Eponymous Trick
On 1/30/20 9:10 AM, ShadoLight wrote: Why does the 'classical' template calling convention not work anymore in this case? (if the template name and function name are different it obviously still works). Note the templates were not defined in the simplified 'Eponymous Trick' style i.e.: I know your question is pretty much answered, but to give you some historical perspective, the long form WAS allowed in the past (it may still be that way in D1), and I think there were ambiguity problems as described. So you can no longer do that. It was actually much more restrictive before -- e.g. in order to do an eponymous template, you could have no other members in the template. Probably we should adjust the examples to remove those that no longer work. -Steve
Re: iopipe: Writing output to std.io File
On 1/30/20 12:59 AM, Jesse Phillips wrote: On Tuesday, 28 January 2020 at 16:09:55 UTC, Steven Schveighoffer wrote: Everything is pulled with iopipe, even output, so it's just a matter of who is pulling and when. Pushing is a matter of telling the other end to pull. That statement I think will be very helpful to me. The push would control the buffer, creating that value concept, where the buffer is flush which creates a pull, specified in the delegate. The push function divides the buffer into 2 parts, the "writeable" items (i.e. items ready to push), and the buffer that can be accessed for manipulation (this is where you put your data). Eventually, the latter fills up and you need more buffer space. At this point, it performs the push, which is done by running the push chain as if it were an input stream, where the data source is the writeable data. Pusher(buffer) <- put(content) An output range wrapper would provide a push interface which would fill in the buffer of the Pusher. When the buffer fills the range wrapper would ask to release which Pusher does by calling the delegate. An output range wrapper should fill in the accessible buffer and then immediately release it (same as that writeln example I showed before). Hopefully I'm following this correctly. I was going to write an ascii art concept to show how the pushing works, but I think I'll maybe draw an actual picture. I need some time to accomplish this, though. It's very clear in my head how this works, but very hard to describe :) -Steve
Re: Is it possible to use DMD as a library to compile strings at runtime?
On Friday, 31 January 2020 at 11:19:37 UTC, Saurabh Das wrote: I see that DUB has DMD as a library package, but I was not able to understand how to use it. Is it possible to use DMD as a library within a D program to compile a string to machine code and run the compiled code at runtime? Thanks, Saurabh Fundamentally DMD as a library is a front-end. Jitting is to the backend side. You'll be able to lex and parse the source to get an AST, to perform the semantic passes on this AST and that's all. Then to run this code you would need to make an AST visitor that will generate the binary code to execute. Even using a specialized library with jitting abilities, such as LLVM-d [1] or libfirm-d [2], this would be *quite* a journey. [1] https://github.com/MoritzMaxeiner/llvm-d [2] https://gitlab.com/basile.b/libfirm-d
Re: DMD won't compile re-init of variable
On Thursday, 30 January 2020 at 21:36:53 UTC, Adam D. Ruppe wrote: On Thursday, 30 January 2020 at 21:09:41 UTC, Simon wrote: How do I revert my variable to the init state? null is the initial state for those. More generally, .init can be used as to get the initial state for any type. ie. m_string2edge = typeof(m_string2edge).init;
Re: Cannot implicitly convert expression [[0, -1, 2], [4, 11, 2]] of type int[][] to const(int[2])[]
On Friday, 31 January 2020 at 12:37:43 UTC, Adnan wrote: What's causing this? You mixed up the array lengths: const int[3][2] matA = [[0, -1, 2], [4, 11, 2]]; const int[2][3] matB = [[3, -1], [1, 2], [6, 1]]; matA is an SA containing <2> elements of type int[3]. matB is an SA containing <3> elements of type int[2].
Cannot implicitly convert expression [[0, -1, 2], [4, 11, 2]] of type int[][] to const(int[2])[]
https://wiki.dlang.org/Dense_multidimensional_arrays#Static_arrays describes a way to create static arrays: int[3][3] matrix = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ]; However my complains that I can't implicitly create static arrays from dynamic arrays. private T[R1][C2] loopMul(ulong R1, ulong C1, ulong R2, ulong C2, T)( auto ref T[R1][C1] matrixA, auto ref T[R1][C2] matrixB) if (C1 == R2) { T[R1][C2] result; for (ulong r = 0; r < R1; ++r) { for (ulong c = 0; c < C2; ++c) { T toAdd = 0; for (ulong n = 0; n < C1; ++n) { toAdd += matrixA[r][n] + matrixB[c][n]; } result[r][c] = toAdd; } } } void main() { import std; scope (success) std.writeln("loopMul -- ok"); // assert([[0, -1, 2], [4, 11, 2]].loopMul!(2, 3, 3, 2, int)([[3, -1], [1, 2], [6, 1]]) == [ // [11, 0], [35, 20] // ]); const int[2][3] matA = [[0, -1, 2], [4, 11, 2]]; const int[3][2] matB = [[3, -1], [1, 2], [6, 1]]; const int[2][2] matC = [[11, 0], [35, 20]]; assert(matA.loopMul(matB) == matC); } /// I would share the D online editor link but `shorten` button doesn't do anything onlineapp.d(24): Error: cannot implicitly convert expression [[0, -1, 2], [4, 11, 2]] of type int[][] to const(int[2])[] onlineapp.d(25): Error: cannot implicitly convert expression [[3, -1], [1, 2], [6, 1]] of type int[][] to const(int[3])[] onlineapp.d(27): Error: template onlineapp.loopMul cannot deduce function from argument types !()(const(int[2][3]), const(int[3][2])), candidates are: onlineapp.d(1):loopMul(ulong R1, ulong C1, ulong R2, ulong C2, T)(auto ref T[R1][C1] matrixA, auto ref T[R1][C2] matrixB) What's causing this?
Re: books for learning D
On Friday, 31 January 2020 at 10:51:07 UTC, mark wrote: On Wednesday, 29 January 2020 at 11:57:14 UTC, Jan Hönig wrote: On Monday, 13 January 2020 at 16:37:31 UTC, Ron Tarrant wrote: On Monday, 13 January 2020 at 10:28:48 UTC, mark wrote: [...] Actually, Andrei's book has been updated a few times over the years since first being published. The latest version says this on the copyright page: D version: 2.081.1 Book revision: 2018-10-17 So, it's really only about 14 months old. I am also curious. Where can i find the revised book. I'd also like to know where the revised "The D Programming Language" by Andrei Alexandrescu is: and whether it can be bought in physical form? I think Ron confused Ali's book and Andrei's book.
Is it possible to use DMD as a library to compile strings at runtime?
I see that DUB has DMD as a library package, but I was not able to understand how to use it. Is it possible to use DMD as a library within a D program to compile a string to machine code and run the compiled code at runtime? Thanks, Saurabh
Re: wordladder - code improvement
On 2020-01-31 09:44, mark via Digitalmars-d-learn wrote: I can't use the levenshtien distance because although it is a better solution, [...] Nah, it isn't, sorry for the noise, should have slept before sending the message, was thinking of hamming distance: auto a = "abcd"; auto b = "bcda"; auto hammingDistance(string a, string b) { return zip(a, b).count!(t => t[0] != t[1]); } levenshteinDistance(a, b).writeln; // => 2 hammingDistance(a, b).writeln; // => 4 main() [...] doesn't match the behaviour There's also std.range.tee if you ever need to perform additional side-effects in a range pipeline, which restores the original dot printing: write("Try "); auto res = generate!(() => genLadder(words.dup, STEPS)) .enumerate(1) .tee!(_ => write('.'), No.pipeOnPop) // No.pipeOnPop ensures we're not one dot short .find!(a => !a[1].empty) .front; writeln(" ", res[0]); genLadder() [...] is so compact. Thinking about it, you could even eliminate the prev variable all together when using ladder.back in compWords. Regarding const correctness, this article and thread might contain useful information: https://forum.dlang.org/thread/2735451.YHZktzbKJo@lyonel By the way, keep the documentation improvements coming, much appreciated!
Re: books for learning D
On Wednesday, 29 January 2020 at 11:57:14 UTC, Jan Hönig wrote: On Monday, 13 January 2020 at 16:37:31 UTC, Ron Tarrant wrote: On Monday, 13 January 2020 at 10:28:48 UTC, mark wrote: I'm just starting out learning D. Andrei Alexandrescu's "The D Programming Language" is 10 years old, so is it still worth getting? (I don't know how much D has changed in 10 years.) Actually, Andrei's book has been updated a few times over the years since first being published. The latest version says this on the copyright page: D version: 2.081.1 Book revision: 2018-10-17 So, it's really only about 14 months old. I am also curious. Where can i find the revised book. I'd also like to know where the revised "The D Programming Language" by Andrei Alexandrescu is: and whether it can be bought in physical form?
Re: books for learning D
On Wednesday, 29 January 2020 at 11:57:14 UTC, Jan Hönig wrote: I am also curious. Where can i find the revised book. Sorry for the delay, guys. I thought I'd posted the link earlier. Here it is: http://ddili.org/ders/d.en/index.html
Re: wordladder - code improvement
I forgot to mention: I know it isn't worth bothering with const/immutable for this tiny example. But I want to learn how to write large D programs, so I need to get into the right habits and know the right things.
Re: format with floating points GC allocating in DMD 2.090
On Friday, 31 January 2020 at 08:45:55 UTC, bauss wrote: On Friday, 31 January 2020 at 07:20:17 UTC, cc wrote: char[4096] buf; writeln(GC.stats.usedSize); foreach (i; 0 .. 10) { sformat(buf, "%f", 1.234f); writeln(GC.stats.usedSize); } Report it as a bug because it's definitely a bug and there was changes to the GC in 2.090.0 2.086 x64 on linux: 0 64 112 160 208 256 304 352 400 448 496
Re: Constant GC allocations when sending large messages to threads?
On Friday, 31 January 2020 at 07:14:30 UTC, cc wrote: On Wednesday, 29 January 2020 at 21:10:53 UTC, Steven Schveighoffer wrote: I'm pretty sure std.concurrency uses Variant to pass message data, which boxes when it gets over a certain size. You are probably crossing that threshold. The allocations should level out eventually when the GC starts collecting them. -Steve Is there a way to pre-allocate a buffer or something to be used? Ideally I'd like to avoid too many garbage collections happening, in my application these thread messages happen almost every frame and are quickly adding up to 100s of kilobytes in allocations every few seconds. You can just allocate non-GC memory.
Re: format with floating points GC allocating in DMD 2.090
On Friday, 31 January 2020 at 07:20:17 UTC, cc wrote: char[4096] buf; writeln(GC.stats.usedSize); foreach (i; 0 .. 10) { sformat(buf, "%f", 1.234f); writeln(GC.stats.usedSize); } Output with DMD32 D Compiler v2.089.1-dirty (Win10 x64): 16 16 16 ... Output with DMD32 D Compiler v2.090.0-dirty: 16 848 1664 2480 3296 4112 4944 5760 6576 7392 8208 Report it as a bug because it's definitely a bug and there was changes to the GC in 2.090.0
Re: wordladder - code improvement
Thanks for your implementation. I can't use the levenshtien distance because although it is a better solution, I want to keep the implementation as compatible with those in the other languages as possible. Your main() is much shorter than mine, but doesn't match the behaviour (and again I want to keep the same as the other implementations). Nonetheless, I didn't know about generate!()(), so I've learnt from yours. Nor did I know about the StopWatch which I'm now using, plus I've added your static assert, and also copied your idea of making update() an inner function (and now only needing one parameter). I still need to study your genLadder() more carefully to understand it because it is so compact.