Re: 64-bit compilation in Wine
On Tuesday, 29 December 2020 at 21:13:59 UTC, Raikia wrote: That certainly helped, but when running the program on a fresh Windows install, I still get the error "The program can't start because vcruntime140.dll is missing from your computer". In my (limited) experience, I think its because it is using msvcrt (which is dynamically linked) instead of libcmt (which is static). The static MS libs cannot be redistributed by 3rd parties thanks to their license, that's why LDC and DMD only come with MinGW-based import libraries depending on an installed MSVC++ runtime. [DMD works with (default) -m32 because that uses Walter's DigitalMars C runtime.]
Re: d++: Error: Could not execute `dmd c.o .\foo.d -offoo.exe`:
On Saturday, 21 November 2020 at 17:25:46 UTC, Jack wrote: I got the error: Error: Could not execute `dmd c.o .\foo.d -offoo.exe`: Error: unrecognized file extension o dmd version: DMD32 D Compiler v2.094.1-dirty gcc version: gcc version 6.3.0 (MinGW.org GCC-6.3.0-1) DMD expects .obj for Windows. So you'll probably have to use the MS compiler or clang to emit an MSVC-compatible object file, and then use either -m32mscoff or -m64 for DMD.
Re: rt/object.d
On Thursday, 29 October 2020 at 16:02:34 UTC, Ola Fosheim Grøstad wrote: I meant the internals like vtable/typeinfo. https://dlang.org/spec/abi.html#classes
Re: Passing pointer to extern(C++) templated function
On Wednesday, 14 October 2020 at 00:25:56 UTC, Jamie wrote: Happy to file a bug, but if it was a bug in the mangler wouldn't both C++ and D get the same result? Assuming D uses the same mangler for the extern(C++) stuff. Bug in the D frontend implementation of Itanium C++ mangling. https://github.com/dlang/dmd/blob/master/src/dmd/cppmangle.d
Re: Passing pointer to extern(C++) templated function
On Tuesday, 13 October 2020 at 09:23:48 UTC, Jamie wrote: It appears that func3 and func4 take on different types depending on other variables being present? Is this expected? Nope, it's a bug in the Itanium C++ mangler, please file a bug. MSVC++ mangling seems fine, after fixing the D declarations to void func3(T)(T* b, const(T)* a); void func4(T)(const(T)* a, T* b); [A D `const T*` is equivalent to C++ `const T* const`; this matters for MSVC mangling...].
Re: Link Time Optimization Bitcode File Format
On Tuesday, 6 October 2020 at 16:46:28 UTC, Severin Teona wrote: Also, when I try to link the druntime with the application I want to write on the microcontroller, there are some link errors due to the file format. This happens when you link manually, not through LDC. When running LDC with `-flto=full -O -v ...`, you'll see that it invokes gcc with extra flags, something like -Wl,-plugin,/dlang/ldc-1.23.0/lib/LLVMgold-ldc.so -Wl,-plugin-opt=mcpu=x86-64 -Wl,-plugin-opt=O3 -Wl,-plugin-opt=-function-sections -Wl,-plugin-opt=-data-sections so that the linker gets to know how to deal with bitcode objects via the LLVM plugin. See http://johanengelen.github.io/ldc/2016/11/10/Link-Time-Optimization-LDC.html for more infos about LTO.
Re: Trying to create a trivial 64 bit D Lang DLL on a Windows 10 machine and cant get past linking.
On Thursday, 1 October 2020 at 20:03:19 UTC, WhatMeWorry wrote: Yes, but shouldn't the /NOENTRY option take care of that. Say, I just want to make a DLL of simple functions. Your little example has 2 problems, the first being an incompatible extern(D) ex/import (mydll.myAddSeven vs. user.myAddSeven) and the second being an incomplete/wrong linker cmdline. When changing the myAddSeven declarations to extern(C++) (another option being a mydll.di header for the import), it works with dmd -m64 -shared -L/NOENTRY mydll.d dmd -m64 user.d mydll.lib For more details, see also https://wiki.dlang.org/Win32_DLLs_in_D.
Re: How to implement fastcall ?
On Wednesday, 23 September 2020 at 19:50:13 UTC, Denis Feklushkin wrote: On Monday, 21 September 2020 at 11:14:06 UTC, Виталий Фадеев wrote: How to implement fastcall ? ( stdcall is calling convention for pass function arguments via registers ) Hypothesis: it is possible what LLVM + Link Time Optimization does by this way. ~All modern ABIs use registers; __fastcall was one of the special 32-bit x86 ABIs AFAIK (using up to 2 GP registers) and isn't supported directly. The D ABI for 32-bit x86 uses one GP register (and is somewhat similar to __thiscall for member functions).
Re: Trouble with Android and arsd.jni
On Thursday, 10 September 2020 at 13:14:00 UTC, burt wrote: However, the app is still crashing when I load it, and there appears to be an issue in Runtime.initialize(), which is called from JNI_OnLoad(), which is defined in arsd.jni. The debugger tells me that it was calling `getStaticTLSRange`, which calls `safeAssert` in the `__foreachbody`, which fails and eventually aborts. That safeAssert would print a useful message, but I guess you can obtain the msg/reason via debugging as well. - This is most likely due to *not* using the required bfd linker (which is used by default when linking via LDC and otherwise selectable via `-linker=bfd`). If you're linking manually via clang, try `-fuse-ld=bfd`.
Re: Trouble with Android and arsd.jni
On Thursday, 10 September 2020 at 11:16:55 UTC, burt wrote: However, I am getting linker errors, telling me that _tlsend, _tlsstart and __bss_end__ are missing. Perhaps you happen to use some stale artifacts? These magic symbols aren't used anymore in druntime since LDC v1.21, and not defined by the compiler anymore. You also don't need the dummy main() anymore. The object file containing the undefined references should shed some light on what's still referencing them.
Re: GC.LDC2 on Android
On Tuesday, 8 September 2020 at 12:47:11 UTC, Danny Arends wrote: How can I figure out which linker is used ? When performing a dub build, it just mentions that ldc2 is used for linking You can add -v as dub 'linker' flag, that will make LDC show the actual cmdline. LDC v1.23 defaults to `-linker=bfd` for Android targets though. And now I actually remember that you should get a startup error in case the linker sections arrangement is a problem, so it's most likely not the linker. The good feedback mentioned earlier, where the GC was apparently no problem: https://github.com/ldc-developers/ldc/issues/3461#issuecomment-648599814
Re: GC.LDC2 on Android
On Tuesday, 8 September 2020 at 11:17:45 UTC, Danny Arends wrote: Does anyone have any experience with using D on android, and using the garbage collector ??? I've never run anything on Android myself, but I've gotten good feedback on AArch64 at least. Make sure to use a recent LDC, and especially to use the bfd linker, not gold or lld, as mentioned in various places.
Re: Building LDC runtime for a microcontroller
On Monday, 7 September 2020 at 15:23:28 UTC, Severin Teona wrote: CMake Error at /snap/cmake/549/share/cmake-3.18/Modules/CMakeTestCCompiler.cmake:66 (message): This is apparently a non-LDC specific issue, a default CMake C compiler sanity check fails. When looking at that file, you'll see that this test should be skipped when providing CMAKE_C_COMPILER_WORKS=TRUE in the CMake cmdline, as provided in one of the exemplary cmdlines on the Wiki page (just append it to the ldc-build-runtime cmdline).
Re: How to define delegate what returns ref?
On Friday, 28 August 2020 at 11:46:15 UTC, Oleg B wrote: How to do this more clearly? alias Dg = ref int delegate(); Dg foo;
Re: BetterC + WASM Update
On Wednesday, 19 August 2020 at 21:24:23 UTC, Mike Brown wrote: I have done some tests, and it appears that classes are supported (LDC 1.22.0)? extern(C++) classes are supported by -betterC. With LDC, D classes are supported to some extent too since v1.11, but this requires a custom object.d (custom Object base class).
Re: LDC cross-module-inlining
On Monday, 10 August 2020 at 11:11:57 UTC, Per Nordlöw wrote: Are the official LDC-releases builtin with or without LTO? Most of them are, but not sure why that matters here (the gain is almost negligible and mainly interesting for the C++ parts - as all D files are compiled to a single object file anyway). On Monday, 10 August 2020 at 05:54:14 UTC, Daniel Kozak wrote: I am not sure but last time I checked ldc does not do cross module inlinig by default, Right, it's still experimental and has issues. and LTO only help if your ldc(druntime+phobos) are built with enabled LTO That's only true if (mostly non-templated) functions in druntime/Phobos are to be cross-module inlined, just like any other library. In that case, you can simply use `-flto= -defaultlib=phobos2-ldc-lto,druntime-ldc-lto` with LDC builds shipping with LTO druntime/Phobos and don't have to recompile druntime/Phobos manually anymore.
Re: __vector(ubyte[32]) misalignment
On Sunday, 9 August 2020 at 01:03:51 UTC, Bruce Carneal wrote: Is sub .alignof alignment expected here? IOW, do I have to manually manage memory if I want alignments above 16? IIRC, yes when using the GC, as that only guarantees 16-bytes alignment. Static arrays on the stack should be aligned just fine with LDC.
Re: Forcing inline functions (again) - groan
On Wednesday, 15 July 2020 at 13:38:34 UTC, Cecil Ward wrote: I recently noticed pragma(inline, true) which looks extremely useful. A couple of questions : 1. Is this cross-compiler compatible? Works for LDC and DMD, not sure about GDC, but if it doesn't support it, it's definitely on Iain's list. 2. Can I declare a function in one module and have it _inlined_ in another module at the call site? For LDC, this works in all cases (i.e., also if compiling multiple object files in a single cmdline) since v1.22. While you cannot force LLVM to actually inline, I haven't come across a case yet where it doesn't.
Re: Choosing a non-default linker for dmd (via dub)
On Wednesday, 15 July 2020 at 11:38:47 UTC, Jacob Carlborg wrote: There's an environment variable "CC" that can be used to select which C compiler is used. Is there any equivalence for selecting the linker, "LD" perhaps? You normally just add -fuse-ld=gold to the C compiler cmdline, e.g., via -Xcc=-fuse-ld=gold in the DMD cmdline.
Re: BetterC Bug? Intended Behavior? Asking Here As Unsure
On Monday, 6 July 2020 at 22:02:37 UTC, Kayomn wrote:
On Monday, 6 July 2020 at 21:09:57 UTC, kinke wrote:
Similar case here; the 'varargs' end up in a GC-allocated
array. I've recently changed `scope` slice params, so that
array literal arguments are allocated on the caller's stack
instead; so adding `scope` for these variadics *should*
probably do the same:
void tester(Test test, scope Test[] tests...);
This doesn't seem to be the case as the issue persists in the
same manner.
https://run.dlang.io/is/LcaKeu
I meant 'should' as in 'should be fixed to do the same', as this
works with -betterC:
struct Test { ~this() {} }
void tester(Test test, scope Test[] tests) { }
extern(C) void main() {
tester(Test(), [Test()]);
}
Re: BetterC Bug? Intended Behavior? Asking Here As Unsure
On Monday, 6 July 2020 at 20:25:11 UTC, Kayomn wrote: Though, admittedly I'm kind of used to seeing this error message since it appears any time you try and do something that relies on type info in betterC, intentionally or not. A notable example is forgetting to supply an arrange length when declaring a stack array, or it'll try to create a runtime-allocated array. Similar case here; the 'varargs' end up in a GC-allocated array. I've recently changed `scope` slice params, so that array literal arguments are allocated on the caller's stack instead; so adding `scope` for these variadics *should* probably do the same: void tester(Test test, scope Test[] tests...);
Re: Catching OS Exceptions in Windows using LDC
On Saturday, 4 July 2020 at 12:59:03 UTC, Adam D. Ruppe wrote: For whatever reason, dmd 64 bit and ldc decided to do their own thing instead of following the Windows standard and thus have no interop with OS exceptions. For LDC, we don't do 'our own thing', but use MSVC++ EH, which allows to catch MSVC++ exceptions in D, and with some work, D exceptions in C++.
Re: Generating struct .init at run time?
On Thursday, 2 July 2020 at 16:51:52 UTC, kinke wrote: `= void` for members doesn't work and, I dare say, not work anytime soon if ever. I've quickly checked; `= void` for members has initialize-with-zeros semantics too, so with LDC, it's equivalent to `= 0` but applicable to user-defined types as well. For DMD, `= void` for non-default-zero-initialized members can be used for the same effect. If all members are effectively zero-initialized, the init symbol isn't emitted, and the compiler initializes the whole struct with zeros. With `= 0`, DMD still emits the init symbol into the object file, but doesn't use it (at least not for stack allocations). TLDR: Seems like initializing (all non-default-zero-initialized) members with `= void` is the portable solution to elide the init symbols *and* have the compiler initialize the whole struct with zeros, so a manual memset isn't required.
Re: Generating struct .init at run time?
On Thursday, 2 July 2020 at 15:20:23 UTC, Ali Çehreli wrote:
According to its date, it was written when I was working for
Weka. Apparently, ldc took care of it for them after all.
If so, then without them posting any issue beforehand or giving
any feedback afterwards.
> For recent LDC versions, the 'solution' is to (statically)
initialize
> the array with zeros, as fully zero-initialized structs don't
feature
> any explicit .init symbols anymore.
What about floating point and char types? Their .init values
are not all zeros in D spec. (I don't think this matters in my
case but still.)
That's why all you have to do, in order not to have recent LDC
emit the struct's init symbol, is to initialize these members
manually with zeros:
struct S { double[elementCount] a = 0; }
void foo() { S s; } // compiler does a memset
`= void` for members doesn't work and, I dare say, not work
anytime soon if ever.
Re: Generating struct .init at run time?
On Thursday, 2 July 2020 at 07:51:29 UTC, Ali Çehreli wrote:
Of course, the solution is to define members with '= void'
Since when? https://issues.dlang.org/show_bug.cgi?id=11331 and
your https://issues.dlang.org/show_bug.cgi?id=16956 are still
open.
For recent LDC versions, the 'solution' is to (statically)
initialize the array with zeros, as fully zero-initialized
structs don't feature any explicit .init symbols anymore.
enum elementCount = 1024 * 1024;
struct S {
double[elementCount] a = void; // <-- HERE
}
void main() {
S s;
assert(typeid(S).initializer.length == double.sizeof *
elementCount);
assert(typeid(S).initializer.ptr is null);
}
Now the program binary is 800M shorter.
So you're saying you have a *stack* that can deal with an 800M
struct (assuming you used a different `elementCount` for the
actual tests)?! Even 8 MB should be too large without extra
compiler/linker options, as that's the default stack size on
Linux IIRC (on Windows, 2 MB IIRC).
I don't think a struct should ever be that large, as it can
probably only live on the heap anyway and only passed around by
refs. I'd probably use a thin struct instead, containing and
managing a `double[]` member (or `double[elementCount]*`).
Re: Linking D with C structs
On Monday, 29 June 2020 at 06:29:38 UTC, Anthony wrote: What does "__initZ" refer to? Does this refer to automatic initialization like "this()"? Almost, it's the static initializer for that struct, which is omitted because you apparently don't compile/link the module containing the struct declaration. Initialize the char array with zeros (= 0) to make the struct fully zero-initialized, preventing the need for that symbol. chars in D are initialized with 0xFF, unlike byte and ubyte.
Re: Garbage collection
On Saturday, 27 June 2020 at 15:27:34 UTC, Stanislav Blinov wrote: On Saturday, 27 June 2020 at 14:12:09 UTC, kinke wrote: Note that I explicitly clear the `str` slice before GC.collect(), so that the stack shouldn't contain any refs to the fat string anymore. Hrm... What happens if you call collect() twice? Nothing changes, even when collecting 5 times at the end of each iteration. In the filed testcase, I've extracted the stack ref to a dedicated function, so that there really shouldn't be any refs on the stack (this is unoptimized code after all...).
Re: Garbage collection
=> https://issues.dlang.org/show_bug.cgi?id=20983
Re: Garbage collection
On Saturday, 27 June 2020 at 10:08:15 UTC, James Gray wrote:
have run into a memory leak
Something seems really off indeed. I've run this on Win64 with
DMD (2.092) and LDC (1.22), without any extra cmdline options:
-
import core.memory;
import core.stdc.stdio;
import std.range;
import std.format;
auto f(R)(R r) { return format("%s", r); }
int toMB(ulong size) { return cast(int) (size / 1048576.0 + 0.5);
}
void printGCStats()
{
const stats = GC.stats;
const used = toMB(stats.usedSize);
const free = toMB(stats.freeSize);
const total = toMB(stats.usedSize + stats.freeSize);
printf(" GC stats: %dM used, %dM free, %dM total\n", used,
free, total);
}
void main()
{
printGCStats();
while (true)
{
puts("Starting");
string str = f(iota(100_000_000));
printf(" string size: %dM\n", toMB(str.length));
str = null;
GC.collect();
printGCStats();
}
}
-
Output with DMD (no change with the precise GC via
`--DRT-gcopt=gc:precise`):
-
GC stats: 0M used, 1M free, 1M total
Starting
string size: 943M
GC stats: 1168M used, 1139M free, 2306M total
Starting
string size: 943M
GC stats: 1168M used, 2456M free, 3623M total
Starting
string size: 943M
GC stats: 1168M used, 2456M free, 3623M total
Starting
string size: 943M
GC stats: 1168M used, 2456M free, 3623M total
Starting
string size: 943M
GC stats: 1168M used, 2456M free, 3623M total
-
With LDC:
-
GC stats: 0M used, 1M free, 1M total
Starting
string size: 943M
GC stats: 1168M used, 1139M free, 2306M total
Starting
string size: 943M
GC stats: 2335M used, 1288M free, 3623M total
Starting
string size: 943M
GC stats: 2335M used, 2605M free, 4940M total
Starting
string size: 943M
GC stats: 2335M used, 2605M free, 4940M total
Starting
string size: 943M
GC stats: 2335M used, 2605M free, 4940M total
-
Note that I explicitly clear the `str` slice before GC.collect(),
so that the stack shouldn't contain any refs to the fat string
anymore.
Re: figure out where a particular template function is located
On Wednesday, 24 June 2020 at 21:05:12 UTC, Steven Schveighoffer wrote: I have a hard time believing that there's no way to do this! This would IMO be the job of the IDE. E.g., Visual D might be able to jump to the template declaration.
Re: figure out where a particular template function is located
On Wednesday, 24 June 2020 at 20:28:24 UTC, Steven Schveighoffer wrote: Is there a way to figure this out from the call? Another option would be running LDC with -vv for verbose codegen (be warned, lots and lots ouf output); we have fully qualified names in there.
Re: real.mant_dig on windows?
On Tuesday, 23 June 2020 at 02:56:36 UTC, 9il wrote: Should it always be 53? or it can be 64, when? Thank you For LDC, it's 53 (and .sizeof == 8) for MSVC targets, but 64 (x87) for MinGW, reflecting the accompanying C runtime's `long double`. [And IIRC, MS disallows any x87 usage in kernel code.] For DMD, it's always 64, it only has x87 reals.
Re: called copy constructor in foreach with ref on Range
On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote: [...] That's why I put the struct in parantheses. Moving a class ref makes hardly any sense, but I've also never written a *class* to represent a range. Moving is the no-brainer solution for transferring ownership of struct ranges and invalidating the original instance.
Re: how to skip the next (n) item & continue from (n+1) with a range ? e.g. in File(fn).byLine();
If you are referring to the next line, not the next n lines, that's a simple `continue;` statement.
Re: how to skip the next (n) item & continue from (n+1) with a range ? e.g. in File(fn).byLine();
On Monday, 22 June 2020 at 20:02:22 UTC, kinke wrote: If you are referring to the next line, not the next n lines, that's a simple `continue;` statement. [Please discard, that'd obviously be skipping the *current* line.]
Re: How to correctly integrate D library to Swift/Obj-C mobile project?
On Monday, 22 June 2020 at 19:41:22 UTC, Vlad wrote: Usually, when you connect c++/c, you have header files so you can call functions from Objective-C/swift code. We need something similar. There's a pretty recent -HC switch to generate C++ headers from `extern(C++)` declarations. Not sure how usable it is at this point. Is it even possible to compile D for iOS and use it the same way as compiled C++ static library? (We do need a D runtime) iOS shouldn't be any different than other targets (especially macOS) in this regard.
Re: called copy constructor in foreach with ref on Range
On Monday, 22 June 2020 at 19:03:44 UTC, Jonathan M Davis wrote: in practice, that means that generic code cannot use a range once it's been copied Translating to a simple rule-of-thumb: never copy a (struct) range, always move.
Re: called copy constructor in foreach with ref on Range
On Monday, 22 June 2020 at 16:25:11 UTC, Jonathan M Davis wrote:
The reason that foreach copies the range is simply due to how
the code is lowered. e.g.
foreach(e; range)
{
}
essentially becomes
for(auto r = range; !r.empty; r.popFront())
{
auto e = r.front;
}
And the fact that a copy is made is likely simply a result of
it mimicking what happens with arrays.
I was trying to explain/guess the rationale for that copy (not in
terms of how it's implemented, but why it's implemented that
way). This 'mimicking-an-array' doesn't make any sense to me. If
the original idea wasn't to make sure the range is reusable
afterwards, I guess it's done for implementation simplicity, to
promote an rvalue range to the required lvalue.
If copying a range is considered to be generally unsafe and a
common pitfall (vs. the save() abomination), maybe range-foreach
shouldn't allow any lvalue ranges in the 1st place, thus not
making any copies and forcing the user to specify some rvalue (as
returned by `range.save()`, or `move(range)` if destructive
iteration is indeed intended).
Re: called copy constructor in foreach with ref on Range
A foreach over a custom range makes an initial copy, so that the original range is still usable after the foreach (not empty).
Re: Arduino and MCU Support
On Friday, 19 June 2020 at 14:14:07 UTC, frasdoge wrote: though the -mcpu does not have any AVR options out-of-the-box as you mentioned. I guess you mean `ldc2 -mcpu=help` doesn't list any AVR CPUs. Use `ldc2 -mtriple=avr -mcpu=help`.
Re: Arduino and MCU Support
On Friday, 19 June 2020 at 14:14:07 UTC, frasdoge wrote: I'm having a bit of trouble understanding how to actually get started even with those links. I've installed the latest LDC and LLVM releases for Windows, though the -mcpu does not have any AVR options out-of-the-box as you mentioned. Perhaps I've missed something, or will I need to build the binary myself using the flags for AVR? Compiling the sample from the AVR wiki works here on Win64 with the official LDC 1.22 package and: ldc2 -betterC -Oz -mtriple=avr -mcpu=atmega328p -c test.d For linking, you'll need an avr-gcc toolchain, and add `-gcc= -Xcc=-mmcu=atmega328p` as mentioned on the Wiki page. I don't have such a toolchain. The ESP32 process seems more involved. Due to my inexperience in this area, I'm wondering that, if I need to build the binaries myself anyway, how I would set it such that it'll work with AVR and ESP32 at the same time with one installation? Simply using -mtriple and tweaking etc\ldc2.conf as explained here: https://wiki.dlang.org/Cross-compiling_with_LDC
Re: Arduino and MCU Support
On Friday, 19 June 2020 at 11:57:01 UTC, frasdoge wrote: I am looking to use D for microcontroller programming due to its benefits over C in workflow and general language features. I was wondering what the current state of this is, especially with regards to AVR. An example of the MCUs I would like to develop with include anything from 8 bit ATmega328p to 32 bit ESP32. The ESP32 can be programmed in C, C++, micropython and Lua, so I'm hoping there's at least some compatibility there. AVR: https://wiki.dlang.org/D_on_AVR With recent official LDC packages, you don't need to build LLVM and LDC yourself, AVR is supported out-of-the-box. ESP32: https://wiki.dlang.org/D_on_esp32/esp8266(llvm-xtensa%2Bldc)_and_how_to_get_started This arch hasn't been upstreamed to LLVM yet and so needs their LLVM fork, i.e., building it and LDC yourself. For some more infos, use the search function of this forum.
Re: Windows + LDC/DMD installation nightmare when changing VS versions
On Friday, 12 June 2020 at 15:21:12 UTC, Guillaume Piolat wrote: Any idea what could be causing this? Mentioning at least the used LDC version would be helpful; especially since the MSVC detection was completely overhauled with the v1.22 betas (and I think the previous non-existing-LDC_VSDIR hack wouldn't work anymore). LDC doesn't need a reinstall when tampering the VS installations (there's no setup process, MSVC auto-detection runs each time). - Assuming you are using an LDC version < 1.22, you can manually check the auto-detection result by invoking `bin\msvcEnv.bat ` (e.g., by checking the env variables afterwards via `set`). Some leftovers from uninstalled VS installations might be problematic, but probably hardly the reason for a 32-bit libcmt.lib to be linked with a 64-bit target. But I'd start first with checking whether LDC/dub works in a naked command prompt, to rule out that VisualD is interfering. [And adding -v to the LDC commandline is useful for debugging linking problems.]
Re: how to achieve C's Token Pasting (##) Operator to generate variable name in D?
Using a mixin:
string f(string x) { return "_" ~ x; }
int main() {
mixin("int "~f("x")~" = 3;");
return _x;
}
Re: m32mscoff with lld-link causes SEH errors
On Monday, 25 May 2020 at 01:32:58 UTC, Daniel C wrote: Is lld-link only for 64-bit compiles (-m64 is the only one that gives no errors) Nope, but SafeSEH is a 32-bit-only feature. DMD doesn't emit SafeSEH compatible object files, and LLD seems to have a different default setting in that regard compared to MS link.exe. Using `-L/safeseh:no` should work around this.
Re: ModuleInfo and -fno-moduleinfo option
ModuleInfos are essential for the module ctors and dtors (of used modules) to be run, incl. a dependency tree defining their order of execution. They're also needed for running the unittests.
Re: large Windows mingw64 project in C99 --- need ABI compatible D compiler
On Wednesday, 20 May 2020 at 23:08:53 UTC, IGotD- wrote: When you mention the ABI, is there something particular you have in mind or just in general? The ABI for MinGW targets in general. - Judging by https://forum.dlang.org/post/anfwqjjsteeyelbdh...@forum.dlang.org, you apparently use a very different definition of 'ABI'. See http://uclibc.org/docs/psABI-x86_64.pdf or https://docs.microsoft.com/en-us/cpp/build/x64-software-conventions?view=vs-2019 for what an ABI is. I guess what you meant is the druntime API implicitly used by the compiler (mostly, the _d_* hooks like _d_assert, _d_newclass etc.). That's well-defined already, e.g., see https://github.com/ldc-developers/ldc/blob/master/gen/runtime.cpp.
Re: large Windows mingw64 project in C99 --- need ABI compatible D compiler
On Wednesday, 20 May 2020 at 20:45:26 UTC, NonNull wrote: [...] so I will likely go with ldc2 with the option you suggested and see how it goes. Thanks again! You're welcome. If you do come across an ABI issue, make sure to file an LDC issue. While I have no interest in MinGW, I want at least a working ABI.
Re: large Windows mingw64 project in C99 --- need ABI compatible D compiler
On Wednesday, 20 May 2020 at 18:53:01 UTC, NonNull wrote: Which D compiler should be used to be ABI compatible with mingw32? And which to be ABI compatible with mingw64? The natural choice for coupling mingw[64]-gcc would be GDC. Especially wrt. ABI, gdc apparently doesn't have to do much by itself, in sharp contrast to LDC. No idea where gdc's MinGW[-w64] support is at though and whether you need more recent D features not available in gdc. Wrt. LDC, I think the C ABI for the `-mtriple=x86_64-windows-gnu` target should be okay. IIRC, MinGW mostly adheres to Microsoft's official Win64 ABI and mostly just diverges wrt. `real` (80-bit x87 C `long double` vs. 64-bit double precision for MSVC), and that's covered by LDC IIRC. The C++ ABI (Itanium mangling, not the MSVC one) should be okay-ish; there might be differences wrt. what's considered a POD between MinGW and MSVC. Exception handling almost certainly doesn't work; TLS may likely not work either. In general, druntime and Phobos don't fully support MinGW[-w64], but if you restrict yourself to -betterC code, that might not be a problem. How can I use D in this situation, where I need it to work directly with C data? building DLLs is not going to work here for that reason. With -betterC, generating mixed DLLs shouldn't be any trouble at all.
Re: After compiling Hello World with DMD Compiler, .EXE file takes 1-3 seconds to run for the first time
On Monday, 18 May 2020 at 15:49:06 UTC, Adam D. Ruppe wrote: It sees D programs as unusual and gives them additional scrutiny... Is that really the case for all D programs on Windows, or just those built with -m32 and thus using the exotic DigitalMars C runtime?
Re: Detecting performance pitfall in array access
On Sunday, 17 May 2020 at 11:39:30 UTC, kinke wrote: DMD v2.091: * dmd -m64 -O -release -boundscheck=off -run ..\speed.d aa bbc: ~11 μs I forgot `-inline` for DMD; that reduces the speed, yielding ~16 μs.
Re: Detecting performance pitfall in array access
On Sunday, 17 May 2020 at 03:30:57 UTC, Adnan wrote: In my machine, if you feed "aa" and "bbc" to the function, ldc generated code takes around 400 microseconds. I don't have an access to gdc in my machine. https://imgshare.io/image/NN8Xmp Full code: D : https://run.dlang.io/is/vLj7BC Nim : https://play.nim-lang.org/#ix=2mhH (for reference) Compiler flags: dub : build -b release-nobounds nimble : --d:danger My timings are very different, using LDC v1.21 on Win64: * ldc2 -O -release -run bla.d aa bbc: 8-9 μs * ldc2 -O -release -boundscheck=off -run bla.d aa bbc: 8-9 μs * ldc2 -O -release -boundscheck=off -flto=full -defaultlib=phobos2-ldc-lto,druntime-ldc-lto -run bla.d aa bbc: 4 μs DMD v2.091: * dmd -m64 -O -release -boundscheck=off -run ..\speed.d aa bbc: ~11 μs As a side note, using jagged arrays for multiple dimensions should probably be avoided whenever you can.
Re: Linker error under Ubuntu
On Thursday, 14 May 2020 at 16:09:16 UTC, solidstate1991 wrote: When I try to compile my own project under Ubuntu with dub, I get the following linker error: /usr/bin/ld: .dub/obj/pixelperfectengine_pixelperfecteditor.o: undefined reference to symbol 'inflateEnd' //lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Error: /usr/bin/gcc failed with status: 1 /usr/bin/ldc2 failed with exit code 1. This sounds like a misconfigured distro-LDC. zlib is usually integrated into libphobos, but distros tend to favor the distro's libz.so and patch it out. That must be handled in /etc/ldc2.conf though, with something like `-defaultlib=phobos2-ldc,z,druntime-ldc` (and possibly a zlib1g-dev package dependency).
Re: Is is a Bug or just me?
On Friday, 8 May 2020 at 14:16:10 UTC, foerdi wrote: Now I am unsure if this is a bug or an undefined behavior that I don't know. This is a regression, and a potentially pretty bad one, so thx for tracking it down! If this is a bug, then I don't know how to call it for the bug tracker. Maybe something like 'return statement might access memory from destructed temporary'.
Re: XMM Intrinsics
On Friday, 8 May 2020 at 13:30:42 UTC, Marcio Martins wrote: I saw the intel-intrinsics package, but unfortunately it stops at SEE3 and I need SSE4.2 for this. How is this library working? It's open source. :) Will LDC/LLVM detect the name and replace it with the right instructions? If so, could I just provide an empty _mm_crc32_u8 and it'd pick it up correctly? Nope. But take a look at ldc.gccbuiltins_x86, it offers these 4 builtins: int __builtin_ia32_crc32hi(int, short); int __builtin_ia32_crc32si(int, int); int __builtin_ia32_crc32qi(int, byte); long __builtin_ia32_crc32di(long, long); Make sure to compile with `-mattr=+sse4.2` to enable these instructions.
Re: XMM Intrinsics
On Friday, 8 May 2020 at 12:49:00 UTC, Simen Kjærås wrote: How would I go about calling _mm_* functions in D in a way that is portable between D compilers? You would use core.simd: Nope one wouldn't, because that horrible interface isn't supported by LDC, and I guess GDC neither. The intel-intrinsics dub package aims to provide a compiler-independent layer: https://code.dlang.org/packages/intel-intrinsics
Re: real operations imprecise?
I can't even reproduce the 'missing' digits. On run.dlang.io,
i.e., on Linux x64 (and so x87 real), I get an identical output
for both DMD and LDC:
void main()
{
import core.stdc.stdio, std.math;
printf("%.70Lf\n", PI);
printf("%.70Lf\n", PI_2);
printf("%La\n", PI);
printf("%La\n", PI_2);
}
=>
3.14159265358979323851280895940618620443274267017841339111328125
1.570796326794896619256404479703093102216371335089206695556640625000
0xc.90fdaa22168c235p-2
0xc.90fdaa22168c235p-3
Re: Idomatic way to guarantee to run destructor?
On Monday, 4 May 2020 at 11:50:49 UTC, Steven Schveighoffer wrote: I'm not sure if Ali is referring to this, but the usage of scope to allocate on the stack was at one time disfavored by the maintainers. This is why std.typecons.scoped was added (to hopefully remove that feature). Though, if dip1000 ever becomes the default, allocating on the stack could be a valid optimization. It's not an optimization, it's the status quo for years, although apparently not properly spec'd. And unlike the `scoped` library solution, `scope` is lightweight and works with -betterC too.
Re: How can I fully include "libdruntime-ldc.a" and "libphobos2-ldc.a" in my .so lib ?
On Thursday, 16 April 2020 at 10:04:54 UTC, Basile B. wrote: Just got it to work using "libs" : [ "druntime-ldc", "phobos2-ldc" ] $ ldc2 -help | grep -- -link-defaultlib-shared --link-defaultlib-shared - Link with shared versions of default libraries. Defaults to true when generating a shared library (-shared). Boolean options can take an optional value, e.g., -link-defaultlib-shared=.
Re: A question about C++ interop
On Sunday, 29 March 2020 at 15:20:52 UTC, YD wrote: So what do I need to declare in the D file for it to match the library entry? Thanks! This is similar to https://issues.dlang.org/show_bug.cgi?id=19260, and can be worked around the same way by messing manually with the mangled name, if you can't adapt the C++ side. The actual problem is that you can't express a mutable reference to a const class object (as opposed to a struct) in D (`const Y` is a const reference to a const Y object). (This problem somehow does not appear on Linux where the library file is compiled with gcc, though) The Itanium C++ mangling doesn't differentiate between: void foo(const Y *); // what you have on the C++ side void foo(const Y * const); // corresponds to D `void foo(const Y)`
Re: Output predefined versions
On Wednesday, 25 March 2020 at 17:22:51 UTC, Dan Cirnat wrote: Is there a quick way to check which ones are predefined? Yes, just dummy-compile something with `-v` and check the line starting with `predefs`.
Re: Strip Unused Symbols Ldc + Windows
On Saturday, 21 March 2020 at 17:33:21 UTC, SrMordred wrote: Hmm, ok, my question is in fact relate to this kind of thing: https://godbolt.org/z/NGjyyx Why int example.add(int, int): its still on the binary when all u need is alredy optimized to main: mov eax, 30 ret ? You're inspecting an object file, before any linker and symbol stripping is involved.
Re: Strip Unused Symbols Ldc + Windows
On Saturday, 21 March 2020 at 01:54:00 UTC, SrMordred wrote: Someone knows how to strip unused symbols on final binary using ldc on windows ? i found this about this topic: https://forum.dlang.org/post/yvmnkvzgoxhcfavja...@forum.dlang.org that uses --gc-sections and --version-script but this options are not avaliable in windows lld-link That was about ELF symbol visibility and doesn't apply to Windows at all. - The symbols are stripped by default for Windows targets (/OPT:REF for MS linker/LLD). You can cross-check by disabling via `-disable-linker-strip-dead`.
Re: dub and -lowmem: does nothing
On Friday, 20 March 2020 at 23:37:52 UTC, Anonymouse wrote: 4. If I run dub with -v on the lowmem configuration and copy/paste *the same command it ran*, unmodified, I suddenly get the more expected ~1183 Mb used. [...] -lowmem is visibly present in the dmd command listed with -v, but it seems to do nothing through dub. How? Why? Most likely because dub doesn't actually invoke the listed command, but uses a response file to work around cmdline length limits. -lowmem in response files is ignored by DMD (needs to be parsed and set before druntime initialization, but response file parsing needs druntime + GC). It works for LDC though.
Re: DMD 2.090.1: SIGILL, Illegal instruction on (ahem) intel Pentium III
On Wednesday, 11 March 2020 at 22:18:04 UTC, kdevel wrote: Disassembly on the AMD 64 it reveals that ldc also emits the movds instructions: 0x08051ba2 <+434>: call 0x804f680 <_D2rt5minfo11ModuleGroup6__ctorMFNbNcNiAyPS6object10ModuleInfoZSQCkQCkQCh> 0x08051ba7 <+439>: sub$0x8,%esp 0x08051baa <+442>: movsd 0x30(%esp),%xmm0 0x08051bb0 <+448>: movsd 0x38(%esp),%xmm1 That's in druntime, not your cross-compiled code; you'll need to cross-compile druntime and Phobos first, see https://wiki.dlang.org/Building_LDC_runtime_libraries.
Re: Using LDC2 on ARM
On Monday, 2 March 2020 at 17:45:26 UTC, Severin Teona wrote: Is there any reason why the LDC team stopped releasing pre-built binaries for arm? It's the only package that isn't auto-generated by CI services and requires manual steps in a painfully slow qemu environment, a process that takes hours and which I wasn't willing to keep up any longer.
Re: Strange counter-performance in an alternative `decimalLength9` function
On Friday, 28 February 2020 at 10:11:23 UTC, Bruce Carneal wrote: On Friday, 28 February 2020 at 06:50:55 UTC, 9il wrote: bsr can be done in one/two CPU operation, quite quick. But core.bitop.bsr wouldn't be inlined. Instead, mir-core (mir.bitop: ctlz) or LDC intrinsics llvm_ctlz can be used for to get code with inlining. That's surprising. I just got ldc to inline core.bitop.bsr on run.dlang.io using ldc -O3 -mcpu=native. These tiny core.bitop wrappers around LLVM intrinsics are always inlined (`pragma(inline, true)`), i.e., you don't even need -O.
Re: Lambda capture by value
On Monday, 24 February 2020 at 19:50:23 UTC, JN wrote:
foreach (i; iota(5))
{
printers[i] = () { write(i); };
}
This allocates 1 closure and generates 1 lambda, so all printers
are identical delegates. You could use a static foreach:
NumberPrinter[] printers;
static foreach (i; 0..5)
printers ~= () { write(i); };
foreach (d; printers)
d();
Re: Porting D to custom OS
On Saturday, 22 February 2020 at 13:20:40 UTC, IGotD- wrote: Do we have any guide for OS porting? I'd suggest to first hack the compiler, so that it doesn't predefine the host OS, but a new version for your OS (and check whether predefining `version (Posix)` is appropriate or not). That way, you'll hit static asserts when compiling druntime/Phobos, where OS-specific parts don't handle the new OS yet. Once all compile errors are fixed, you can then move on to compiling and linking the druntime/Phobos test runners, fixing all linker errors along the way, and finally fixing all failing unittests, possibly requiring compiler codegen adaptations.
Re: State of MIPS
On Wednesday, 19 February 2020 at 07:09:02 UTC, April wrote: What's the current state of MIPS compiling for bare metal? For LDC, bare metal should hardly be a problem; most druntime/Phobos tests apparently pass, see https://github.com/ldc-developers/ldc/issues/2995.
Re: Printing LHS and RHS of assert expressions on failure
On Tuesday, 11 February 2020 at 13:38:32 UTC, Adnan wrote: I just want to know is there any de-facto way of achieving this? See the `-checkaction=context` switch.
Re: How to call a extern C++ class constructor ?
On Saturday, 1 February 2020 at 14:52:21 UTC, kinke wrote: Trivial cases like yours should actually work wrt. using C++ ctor implementations from D IIRC. Ah, you need at least one virtual function in the C++ class (because D always reserves a vptr, the pointer to the class vtable).
Re: How to call a extern C++ class constructor ?
On Saturday, 1 February 2020 at 08:15:20 UTC, Luhrel wrote: But somehow I got a segfault on dcpp.getNumber(true). That's because you declare it as virtual in D (default for classes, use `final`), but non-virtual in C++. You also forgot to add the class field to the D declaration (yes, D needs to know about the struct layout and size too, especially when you `new` the class in D and let the GC allocate it). Trivial cases like yours should actually work wrt. using C++ ctor implementations from D IIRC.
Re: Information about the 'magic' field in object.Object class
On Thursday, 16 January 2020 at 15:28:06 UTC, realhet wrote:
Update:
- All of the child classes needed to be marked with extern(C++)
- static class members are not supported, only __gshared static.
- passing a delegate to a constructor of this class expects a
(extern(C++) delegate) too.
- Internal compiler error: string[string] can not be mapped to
C++
So extern(C++) is not good in the current case.
The 3 latter points can be trivially worked around via extern(D):
extern(C++) class C
{
extern(D):
static int tlsGlobal;
this(void delegate()) {}
void foo(string[string] aa) {}
}
void main()
{
C.tlsGlobal = 123;
auto c = new C(() {});
c.foo(null);
}
I will not do any synchronization, but I think the GC will
crash upon releasing these objects.
Very likely.
Re: Easiest way to use FMA instruction
On Friday, 10 January 2020 at 00:02:52 UTC, Johan wrote: For LDC: [...] Simpler variant: ``` import ldc.intrinsics; ... const result = llvm_fma(a, b, c); ``` This LLVM intrinsic is also used in LDC's Phobos for std.math.fma(); unfortunately, upstream Phobos just has a `real`-version, so the float/double versions aren't enabled yet: https://github.com/ldc-developers/phobos/blob/26d14c1a292267a32ce64fa7f219acc3d3cca274/std/math.d#L8370-L8376
Re: Practical parallelization of D compilation
On Wednesday, 8 January 2020 at 04:40:02 UTC, Guillaume Lathoud wrote: * first run (compiling everything): 50% to 100% slower than classical compilation, depending on the hardware, resp. on an old 4-core or a more recent 8-core. If parallel compiler invocations for each source file are indeed that much slower than a single serial all-at-once compilation in your case, you can also try to compile all modules at once, but output separate object files - `ldc2 -c a.d b.d c.d`. I wonder if some heuristic roughly along these lines - when enough source files and enough cores, do parallel and/or re-use - could be integrated into the compilers, at least in the form of an option. I think that's something to be handled by a higher-level build system, not the compiler itself.
Re: What is the simplest way to download and set path variables for D compilers when using AppVeyor
On Wednesday, 27 November 2019 at 19:02:08 UTC, Michael Brockus wrote: I am wondering if you guys would know what maybe the simplest way to have D working on AppVeyor Probably something like this: https://github.com/kinke/ldc/blob/e484486364f6765cb35d9d2961b05647ae78552b/appveyor.yml#L67-L69
Re: Why same pointer type for GC and manual memory?
On Thursday, 14 November 2019 at 01:08:58 UTC, Suleyman wrote: On Wednesday, 13 November 2019 at 16:43:27 UTC, IGotD- wrote: Best example is probably managed C++, an MS extension to C++ which is now deprecated. MS Managed C++ was superseded by C++/CLI[1] which was standardized. They actually retained the special syntax for GC pointers. One of the motivations if I understand correctly is to let the programmers easily distinguish which pointers should be freed and which ones are managed by the GC. It's not a bad idea when there is extensive use of both manual memory management and garbage collection. IIRC (it's been a while), a mandatory reason for that distinction is that the .NET GC may move managed objects in memory (compaction) and so you have to pin them first to get a stable pointer.
Re: Does betterC work different on windows and linux?
On Thursday, 14 November 2019 at 16:34:07 UTC, Ferhat Kurtulmuş wrote: I could also run the code in that way. Probably I have some problems with dub configurations. I get linking errors when I try to import the library in a newly created dub project, although there is "dflags": ["-betterC"] in the dub.json of client app. Then we can be sure that it supports betterC. The -betterC for that app doesn't imply that its dependencies are compiled with -betterC too. So either also specify that flag in your library's dub config, or build the app with `DFLAGS=-betterC dub ...`.
Re: Does betterC work different on windows and linux?
I can't reproduce this with LDC 1.17.0, after changing `unittest` to `extern (C) int main()` and returning 0 at the end; compiled & linked with `ldc2 -betterC stringnogc.d`.
Re: Troubleshooting DUB invocations
On Tuesday, 12 November 2019 at 16:44:06 UTC, Dukc wrote: When trying to compile a project including newest Spasm (DUB package) using the newest LDC via DUB, the result is: ``` lld: error: unknown argument: --no-as-needed ``` I then ran DUB with -v switch and it turned out the invocation contained `-L--no-as-needed` as first of all the -L arguments. The trouble is, how do I know what causes DUB to add that argument to the invocation? I could find no reason in `dub.` files of either my package, Spasm or any package in Spasm dependency tree. Dub is open-source, so you can grep the source. - Dub uses it for all 3 compilers (e.g., https://github.com/dlang/dub/blob/f87302dd206b0e5871b39704e694b2194e294aa5/source/dub/compilers/ldc.d#L249), and I'm not sure it's really needed. Anyway, you can also use another linker that supports this flag (e.g., via `-linker=gold`).
Re: rpath on macOS
On Tuesday, 12 November 2019 at 10:19:30 UTC, cartland wrote: but on macOS with DMD or LDC this gives ld: unknown option: -rpath=../../_cache/" IIRC, Mac's ld64 linker requires 2 separated args: "-rpath" "../../_cache/"
Re: is the runtime implemented in betterC?
On Friday, 8 November 2019 at 15:25:40 UTC, dangbinghoo wrote: On Friday, 8 November 2019 at 13:52:18 UTC, kinke wrote: On Friday, 8 November 2019 at 10:40:15 UTC, dangbinghoo wrote: hi, I'm not sure what you are trying to achieve; you can easily cross-compile druntime & Phobos with LDC, see https://wiki.dlang.org/Building_LDC_runtime_libraries. hmm, if runtime is implemented in regular D, how could the regular D code depends on regular D runtime be compiled when we doesn't have a D runtime even exists? thinking thant we just have xtensa-llvm, and building ldc for xtensa CPU, the runtime will simply just not compiled. it's an egg-chicken problem? This is getting confusing. You definitely don't need a prebuilt druntime to build the static druntime library, the dependency is at link-time, and then druntime just depends on other parts of itself. No chicken-egg problem. It's still not clear to me what you are actually trying to achieve. If you are working on an x64 machine, have built a special xtensa-LLVM and built an LDC linked against that LLVM, you can cross-compile to that CPU. You can use the mentioned ldc-build-runtime tool to try to cross-compile druntime and Phobos (and optionally the testrunners). Then it's all about fixing the resulting compile errors (and link errors for the testrunners); most of the adaptations are in druntime, but you'll also have to slightly adapt the compiler (at least adding a new predefined version for the new CPU architecture). druntime depends on OS, architecture and coupled C runtime - what OS are you going to target?
Re: Default initialization of static array faster than void initialization
On Friday, 8 November 2019 at 16:49:37 UTC, wolframw wrote: I compiled with dmd -O -inline -release -noboundscheck -mcpu=avx2 and ran the tests with the m array being default-initialized in one run and void-initialized in another run. The results: Default-initialized: 245 ms, 495 μs, and 2 hnsecs Void-initialized: 324 ms, 697 μs, and 2 hnsecs If you care about performance, you're much better off with LDC or GDC. DMD v2.089 takes 11.7 ms on my Win64 machine, LDC (`ldc2 -O -run gist.d`) v1.18 0.27 ms - that's 43x faster.
Re: is the runtime implemented in betterC?
On Friday, 8 November 2019 at 10:40:15 UTC, dangbinghoo wrote: hi, is the runtime d code implemented purely with betterC? i was thinking that what's happening when we building ARM dlang compiler, when the dlang compiler ready in the first, there's no ARM version of the runtime lib and phobos, so, it's likely we are using bare metal D and trying to build the runtime. druntime is not compiled as `-betterC`, because the entire point of `-betterC` is to prevent a dependency on druntime, at least at link-time [so C forward declarations and some templates can be used by code compiled as `-betterC`]. I'm not sure what you are trying to achieve; you can easily cross-compile druntime & Phobos with LDC, see https://wiki.dlang.org/Building_LDC_runtime_libraries.
Re: Accuracy of floating point calculations
On Tuesday, 29 October 2019 at 16:20:21 UTC, Daniel Kozak wrote:
On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak
wrote:
On Tue, Oct 29, 2019 at 4:45 PM Twilight via
Digitalmars-d-learn wrote:
>
> D calculation:
>mport std.stdio;
import std.math : pow;
import core.stdc.math;
void main()
{
writefln("%12.3F",log(1-0.)/log(1-(1-0.6)^^20));
}
>writefln("%12.2F",log(1-0.)/log(1-(1-0.6)^^20));
>
> 837675572.38
>
> C++ calculation:
>
>cout<> (log(1-0.)/log(1-pow(1-0.6,20)))
> <<'\n';
>
> 837675573.587
>
> As a second data point, changing 0. to 0.75 yields
> 126082736.96 (Dlang) vs 126082737.142 (C++).
>
> The discrepancy stood out as I was ultimately taking the
> ceil of the results and noticed an off by one anomaly.
> Testing with octave, www.desmos.com/scientific, and
> libreoffice(calc) gave results consistent with the C++
> result. Is the dlang calculation within the error bound of
> what double precision should yield?
If you use gdc or ldc you will get same results as c++, or you
can use C log directly:
import std.stdio;
import std.math : pow;
import core.stdc.math;
void main()
{
writefln("%12.3F",log(1-0.)/log(1-(1-0.6)^^20));
}
My fault, for ldc and gdc you will get same result as C++ only
when you use pow not ^^(operator) and use doubles:
import std.stdio;
import std.math;
void main()
{
writefln("%12.3F",log(1-0.)/log((1-pow(1-0.6,20;
}
The real issue here IMO is that there's still only a `real`
version of std.math.log. If there were proper double and float
overloads, like for other std.math functions, the OP would get
the expected result with his double inputs, and we wouldn't be
having this discussion.
For LDC, it would only mean uncommenting 2 one-liners forwarding
to the LLVM intrinsic; they're commented because otherwise you'd
get different results with LDC compared to DMD, and other forum
threads/bugzillas/GitHub issues would pop up.
Note that there's at least one bugzilla for these float/double
math overloads already. For a start, one could simply wrap the
corresponding C functions.
Re: Can not understand this code.
On Friday, 25 October 2019 at 06:40:19 UTC, lili wrote: why need defined a alias Min in Min template? https://dlang.org/spec/template.html#implicit_template_properties
Re: dub build doesn't work
On Wednesday, 23 October 2019 at 16:55:37 UTC, OiseuKodeur wrote: On Wednesday, 23 October 2019 at 06:40:47 UTC, Seb wrote: You won't need Visual Studio for this, but something which ships msvcr100.dll. So sth. like this should be enough: https://www.microsoft.com/en-us/download/details.aspx?id= even when i installed the latest vcredist_x86 it doesn't work You don't need the *latest* VC runtime (2019), but 2010, i.e., Seb's link. For DMD that is, LDC should be fine with the latest one.
Re: Eliding of slice range checking
On Wednesday, 23 October 2019 at 13:08:34 UTC, Per Nordlöw wrote: Is it possible to remove cluttering? godbolt.org supports D as well and is way more powerful than run.dlang.io, besides offering way more LDC versions to choose from. It can also be used to remove the 'cluttering': https://d.godbolt.org/z/ejEmrK
Re: Eliding of slice range checking
On Wednesday, 23 October 2019 at 13:08:34 UTC, Per Nordlöw wrote: The ASM- and IR-output from the following code is pretty messy for You call this messy?! cmpq%rdi, %rdx jae .LBB0_2 xorl%eax, %eax retq .LBB0_2: movq%rdi, %rax testq %rdi, %rdi je .LBB0_3 pushq %rax .cfi_def_cfa_offset 16 movq%rcx, %rdi movq%rax, %rdx callq memcmp@PLT testl %eax, %eax sete%al addq$8, %rsp .cfi_def_cfa_offset 8 retq .LBB0_3: movb$1, %al retq Anyway, clearly no bounds checks, LLVM's optimizer works as it should.
Re: Eliding of slice range checking
On Wednesday, 23 October 2019 at 11:20:59 UTC, Per Nordlöw wrote: How can I investigate the codegen myself here? Simply check the IR or asm, e.g., on run.dlang.io. If there's a call to `_d_arraybounds` in the function of interest, bounds checks are enabled. For your example, the template is inferred to be @safe, and `-release` only elides bounds checks in @system functions (corresponding to `-boundscheck=safeonly`). Use `-boundscheck=off` to elide it in all functions.
Re: using regex at compile time errors out! Error: static variable `thompsonFactory` cannot be read at compile time
Have you tried ctRegex?
Re: C++ base constructor call vs. D's
On Wednesday, 2 October 2019 at 17:22:40 UTC, Just Dave wrote: I was reading the C++ to D page, and came across this little bit about when to call the base class constructor: Isn't there some inherent danger of not calling the base constructor first? The object's fields are pre-initialized before invoking the constructor, and not undefined as in C++, so probably not really dangerous. "It's superior to C++ in that the base constructor call can be flexibly placed anywhere in the derived constructor." That formulation is s bit suboptimal, as the emphasis should be on '*can* be flexibly placed anywhere' - if you don't specify an explicit `super()` call, it's implicitly inserted at the beginning of the derived ctor, so a base ctor is always invoked at some time when constructing a derived object. I don't think there are lots of use cases for deferring the super call, but it might be useful for logging purposes and such.
Re: Static initialization of rectangular arrays
On Thursday, 29 August 2019 at 18:59:22 UTC, kinke wrote: On Thursday, 29 August 2019 at 18:11:50 UTC, Les De Ridder wrote: It's a known bug[1]. As a workaround you could use a `static this()`: Or LDC, and GDC probably too. Sorry, that was wrt. the linked bugzilla and not this example here. - What does work is `static double[6][3] matrix = [0, 0, 0]`, i.e., initializing each nested 1D array with a scalar 0.
Re: Static initialization of rectangular arrays
On Thursday, 29 August 2019 at 18:11:50 UTC, Les De Ridder wrote: It's a known bug[1]. As a workaround you could use a `static this()`: Or LDC, and GDC probably too.
Re: How to set a global var to a user defined section.
On Tuesday, 20 August 2019 at 17:33:17 UTC, lili wrote:
Hi:
With gcc we can use _ attribute _((section("name")) var; how
to same in dlang?
As for C(++), not standardized in the language itself. With LDC:
import ldc.attributes : section;
@section("name")
__gshared int myGlobal;
Re: /usr/bin/ld.gold: error: failed to find object -lz
On Thursday, 15 August 2019 at 11:28:35 UTC, Dukc wrote: > https://software.opensuse.org/package/zlib-devel-static An error when installing, apparently internal. That's the library you need. You may have messed things up by installing a non-dev package from Fedora (!).
Re: Abstract classes vs interfaces, casting from void*
On Friday, 9 August 2019 at 12:26:59 UTC, John Colvin wrote: Why is there no "hi" between 0 and 1? Because you are treating the unadjusted object pointer as interface pointer and then call the only virtual function of that interface, in the 2nd vtbl slot (after the TypeInfo ptr). Casting a class ref to an interface offsets the pointer, so that the interface ref points to the interface vptr for that object instance. This is missing in that line, and so you are invoking the first virtual function of class C, which is some base function in `Object`.
Re: Module static constructor doesn't work?
On Thursday, 8 August 2019 at 14:55:37 UTC, Andrey Zherikov wrote: But if I create library from lib.d first and then link it with main.d then ctor/dtor are not called: For this to work as expected, the `lib.obj` object file needs to be linked into the final executable. As main.d doesn't need anything from lib.d, the linker will skip it by default if it's in a static library. An `import lib1.lib` isn't enough, you need to reference some symbol in main.d. Or instruct the linker to use all object files in the static library (e.g., via /WHOLEARCHIVE with the MS linker).
Re: How to mark a condition is likeyly or unlikey ？
On Wednesday, 7 August 2019 at 11:37:06 UTC, lili wrote: How to do this in Dlang？ Just as in C, this isn't standardized, and I don't think DMD has such a thing. For LDC, see https://forum.dlang.org/thread/ecycecfohgcqkfapi...@forum.dlang.org.
