Re: wstring comparison is failing
On Monday, 23 September 2019 at 23:22:14 UTC, Brett wrote: I guess you are probably right... I was thinking that it would compare up to a null terminator. Seems kinda buggy... maybe the compiler needs to give a warning? After all, compared a fixed size array with a dynamic array then will almost always fail since it is unlikely the sizes will match... ...rather than failing silently. It might still be useful for generic code, so a compiler warning would probably not be suitable. However, it might be a good idea for a linter such as Dscanner, which, unlike the compiler, sees types as they are written in the code, not as they are calculated through metaprogramming.
Re: wstring comparison is failing
On Monday, September 23, 2019 5:22:14 PM MDT Brett via Digitalmars-d-learn wrote: > On Monday, 23 September 2019 at 20:45:00 UTC, destructionator > > wrote: > > On Mon, Sep 23, 2019 at 08:38:03PM +, Brett via > > > > Digitalmars-d-learn wrote: > >> The only thing is that szExeFile is a static > >> wchar array... which shouldn't effect the comparison. > > > > are you sure about that? > > > > with a static size, the lengths of the two sides won't match... > > I guess you are probably right... I was thinking that it would > compare up to a null terminator. Seems kinda buggy... maybe the > compiler needs to give a warning? After all, compared a fixed > size array with a dynamic array then will almost always fail > since it is unlikely the sizes will match... > > ...rather than failing silently. D does virtually nothing with null terminators. String literals have them one index past their end so that you can pass them to C functions without D code actually seeing the null terminator, but otherwise, you have to add the null terminator when passing to C code (e.g. with toStringz or toUTFz), and you have to strip it off when getting a string from C code (e.g. with fromStringz). Other than functions specifically designed to convert to and from C strings, D code is going to treat null terminators just like any other character, because D strings are not null-terminated. - Jonathan M Davis
Re: wstring comparison is failing
On Monday, 23 September 2019 at 20:45:00 UTC, destructionator wrote: On Mon, Sep 23, 2019 at 08:38:03PM +, Brett via Digitalmars-d-learn wrote: The only thing is that szExeFile is a static wchar array... which shouldn't effect the comparison. are you sure about that? with a static size, the lengths of the two sides won't match... I guess you are probably right... I was thinking that it would compare up to a null terminator. Seems kinda buggy... maybe the compiler needs to give a warning? After all, compared a fixed size array with a dynamic array then will almost always fail since it is unlikely the sizes will match... ...rather than failing silently.
Re: Looking for a Simple Doubly Linked List Implementation
On 09/23/2019 01:45 PM, Ron Tarrant wrote: > Well, it turns out, I didn't need a linked list, doubly or otherwise. So, what was it then? Append to an array, sort it, and be happy? :) Ali
Re: Single D app entered multiple times from command line
On Monday, 23 September 2019 at 19:14:15 UTC, Brett wrote: I imagine I could potentially create a separate process that has a communication layer between it and the D program but I'm hoping it would be less work. You're pretty much describing a client-server design. A lot of software does work in this way, e.g.: - MS toolchain spawns mspdbsrv to write PDB files - Gradle (Java build tool) spawns a daemon which caches information in memory - Git on Windows also creates long-lived processes to cache filesystem information The simplest design would be for the server to listen on a named pipe (perhaps named after the current directory), and the client to do nothing but forward the command-line arguments and input to the daemon through the pipe, then read back the result and present it to the user.
Re: Looking for a Simple Doubly Linked List Implementation
Well, it turns out, I didn't need a linked list, doubly or otherwise. That's what happens when a person quits coffee for a week: complete brain chaos. For a full week, I banged on this, trying to work out a scheme whereby I could track GTK Notebook tabs with a doubly-linked list, an array, and any other mechanism that came to mind. That was my caffeine-free week of getting absolutely nothing done. (Twice, I actually forgot my name.) This morning, I had a coffee, realized I was not just on the wrong track, but in the wrong train station and within 45 minutes, I had eight Notebook demos working perfectly. Let this serve as a warning, no matter how much you may think you need to go off the caffeine, it's just not worth it.
Re: wstring comparison is failing
On Monday, 23 September 2019 at 20:38:03 UTC, Brett wrote: cast(wstring)entry.szExeFile == Name to!wstring(entry.szExeFile) == Name These all fail. The strings are clearly the same. I can compare char by char and it works. latest D 2.088. The only thing is that szExeFile is a static wchar array... which shouldn't effect the comparison. If you're comparing a static array, you're also comparing the bytes after the NUL character. Both of those conversions will give you a wstring with the length of the entire array, regardless of and including any NUL characters, so that's probably not what you want. fromStringz would probably be more appropriate there.
Re: wstring comparison is failing
On Mon, Sep 23, 2019 at 08:38:03PM +, Brett via Digitalmars-d-learn wrote: > The only thing is that szExeFile is a static > wchar array... which shouldn't effect the comparison. are you sure about that? with a static size, the lengths of the two sides won't match...
wstring comparison is failing
cast(wstring)entry.szExeFile == Name to!wstring(entry.szExeFile) == Name These all fail. The strings are clearly the same. I can compare char by char and it works. latest D 2.088. The only thing is that szExeFile is a static wchar array... which shouldn't effect the comparison.
Re: Why is the fPIC switch missing?
On Monday, 23 September 2019 at 08:19:35 UTC, Boris Carvajal wrote: On Monday, 23 September 2019 at 01:31:03 UTC, Emmanuelle wrote: Hello. My problem is exactly what it says on the title: my dmd (windows 7, x64) doesn't seem to have -fPIC: I think it's not needed. The generated code on Windows is always position independent. I believe Windows uses relocations. Relocations require patching the image after loading using a relocation table. Position-independent code does not require relocations, it is ready to run from any address straight after loading. This allows multiple copies of programs or libraries to be loaded at the same time in different processes at different addresses (with ASLR), but share their physical memory pages.
Single D app entered multiple times from command line
Is there a way too have a single D process run and be called multiple times from the command line without too much work? Basically any time the process is called by the command line it will "enter" only one process... and if that process is being debugged the entries can be debugged too. E.g., if I have visual studio running and a BP set in a D app... and I then execute the app the BP is hit(rather than the app being spawned in a new process and never even being debugged). I imagine I could potentially create a separate process that has a communication layer between it and the D program but I'm hoping it would be less work.
Re: D man pages
On Monday, 23 September 2019 at 06:06:05 UTC, Jarek wrote: I have the same question. Where to find something similar to man pages from C? They are the same functions, so the idea is you can just use the C man pages directly. There's just the pattern of the D module name to know. but... does it mean that I can't use seekdir() on systems with Musl? (Alpine linux)? it is possibly just not copied in there, I'd say to just try it and see if it triggers the static assert down there. the man page says CONFORMING TO 4.3BSD, POSIX.1-2001. so it probably should work with the core.sys.posix header there, maybe it just isn't verified as to the type of the argument (the notes section warns it has changed, so the D devs are surely being extra cautious about which one it actually has in there, waiting for someone to verify it before putting in the file)
Re: Why is the fPIC switch missing?
On Monday, 23 September 2019 at 08:19:35 UTC, Boris Carvajal wrote: On Monday, 23 September 2019 at 01:31:03 UTC, Emmanuelle wrote: Hello. My problem is exactly what it says on the title: my dmd (windows 7, x64) doesn't seem to have -fPIC: I think it's not needed. The generated code on Windows is always position independent. Still, DMD should warn about it and keep compiling like GCC, not fail miserably. Is PIC really enabled by default for Windows 32-bit binaries.
Re: Why is the fPIC switch missing?
On Monday, 23 September 2019 at 01:31:03 UTC, Emmanuelle wrote: Hello. My problem is exactly what it says on the title: my dmd (windows 7, x64) doesn't seem to have -fPIC: I think it's not needed. The generated code on Windows is always position independent. Still, DMD should warn about it and keep compiling like GCC, not fail miserably.
Re: Why is the fPIC switch missing?
On Mon, Sep 23, 2019 at 3:35 AM Emmanuelle via Digitalmars-d-learn wrote: > > Forgot to say: dmd v2.088.0. Also, weirdly enough, `dmd > --version` outputs `DMD32 D Compiler v2.088.0-dirty`. Why is > "dirty" there? https://forum.dlang.org/post/qqxmnoshytmzflviw...@forum.dlang.org
Re: Why is the fPIC switch missing?
On Mon, Sep 23, 2019 at 3:35 AM Emmanuelle via Digitalmars-d-learn wrote: > > Hello. My problem is exactly what it says on the title: my dmd > (windows 7, x64) doesn't seem to have -fPIC: > > --- > > dmd -fPIC > Error: unrecognized switch '-fPIC' > run `dmd` to print the compiler manual > run `dmd -man` to open browser on manual > --- > > `dmd --help` also doesn't have anything about fPIC. Sorry if I'm > being dense but why is that? Is it only available on Linux? > > Thank you! It seems it is not available for windows and MacOS: https://github.com/dlang/dmd/blob/639c67162b2be90ebf8dc9a9f8118cb2a9606569/src/dmd/cli.d#L323
Re: D man pages
On Saturday, 5 January 2019 at 21:59:27 UTC, kdevel wrote:
For years I missed the man pages of the C++ standard library
and now found out that some Linux distros provide them as extra
package. The man pages are not generated by a default during a
GCC bootstrap install but need an explicit make doc-install-man
in the corresponding doc directory of libstdc++.
Is there any such mechanism to generate man pages for D/Phobos?
Stefan
Hello,
I have the same question. Where to find something similar to man
pages from C?
I would like to use core.sys.posix.dirent and don't know where to
find manuals about it.
Reading dirent.h or man opendir is a lot easier than reading
dirent.d from
/usr/lib64/gcc/x86_64-slackware-linux/9.2.0/include/d/core/sys/posix
If I read dirent.d, then I see something like:
else version (CRuntime_Bionic)
{
}
else version (CRuntime_Musl)
{
}
else version (CRuntime_UClibc)
{
void seekdir(DIR*, c_long);
c_long telldir(DIR*);
}
else
{
static assert(false, "Unsupported platform");
}
does it mean that I can't use seekdir() on systems with Musl?
(Alpine linux)?
