Re: 64-bit compilation in Wine

2020-12-30 Thread kinke via Digitalmars-d-learn

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`:

2020-11-21 Thread kinke via Digitalmars-d-learn

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

2020-10-29 Thread kinke via Digitalmars-d-learn
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

2020-10-13 Thread kinke via Digitalmars-d-learn

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

2020-10-13 Thread kinke via Digitalmars-d-learn

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

2020-10-06 Thread kinke via Digitalmars-d-learn

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.

2020-10-01 Thread kinke via Digitalmars-d-learn

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 ?

2020-09-23 Thread kinke via Digitalmars-d-learn
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

2020-09-10 Thread kinke via Digitalmars-d-learn

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

2020-09-10 Thread kinke via Digitalmars-d-learn

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

2020-09-08 Thread kinke via Digitalmars-d-learn

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

2020-09-08 Thread kinke via Digitalmars-d-learn

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

2020-09-07 Thread kinke via Digitalmars-d-learn

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?

2020-08-28 Thread kinke via Digitalmars-d-learn

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

2020-08-19 Thread kinke via Digitalmars-d-learn

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

2020-08-10 Thread kinke via Digitalmars-d-learn

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

2020-08-09 Thread kinke via Digitalmars-d-learn

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

2020-07-15 Thread kinke via Digitalmars-d-learn

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)

2020-07-15 Thread kinke via Digitalmars-d-learn

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

2020-07-06 Thread kinke via Digitalmars-d-learn

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

2020-07-06 Thread kinke via Digitalmars-d-learn

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

2020-07-04 Thread kinke via Digitalmars-d-learn

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?

2020-07-02 Thread kinke via Digitalmars-d-learn

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?

2020-07-02 Thread kinke via Digitalmars-d-learn

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?

2020-07-02 Thread kinke via Digitalmars-d-learn

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

2020-06-29 Thread kinke via Digitalmars-d-learn

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

2020-06-27 Thread kinke via Digitalmars-d-learn

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

2020-06-27 Thread kinke via Digitalmars-d-learn

=> https://issues.dlang.org/show_bug.cgi?id=20983


Re: Garbage collection

2020-06-27 Thread kinke via Digitalmars-d-learn

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

2020-06-24 Thread kinke via Digitalmars-d-learn
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

2020-06-24 Thread kinke via Digitalmars-d-learn
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?

2020-06-23 Thread kinke via Digitalmars-d-learn

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

2020-06-22 Thread kinke via Digitalmars-d-learn

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();

2020-06-22 Thread kinke via Digitalmars-d-learn
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();

2020-06-22 Thread kinke via Digitalmars-d-learn

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?

2020-06-22 Thread kinke via Digitalmars-d-learn

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

2020-06-22 Thread kinke via Digitalmars-d-learn

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

2020-06-22 Thread kinke via Digitalmars-d-learn

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

2020-06-21 Thread kinke via Digitalmars-d-learn
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

2020-06-19 Thread kinke via Digitalmars-d-learn

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

2020-06-19 Thread kinke via Digitalmars-d-learn

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

2020-06-19 Thread kinke via Digitalmars-d-learn

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

2020-06-12 Thread kinke via Digitalmars-d-learn

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?

2020-05-30 Thread kinke via Digitalmars-d-learn

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

2020-05-26 Thread kinke via Digitalmars-d-learn

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

2020-05-26 Thread kinke via Digitalmars-d-learn
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

2020-05-20 Thread kinke via Digitalmars-d-learn

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

2020-05-20 Thread kinke via Digitalmars-d-learn

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

2020-05-20 Thread kinke via Digitalmars-d-learn

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

2020-05-18 Thread kinke via Digitalmars-d-learn

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

2020-05-17 Thread kinke via Digitalmars-d-learn

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

2020-05-17 Thread kinke via Digitalmars-d-learn

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

2020-05-15 Thread kinke via Digitalmars-d-learn

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?

2020-05-08 Thread kinke via Digitalmars-d-learn

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

2020-05-08 Thread kinke via Digitalmars-d-learn

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

2020-05-08 Thread kinke via Digitalmars-d-learn

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?

2020-05-05 Thread kinke via Digitalmars-d-learn
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?

2020-05-04 Thread kinke via Digitalmars-d-learn

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 ?

2020-04-16 Thread kinke via Digitalmars-d-learn

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

2020-03-29 Thread kinke via Digitalmars-d-learn

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

2020-03-25 Thread kinke via Digitalmars-d-learn

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

2020-03-21 Thread kinke via Digitalmars-d-learn

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

2020-03-21 Thread kinke via Digitalmars-d-learn

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

2020-03-20 Thread kinke via Digitalmars-d-learn

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

2020-03-11 Thread kinke via Digitalmars-d-learn

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

2020-03-02 Thread kinke via Digitalmars-d-learn

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

2020-02-28 Thread kinke via Digitalmars-d-learn

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

2020-02-24 Thread kinke via Digitalmars-d-learn

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

2020-02-22 Thread kinke via Digitalmars-d-learn

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

2020-02-19 Thread kinke via Digitalmars-d-learn

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

2020-02-11 Thread kinke via Digitalmars-d-learn

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 ?

2020-02-01 Thread kinke via Digitalmars-d-learn

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 ?

2020-02-01 Thread kinke via Digitalmars-d-learn

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

2020-01-16 Thread kinke via Digitalmars-d-learn

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

2020-01-10 Thread kinke via Digitalmars-d-learn

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

2020-01-08 Thread kinke via Digitalmars-d-learn
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

2019-11-27 Thread kinke via Digitalmars-d-learn
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?

2019-11-14 Thread kinke via Digitalmars-d-learn

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?

2019-11-14 Thread kinke via Digitalmars-d-learn
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?

2019-11-14 Thread kinke via Digitalmars-d-learn
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

2019-11-12 Thread kinke via Digitalmars-d-learn

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

2019-11-12 Thread kinke via Digitalmars-d-learn

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?

2019-11-09 Thread kinke via Digitalmars-d-learn

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

2019-11-08 Thread kinke via Digitalmars-d-learn

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?

2019-11-08 Thread kinke via Digitalmars-d-learn

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

2019-10-29 Thread kinke via Digitalmars-d-learn

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.

2019-10-25 Thread kinke via Digitalmars-d-learn

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

2019-10-23 Thread kinke via Digitalmars-d-learn

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

2019-10-23 Thread kinke via Digitalmars-d-learn

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

2019-10-23 Thread kinke via Digitalmars-d-learn

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

2019-10-23 Thread kinke via Digitalmars-d-learn

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

2019-10-04 Thread kinke via Digitalmars-d-learn

Have you tried ctRegex?


Re: C++ base constructor call vs. D's

2019-10-02 Thread kinke via Digitalmars-d-learn

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

2019-08-29 Thread kinke via Digitalmars-d-learn

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

2019-08-29 Thread kinke via Digitalmars-d-learn

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.

2019-08-20 Thread kinke via Digitalmars-d-learn

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

2019-08-15 Thread kinke via Digitalmars-d-learn

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*

2019-08-09 Thread kinke via Digitalmars-d-learn

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?

2019-08-08 Thread kinke via Digitalmars-d-learn

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 ?

2019-08-07 Thread kinke via Digitalmars-d-learn

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.


  1   2   3   >