Re: GDB + ddemangle

[Joakim via Digitalmars-d-announce]

On Wednesday, 25 April 2018 at 05:09:28 UTC, ANtlord wrote:

On Friday, 20 April 2018 at 17:55:12 UTC, Iain Buclaw wrote:
On 20 April 2018 at 17:40, drug via Digitalmars-d-announce 
 wrote:


Using a compiler that implements 2.077 or later (IIRC) 
probably won't, due to gdb being too old.  They broke ABI by 
introducing back referencing, no release of gdb supports that 
yet.


I launched gdb with command `gdb -ex 'set lang d' test` 
disabling my plugin and I don't see demangling anywhere. Source 
file is compiled with command `dmd -g test.d`


DMD 2.079
GDB 8.1

Did I miss something?


Yes, read two posts back, by Iain.

Re: GDB + ddemangle

[ANtlord via Digitalmars-d-announce]

On Friday, 20 April 2018 at 17:55:12 UTC, Iain Buclaw wrote:
On 20 April 2018 at 17:40, drug via Digitalmars-d-announce 
 wrote:


Using a compiler that implements 2.077 or later (IIRC) probably 
won't, due to gdb being too old.  They broke ABI by introducing 
back referencing, no release of gdb supports that yet.


I launched gdb with command `gdb -ex 'set lang d' test` disabling 
my plugin and I don't see demangling anywhere. Source file is 
compiled with command `dmd -g test.d`


DMD 2.079
GDB 8.1

Did I miss something?

Re: The dlang-community releases DCD 0.9.3 and D-Scanner 0.5.2

[wangwei via Digitalmars-d-announce]

On Monday, 23 April 2018 at 17:26:49 UTC, Seb wrote:
On Monday, 23 April 2018 at 17:04:09 UTC, Baz @dlang-community 
wrote:
Time to update your favorite D completion daemon and D linter 
since previous patch were not announced.


Changelogs:

- https://github.com/dlang-community/DCD/releases
- https://github.com/dlang-community/D-Scanner/releases


For all those building IDE plugins for DCD & co:

This is the first D-Scanner release which comes with release 
binaries for Windows, Linux and macOS.
DCD and dfmt are in the process of receiving similar, automated 
builds too.


I use the dmd portable version and vscode with code-d, the dcd 
just failed (d.ext.dcdFail) no matter dcd is installed 
automatically by code-d or by (source + dub), I definitely need 
the binary release. Dscanner works great.


Once I have used Emacs + company-dcd in Linux, it works well 
although it doesn't look pretty :)


Buying a laptop with intel + nvidia (optimus) is a huge pain in 
installing linux on it.

Re: LDC 1.9.0 beta

[kinke via Digitalmars-d-announce]

On Tuesday, 24 April 2018 at 19:39:30 UTC, Radu wrote:

On Tuesday, 24 April 2018 at 15:53:23 UTC, Joakim wrote:
Yeah, this beta doesn't even have a MIPS backend. How much of 
the testsuite do you have working on MIPS/uClibc? If you have 
it pretty far along, we can probably cherry-pick what you need 
and ship it with 1.9 for people to try.


I realized that those PRs are not going to get in :(. 
Unfortunately it is pretty hard to contribute something that 
has a big impact. It looks that I need to wait another 2 
releases to get all those changes in LDC as I might miss the 
2.8.0 window for 1 PR, not counting additional patches for 
fixes that might come later on...


It may not be that bad. The next post-1.9 LDC is based on 2.080.x 
with x most likely >= 1, so just make sure to have most stuff in 
by then (maybe targeting the stable druntime/Phobos branches for 
new PRs). Final touchups can always be cherry-picked.


We may have a 2.080-based LDC pretty soon. I started merging 
beta1 this evening and it looks way less troublesome than 
upgrading to 2.079.

Re: LDC 1.9.0 beta

[Radu via Digitalmars-d-announce]

On Tuesday, 24 April 2018 at 15:53:23 UTC, Joakim wrote:

On Monday, 23 April 2018 at 09:18:07 UTC, Suliman wrote:
What about Webassembly support? Latest LLVM suppport it, so 
LDC should support also.


We don't support a lot of platforms that llvm supports. It will 
require someone to work on the port, which hasn't happened. 
I've said before that I don't think it's worth it, because the 
web has been declining as a platform:


https://forum.dlang.org/post/unqvdzopebfksnxwh...@forum.dlang.org

On Tuesday, 24 April 2018 at 08:47:49 UTC, Radu wrote:

On Sunday, 22 April 2018 at 15:56:49 UTC, kinke wrote:

Hi everyone,

on behalf of the LDC team, I'm glad to announce the first 
beta for LDC 1.9. The highlights of this version in a 
nutshell:


* Based on D 2.079.1, including new `-i` switch and support 
for a minimal (d)runtime.
* Support for LLVM 6, used for all prebuilt packages (except 
for Win32).
* `-link-internally` able to (cross-)link Windows, Linux and 
macOS binaries.
* Prebuilt Linux and macOS packages now shipping with 
LTO-able druntime/Phobos.
* Improved support for MIPS targets and the uClibc runtime 
library.
* Various fixes, incl. druntime/Phobos/ldc-jit .dylib issues 
on macOS.


Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.9.0-beta1


Thanks to all contributors!


Looks that not all my druntime and phobos PR got in. Is this 
because they were not included in 2.0.79 mainline release?


Yes, ldc releases are the same as dmd releases, with some 
ldc-specific changes. We generally don't backport features from 
upstream.


ATM uClibc is not usable as is, it doesn't even compile 
because of various missing pieces, bummer :(


Yeah, this beta doesn't even have a MIPS backend. How much of 
the testsuite do you have working on MIPS/uClibc? If you have 
it pretty far along, we can probably cherry-pick what you need 
and ship it with 1.9 for people to try.


I realized that those PRs are not going to get in :(. 
Unfortunately it is pretty hard to contribute something that has 
a big impact. It looks that I need to wait another 2 releases to 
get all those changes in LDC as I might miss the 2.8.0 window for 
1 PR, not counting additional patches for fixes that might come 
later on...


uClibc fully passes druntime unit tests on ARM had float (armv7).
phobos test runner segfaults on std.mathspecial, commenting out 
mathspecial - I get some asserts on formatting code related to 
double and some math asserts on some constants. Overall looks 
good and the formatting issues for double and math special 
segfault are not a priority for me, yet.


on uClibc MIPS, druntime test hangs on everything after running 
core.runtime test at `void* z = pureMalloc(size_t.max - 2);`, 
malloc calls will fail after this (overcommit). Versioning it out 
I get the druntime unittest passing with an assert on core.atomic 
for double and some assert when allocating 390mb of memory in 
gc.impl.conservative.gc (way to much for my board). Overall 
druntime looks good. I don't have the details for phobos, but 
most of it passes.


MIPS is a bit special as the vendor toolchain for my HW is pretty 
old and misses some supporting libs like libbacktrace, a math 
function etc.. had to stub them out. I think MIPS will require 
more tinkering from people trying it out.

Re: LDC 1.9.0 beta

[kinke via Digitalmars-d-announce]

On Tuesday, 24 April 2018 at 15:53:23 UTC, Joakim wrote:

Yeah, this beta doesn't even have a MIPS backend.


[The prebuilt binaries don't.] I thought about it for a second, 
but releasing a new LDC-LLVM version (and me having to build the 
4 Windows variants again) seemed too troublesome for the gain. We 
can add the backend for v6.0.1 (and maybe revise that targets 
list in general).
FWIW, I included the AArch64 target for the prebuilt armhf 
LLVM/LDC this time.

Re: LDC 1.9.0 beta

[Joakim via Digitalmars-d-announce]

On Monday, 23 April 2018 at 09:18:07 UTC, Suliman wrote:
What about Webassembly support? Latest LLVM suppport it, so LDC 
should support also.


We don't support a lot of platforms that llvm supports. It will 
require someone to work on the port, which hasn't happened. I've 
said before that I don't think it's worth it, because the web has 
been declining as a platform:


https://forum.dlang.org/post/unqvdzopebfksnxwh...@forum.dlang.org

On Tuesday, 24 April 2018 at 08:47:49 UTC, Radu wrote:

On Sunday, 22 April 2018 at 15:56:49 UTC, kinke wrote:

Hi everyone,

on behalf of the LDC team, I'm glad to announce the first beta 
for LDC 1.9. The highlights of this version in a nutshell:


* Based on D 2.079.1, including new `-i` switch and support 
for a minimal (d)runtime.
* Support for LLVM 6, used for all prebuilt packages (except 
for Win32).
* `-link-internally` able to (cross-)link Windows, Linux and 
macOS binaries.
* Prebuilt Linux and macOS packages now shipping with LTO-able 
druntime/Phobos.
* Improved support for MIPS targets and the uClibc runtime 
library.
* Various fixes, incl. druntime/Phobos/ldc-jit .dylib issues 
on macOS.


Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.9.0-beta1


Thanks to all contributors!


Looks that not all my druntime and phobos PR got in. Is this 
because they were not included in 2.0.79 mainline release?


Yes, ldc releases are the same as dmd releases, with some 
ldc-specific changes. We generally don't backport features from 
upstream.


ATM uClibc is not usable as is, it doesn't even compile because 
of various missing pieces, bummer :(


Yeah, this beta doesn't even have a MIPS backend. How much of the 
testsuite do you have working on MIPS/uClibc? If you have it 
pretty far along, we can probably cherry-pick what you need and 
ship it with 1.9 for people to try.

Re: Who says we can't call C++ constructors?

[kinke via Digitalmars-d-announce]

On Tuesday, 24 April 2018 at 11:19:59 UTC, Atila Neves wrote:
Odd then that dmd doesn't try to correctly mangle constructors 
and destructors since they're perfectly callable.


For normal constructors, that only works in the 
C++-ctor-called-from-D direction, with suboptimal performance. 
Reason being that the D compiler blits the T.init value over the 
instance before calling a ctor, and the D ctor not having to 
define all members.
So for a C++ ctor called from D, the pre-construction blit is 
useless extra work, and calling a D ctor from C++ is unsafe as 
the D ctor may not set all fields. The latter could be simply 
implemented by C++ ctor wrappers for all D ctors (for extern(C++) 
structs and classes), performing the T.init blit and then calling 
the corresponding D ctor, see 
https://forum.dlang.org/post/nqxsdehlydizatopr...@forum.dlang.org.


For the dtor, IIRC the problem was that it's usually virtual in 
C++ (at least when planning to allow subtyping) but isn't in D.

Re: Who says we can't call C++ constructors?

[Atila Neves via Digitalmars-d-announce]

On Tuesday, 24 April 2018 at 12:27:30 UTC, Uknown wrote:

On Tuesday, 24 April 2018 at 11:19:59 UTC, Atila Neves wrote:

On Monday, 23 April 2018 at 20:40:47 UTC, Manu wrote:
On 23 April 2018 at 07:27, Atila Neves via 
Digitalmars-d-announce  
wrote:

On Saturday, 21 April 2018 at 18:11:09 UTC, Manu wrote:


On 21 April 2018 at 05:41, Atila Neves via 
Digitalmars-d-announce 
 wrote:


[...]

Sure.

I thought about generating D wrappers for everything, but in 
TDD fashion I tried slapping a pragma(mangle) on the copy 
constructor and things just worked. Odd then that dmd doesn't 
try to correctly mangle constructors and destructors since 
they're perfectly callable.


[...]


This is very cool.


Thanks!

Is it possible to fix the mangling issues in DMD for Copy 
constructors and destructors?


Yes. And I'm going to have to (see below).


It seems like it would be less code for dpp,


Eh, it'd be a tiny change.


and better C++ interop for D in general.


Well, that's the real issue. There are C++ mangling bugs in the 
dmd frontend, and they need to be fixed because of templates. 
They don't have a mangling until they're instantiated, and I 
can't know that ahead of time where the templates are being 
declared. The easiest way to move forward is to just fix the dmd 
frontend. Unless I come up with some crazy idea. Which I wouldn't 
put past me.


Atila

Re: Who says we can't call C++ constructors?

[Uknown via Digitalmars-d-announce]

On Tuesday, 24 April 2018 at 11:19:59 UTC, Atila Neves wrote:

On Monday, 23 April 2018 at 20:40:47 UTC, Manu wrote:
On 23 April 2018 at 07:27, Atila Neves via 
Digitalmars-d-announce  
wrote:

On Saturday, 21 April 2018 at 18:11:09 UTC, Manu wrote:


On 21 April 2018 at 05:41, Atila Neves via 
Digitalmars-d-announce 
 wrote:


[...]

Sure.

I thought about generating D wrappers for everything, but in 
TDD fashion I tried slapping a pragma(mangle) on the copy 
constructor and things just worked. Odd then that dmd doesn't 
try to correctly mangle constructors and destructors since 
they're perfectly callable.


[...]


This is very cool. Is it possible to fix the mangling issues in 
DMD for Copy constructors and destructors? It seems like it would 
be less code for dpp, and better C++ interop for D in general.

Re: Who says we can't call C++ constructors?

[Atila Neves via Digitalmars-d-announce]

On Monday, 23 April 2018 at 20:40:47 UTC, Manu wrote:
On 23 April 2018 at 07:27, Atila Neves via 
Digitalmars-d-announce  
wrote:

On Saturday, 21 April 2018 at 18:11:09 UTC, Manu wrote:


On 21 April 2018 at 05:41, Atila Neves via 
Digitalmars-d-announce  
wrote:


[...]



Paste the pre-processed D code?
Did you generate the C++ mangled symbol name and call it from 
a D

wrapper? I've attempted that before in 'normal' D ;)



Mostly just constructors with `pragma(mangle)` but having move 
work correctly involved two wrappers, one taking by value and 
one taking by non-const ref.


Can you explain the move issue? That's interesting.


Sure.

I thought about generating D wrappers for everything, but in TDD 
fashion I tried slapping a pragma(mangle) on the copy constructor 
and things just worked. Odd then that dmd doesn't try to 
correctly mangle constructors and destructors since they're 
perfectly callable.


But then there's the move constructor. There's no signature I can 
use for it exactly, so how do I hack that? Well, in D a move 
would be done by value, but that doesn't quite work, since:


this(ref const(T));
this(T);

And:

auto t1 = T(42);
auto t2 = T(t1);

Causes t2 to be constructed with the by value version instead of 
the copy constructor. Clearly not what we want. So I do this:


this(ref const(T));
this(ref T other) {
   this(*cast(const T*)());
}
this(T);

And now rvalues go to the by-value version, and lvalues to the 
copy constructor. What to do with the by-value constructor?


pragma(mangle, "") this(T* );  // C++ move constructor
this(T other) {
this();
other = T.init; // to avoid problems
}

And now rvalues go to the C++ move constructor. Since the D 
definition is in the same module it will probably be inlined as 
well.


The only thing left is to enable explicit moving of lvalues. The 
thing is that I'm already injecting code into the user's file 
anyway, so maybe I can use that to enable moves? I can't put the 
code into a different module (or maybe I can, I might do that 
later), so to namespace it I put it in a struct called dpp:


struct dpp {
static struct Move(T) {
T* ptr;
}

static auto move(T)(ref T value) { // by ref so only lvalues 
apply

return Move!T();
}
}

And we emit another constructor with code in it for the user:

this(Move!T wrapper) {
this(wrapper.ptr);  // calls the C++ move constructor
}

And Bob's your uncle.

Re: LDC 1.9.0 beta

[Radu via Digitalmars-d-announce]

On Sunday, 22 April 2018 at 15:56:49 UTC, kinke wrote:

Hi everyone,

on behalf of the LDC team, I'm glad to announce the first beta 
for LDC 1.9. The highlights of this version in a nutshell:


* Based on D 2.079.1, including new `-i` switch and support for 
a minimal (d)runtime.
* Support for LLVM 6, used for all prebuilt packages (except 
for Win32).
* `-link-internally` able to (cross-)link Windows, Linux and 
macOS binaries.
* Prebuilt Linux and macOS packages now shipping with LTO-able 
druntime/Phobos.
* Improved support for MIPS targets and the uClibc runtime 
library.
* Various fixes, incl. druntime/Phobos/ldc-jit .dylib issues on 
macOS.


Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.9.0-beta1


Thanks to all contributors!


Looks that not all my druntime and phobos PR got in. Is this 
because they were not included in 2.0.79 mainline release?


ATM uClibc is not usable as is, it doesn't even compile because 
of various missing pieces, bummer :(