Re: Meson build system user new to D.
On Wednesday, 8 May 2019 at 10:28:26 UTC, Andre Pany wrote: On Monday, 6 May 2019 at 19:52:23 UTC, Mike Brockus wrote: Hello everyone I am a Meson build system user and I am new to the D language, just wondering if there are compiler flags that I should add, unit testing frameworks, any good practices I can follow and or anything like that also some resources would be helpful thanks. (: While I heard Meson is working for D, the prefered choice, in case you have D only applications/libraries is Dub. If you also want build to build C/C++ together with D, Meson or other build systems are preferable. What is your use case? Kind regards Andre I did have a particular use case yet as I am just discovering the capabilities of D and I may say that I appreciate that it looks like both Python and C mixed into one allegiant programming language which makes it easy for me to learn.
Re: Framework design, initialization and framework usage
On Thursday, 9 May 2019 at 11:48:59 UTC, Robert M. Münch wrote: Good to know that there are not only web-stack people around these days. i do web and gui Though my gui library is 100% from scratch on linux, and... barely even good enough for myself to use. I really need to write a new text edit widget.
Re: I had a bad time with slice-in-struct array operation forwarding/mimicing. What's the best way to do it?
On Saturday, 4 May 2019 at 15:36:51 UTC, Nicholas Wilson wrote: On Saturday, 4 May 2019 at 15:18:58 UTC, Random D user wrote: I wanted to make a 2D array like structure and support D slice like operations, but I had surprisingly bad experience. The de facto multi dimensional array type in D is mir's ndslice https://github.com/libmir/mir-algorithm/blob/master/source/mir/ndslice/slice.d#L479 Thanks. I'll take a look.
Re: Framework design, initialization and framework usage
On Thursday, 9 May 2019 at 11:48:59 UTC, Robert M. Münch wrote: The application won't know/see a difference on which platform it runs. I expect some differences in how GUI actions are handled or communicated to the framework, however these should be rare and can be handled with conditional compilation. This is sounding more and more interesting.
Re: I had a bad time with slice-in-struct array operation forwarding/mimicing. What's the best way to do it?
On Saturday, 4 May 2019 at 16:10:36 UTC, Adam D. Ruppe wrote: On Saturday, 4 May 2019 at 15:18:58 UTC, Random D user wrote: But array copy and setting/clearing doesn't: int[] bar = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 ]; foo[] = bar[]; Generally speaking, opIndex is for getting, opIndexAssign is for setting. Thanks a lot for a very detailed answer. Sorry about the late reply. But for 2d and 3d and more arrays, the number of functions explodes really fast. Yeah, tastes like C++, but I guess I'll bite. I value debuggability and I only have the 2D case, so I think templates are out.
Re: alias parameters, what for?
Thanks, I get your points. I do think they make more sense for the standard library, than in every general case (packages for specific uses). Namely, alias parameters provide absolute genericity (instead of overloading every possible use case, or else constraining the API by design), and ultimate runtime performance (always at the expense of compile time).
Re: Erasing passwords from ram?
On Tuesday, 30 April 2019 at 08:15:15 UTC, Dukc wrote: I am currently programming a server. So I got the idea that after I've generated all the hashes I need from a password, I want to erase it from RAM before discarding it, just to be sure it won't float around if the server memory is exposed to spyware by some buffer overflow. Is this wise caution, or just being too paranoid? I've seen this done, and regardless of likelihoods, it doesn't hurt as a precaution. The memutils lib offers a tool for this, 'SecureMem': http://code.dlang.org/packages/memutils In addition to memory-zeroing, it can also prevent it from getting "dumped to disk on a crash or during OS sleep/hibernation."
Re: Compiler/Phobos/Types problem — panic level due to timing.
On Thu, 2019-05-09 at 08:33 +, John Colvin via Digitalmars-d-learn wrote: > […] > > Not big benefit in this case, very big benefit with longer chains. > > It reads in the order of operations, as opposed to inside out. John, Coming from a Haskell/Lisp background to declarative expression, I do not have a problem with the function application approach. However if the audience are more likely to understand the method application approach (and this is fundamentally a Java audience) then that is the way of should be shown. I showed the variant you suggested. :-) -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 13:18:44 UTC, Cym13 wrote: On Thursday, 9 May 2019 at 13:02:51 UTC, Rene Zwanenburg wrote: On Thursday, 9 May 2019 at 12:33:37 UTC, Cym13 wrote: On Thursday, 9 May 2019 at 11:31:20 UTC, Cym13 wrote: ... To dismiss any doubt about AV or other processes coming into play I took the binary and ran it with wine on linux with the exact same end result. For reference my windows system is a 64b windows 10. You could try to use the find handle function in Process Explorer to figure out what process has the file open: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer I did just that and my test program truly is the only process on the system having that file open. Unless I'm missing something that process-explorer doesn't see and is even true in wine's ultra light environment comprised of a single process, this is definitely not the issue. Can you reproduce the issue with other Dlls or is it only reproducible with curl dll? Does the issue with curl dll also exists if you do not call the curl function? Kind regards Andre
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 13:02:51 UTC, Rene Zwanenburg wrote: On Thursday, 9 May 2019 at 12:33:37 UTC, Cym13 wrote: On Thursday, 9 May 2019 at 11:31:20 UTC, Cym13 wrote: ... To dismiss any doubt about AV or other processes coming into play I took the binary and ran it with wine on linux with the exact same end result. For reference my windows system is a 64b windows 10. You could try to use the find handle function in Process Explorer to figure out what process has the file open: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer I did just that and my test program truly is the only process on the system having that file open. Unless I'm missing something that process-explorer doesn't see and is even true in wine's ultra light environment comprised of a single process, this is definitely not the issue.
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 12:33:37 UTC, Cym13 wrote: On Thursday, 9 May 2019 at 11:31:20 UTC, Cym13 wrote: ... To dismiss any doubt about AV or other processes coming into play I took the binary and ran it with wine on linux with the exact same end result. For reference my windows system is a 64b windows 10. You could try to use the find handle function in Process Explorer to figure out what process has the file open: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 11:31:20 UTC, Cym13 wrote: ... To dismiss any doubt about AV or other processes coming into play I took the binary and ran it with wine on linux with the exact same end result. For reference my windows system is a 64b windows 10.
Re: Blog Post #0032 - Menu Accelerator Keys
On Wednesday, 8 May 2019 at 15:06:23 UTC, number wrote: I do feel a bit pedantic about it too :) That's like OCD, right? :)
Re: Framework design, initialization and framework usage
On 2019-05-08 13:31:40 +, Ron Tarrant said: On Wednesday, 8 May 2019 at 10:21:34 UTC, Robert M. Münch wrote: However, I'm happy to post some updates/screenrecordings to show our progress. Works for me. Ok, so I need to find a good name for this thing which I can use as thread subject :-) What are you interested in or what would you do with such a framework? You sparked my interest because it sounds like you're working on something similar to what I cover in a blog I've been writing since January (http://gtkdcoding.com). Ah, sorry, didn't catch the link. I saw this but didn't read anything yet. Will do. Rather than write something from scratch like you guys (I'm not that brave) I take an OOP approach to GtkD, modularizing so it's as close to using Lego as possible. This blog is a revamp of another I started back in 2006 for PHP-GTK, but using D rather than PHP and updated to GTK 3.x. The original also included an application framework (which I haven't yet reproduced in D) with a pluggable do/undo/redo system. So you can see why I perked up when I read your thread. Good to know that there are not only web-stack people around these days. And I assume your framework is written with D as a base language? Yes. Of course we use some C bases libs but the overall goal is to make a D framework. And you said it's cross-platform, too? Windows, Mac, Linux? Are any of the BSDs supported? Since we are going to draw all GUI stuff ourself it should work on all platforms where you can blit a memory buffer to screen. The part that's most platform specific is the event loop. But that's not rocketscience. Overall we try to keep the OS specific integration to an absolut minimum. The application won't know/see a difference on which platform it runs. I expect some differences in how GUI actions are handled or communicated to the framework, however these should be rare and can be handled with conditional compilation. Assuming all that, we're very much of the same mind: cross-platform GUI applications made fast-n-easy using a single language and toolkit. Great :-) Let's see how quick we move forward. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: alias parameters, what for?
On Thursday, 9 May 2019 at 09:52:21 UTC, XavierAP wrote: alias parameters are used for functions (in the general sense). Why this instead of specifying and typing the parameter functions or delegates? With function pointers, there is extra indirection and the function can not be inlined. With alias parameters, something like map!(x => x*2) can be as fast as a hand-written for-loop. A function pointer would make it significantly slower since every multiplication adds a new function call. You can not have a variable map function to the alias parameter, but most often you don't need that. If you do, you can simply do map!(x => dynamicFunc(x)).
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 11:07:53 UTC, Andre Pany wrote: On Thursday, 9 May 2019 at 10:09:23 UTC, Cym13 wrote: Hi, this is likely not related to D itself but hopefully someone can help me with this since I'm rather new to windows programming, I mainly work on linux. I'm trying to bundle a DLL in a binary, write it in a temp folder, use it and remove the dangling file. [...] I can't explain the behaviour, but you could store the temp file name in a string array and remove these file in the module destructor. That's the way how dub handles temp files/folders. https://github.com/dlang/dub/blob/master/source/dub/internal/utils.d#L98 Kind regards Andre No luck there.
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 11:11:56 UTC, Rumbu wrote: Since deploying a dll is a suspect behaviour outside a normal installation process, most probably you have a lock on the file put by windows defender or an antivirus if installed. Thanks for your input but I'm absolutely certain that it's not related to AV since I made sure to test in an AV-free environment (and I'd expect AV to kick in before loading the DLL, but I may be wrong on that). FreeLibrary doesn't guarantee that the dll file is closed, maybe other windows processes are accessing it (like prefetch). Anyway, you are deploying a dll just to read a file, It's over engineering, use WinAPI UrlDownloadToFile instead or any other winapi functions. Well, that's just a test script, it's feature or DLL doesn't matter.
Re: alias parameters, what for?
On Thursday, 9 May 2019 at 09:52:21 UTC, XavierAP wrote:
What are the benefits of alias parameters, compared to
specifying the template parameters fully?
https://dlang.org/spec/template.html#aliasparameters
In most examples, at places in Phobos, and in Andrei's and
Ali’s books, alias parameters are used for functions (in the
general sense). Why this instead of specifying and typing the
parameter functions or delegates?
Genericity, for one. This code will work with functions,
delegates, templated functions, lambdas, and functors:
void call(alias fun)() {
fun();
}
This brings another question, why is it so widespread in Phobos
etc. to template these function parameters instead of declaring
them as run-time parameters? Is this really always considered
beneficial, why?
The compiler can optimize calls to compile-time parameters, but
not run-time parameters. Also, as said above, alias parameters
support a greater variety of types. If instead run-time
parameters were used there'd have to be multiple overloads, or a
templated function that accepts all the different callables.
For one it looks like it saves a lot of typing and makes the
whole declaration more readable (not to mention possible
attribute soups); but the type-checking code just moves to
additional template constraints.
The type checking tends to be a lot looser though - more along
the lines of 'Can I call f with these parameters?', rather than
'Is f a function taking two ints and a string, returning a bool,
and adorned with @safe and @nogc?'. There are tradeoffs there, of
course, and you should use whichever is more correct for your use
case.
And finally what’s the advantage of alias parameters in
general, besides function/delegates? But I don’t see other uses
in practice, although they’re possible.
Templates can be passed in alias parameters. This is used quite
extensively in std.meta. In fact, alias parameters accept
anything* with a name. This makes it easy to build templates that
operate on any type or scope (e.g. a module) with the exact same
code, and passing them from one template to the other without
having to rewrite them to operate on specific types of objects.
Another use case is to pass a value of an unknown type. Without
alias parameters, you'd have to pass the type as well, something
like foo!(int, 3) instead of foo!3, or use a template sequence
parameter and a template constraint:
template foo(Value...) if (Value.length == 1) {}
This is clearly untenable for more than a single such parameter.
In my own code, I've almost exclusively used alias parameters for
templates, with functions being the second most common, and one
or two examples of the module/types mentioned above.
* except built-in primitive types
--
Simen
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 10:09:23 UTC, Cym13 wrote:
Hi,
this is likely not related to D itself but hopefully someone
can help me with this since I'm rather new to windows
programming, I mainly work on linux. I'm trying to bundle a DLL
in a binary, write it in a temp folder, use it and remove the
dangling file.
So far I have the following file:
import std;
void main(string[] args) {
import core.runtime;
static immutable libcurl = import("libcurl.dll");
import std.file: write;
auto libpath = tempDir.buildPath("libcurl.dll");
libpath.write(libcurl);
auto libcurlMem = rt_loadLibrary(libpath.toStringz);
import std.net.curl;
"https://dlang.org/".byLine.count.writeln;
rt_unloadLibrary(libcurlMem);
remove(libpath);
}
Compiled with: dmd.exe -Jlibdir test.d
It almost work, I can write, load and use the library, but when
it comes to
removing it nothing works.
std.file.FileException@std\file.d(1045):
C:\users\cym13\Temp\libcurl.dll: Access denied.
0x00402377 in EntryPoint
0x00413BC7 in EntryPoint
0x00413B49 in EntryPoint
0x004139E3 in EntryPoint
0x0040B77F in EntryPoint
0x7B4754C2 in call_process_entry
0x7B477FC6 in ExitProcess
0x7B4754CE in call_process_entry
I tried using an explicit File handle to explicitely close the
file after
writing to it but that doesn't change anything.
I'm pretty sure I'm missing something basic about the way
windows handles
open files but I don't know what, could someone explain why
this doesn't work
the way I expect it to?
Since deploying a dll is a suspect behaviour outside a normal
installation process, most probably you have a lock on the file
put by windows defender or an antivirus if installed.
FreeLibrary doesn't guarantee that the dll file is closed, maybe
other windows processes are accessing it (like prefetch).
Anyway, you are deploying a dll just to read a file, It's over
engineering, use WinAPI UrlDownloadToFile instead or any other
winapi functions.
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 10:09:23 UTC, Cym13 wrote: Hi, this is likely not related to D itself but hopefully someone can help me with this since I'm rather new to windows programming, I mainly work on linux. I'm trying to bundle a DLL in a binary, write it in a temp folder, use it and remove the dangling file. [...] I can't explain the behaviour, but you could store the temp file name in a string array and remove these file in the module destructor. That's the way how dub handles temp files/folders. https://github.com/dlang/dub/blob/master/source/dub/internal/utils.d#L98 Kind regards Andre
[windows] Can't delete a closed file?
Hi,
this is likely not related to D itself but hopefully someone can
help me with this since I'm rather new to windows programming, I
mainly work on linux. I'm trying to bundle a DLL in a binary,
write it in a temp folder, use it and remove the dangling file.
So far I have the following file:
import std;
void main(string[] args) {
import core.runtime;
static immutable libcurl = import("libcurl.dll");
import std.file: write;
auto libpath = tempDir.buildPath("libcurl.dll");
libpath.write(libcurl);
auto libcurlMem = rt_loadLibrary(libpath.toStringz);
import std.net.curl;
"https://dlang.org/".byLine.count.writeln;
rt_unloadLibrary(libcurlMem);
remove(libpath);
}
Compiled with: dmd.exe -Jlibdir test.d
It almost work, I can write, load and use the library, but when
it comes to
removing it nothing works.
std.file.FileException@std\file.d(1045):
C:\users\cym13\Temp\libcurl.dll: Access denied.
0x00402377 in EntryPoint
0x00413BC7 in EntryPoint
0x00413B49 in EntryPoint
0x004139E3 in EntryPoint
0x0040B77F in EntryPoint
0x7B4754C2 in call_process_entry
0x7B477FC6 in ExitProcess
0x7B4754CE in call_process_entry
I tried using an explicit File handle to explicitely close the
file after
writing to it but that doesn't change anything.
I'm pretty sure I'm missing something basic about the way windows
handles
open files but I don't know what, could someone explain why this
doesn't work
the way I expect it to?
alias parameters, what for?
What are the benefits of alias parameters, compared to specifying the template parameters fully? https://dlang.org/spec/template.html#aliasparameters In most examples, at places in Phobos, and in Andrei's and Ali’s books, alias parameters are used for functions (in the general sense). Why this instead of specifying and typing the parameter functions or delegates? This brings another question, why is it so widespread in Phobos etc. to template these function parameters instead of declaring them as run-time parameters? Is this really always considered beneficial, why? For one it looks like it saves a lot of typing and makes the whole declaration more readable (not to mention possible attribute soups); but the type-checking code just moves to additional template constraints. And finally what’s the advantage of alias parameters in general, besides function/delegates? But I don’t see other uses in practice, although they’re possible.
Re: Compiler/Phobos/Types problem — panic level due to timing.
On Wednesday, 8 May 2019 at 11:53:34 UTC, Russel Winder wrote: On Mon, 2019-05-06 at 15:53 +, John Colvin via Digitalmars-d-learn wrote: […] pretty please show people it with UFCS: recurrence!((a, n) => a[n-1] + a[n-2])(zero, one) .dropExactly(n) .front Any particular reason for preferring this form over the original? Not big benefit in this case, very big benefit with longer chains. It reads in the order of operations, as opposed to inside out.
