Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote: https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md Here, the DIP Author clearly expresses two reasons why a programmer may choose to declare a function to accept ref arguments. The Language Maintainers see this as the core of the proposal and would expect the distinction between the two cases to be maintained throughout. However, this proposal does not maintain the distinction and instead conflates the two cases. The Language Maintainers insist that any proposal allowing ref parameters to accept rvalue references must clearly define how functions which make use of ref for side effects will not accept rvalues. Sorry, but that's just irrelevant / missing the point. On Thursday, 24 January 2019 at 09:31:41 UTC, Manu wrote: Hooray! Who didn't see that coming 10 years off! I didn't see that coming and I'm deeply frustrated and disappointed by this review and rejection.
Re: Copy Constructor DIP and implementation
On Wednesday, 12 September 2018 at 11:39:21 UTC, Dejan Lekic
wrote:
On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole
wrote:
Here is a question (that I don't think has been asked) why not
@copy?
@copy this(ref Foo other) { }
It can be read as copy constructor, which would be excellent
for helping people learn what it is doing (spec lookup).
Also can we really not come up with an alternative bit of code
than the tupleof to copying wholesale? E.g. super(other);
I could not agree more. @implicit can mean many things, while
@copy is much more specific... For what is worth I vote for
@copy ! :)
@implicit makes sense if extending explicitly implicit calls to
all other constructors gets somday considered. Some people argued
for it and I agree with them that it'd be nice to have, for ex.
to make a custom string struct type usable without having to
smear the code with constructor calls.
Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?
On Thursday, 30 August 2018 at 12:18:10 UTC, Elie Morisse wrote: On Monday, 11 June 2018 at 15:41:57 UTC, Steven Schveighoffer wrote: I filed a bug about a similar thing (calling private functions instead of using private variables), but it seemed to be agreed upon that this is expected behavior: https://issues.dlang.org/show_bug.cgi?id=15897 You may find some more insight from reading that discussion. I don't agree with the conclusion, as it is very surprising behavior to me. -Steve Not the same, bauss' case is a template method that wouldn't get the depreciation warning if it wasn't templated. Template instances not always having the same access privileges as their template declaration's is definitely a bug. Or actually since I didn't test the code it's more likely just due to T being Bar, in which case there's no reason to make the cast to Foo mandatory since Foo's field get accessed from Foo's method.
Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?
On Monday, 11 June 2018 at 15:41:57 UTC, Steven Schveighoffer wrote: I filed a bug about a similar thing (calling private functions instead of using private variables), but it seemed to be agreed upon that this is expected behavior: https://issues.dlang.org/show_bug.cgi?id=15897 You may find some more insight from reading that discussion. I don't agree with the conclusion, as it is very surprising behavior to me. -Steve Not the same, bauss' case is a template method that wouldn't get the depreciation warning if it wasn't templated. Template instances not always having the same access privileges as their template declaration's is definitely a bug.
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1016, "ref T accepts r-values": https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md Yay! Thank you Manu for taking the time to write the DIP, and I greatly hope that it will get accepted and implemented quickly. Code interacting with C++ libraries will become infinitely more readable, and from the endless past discussions on the topic no real drawback ever emerged, in my opinion.
Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests
On Monday, 12 February 2018 at 01:27:19 UTC, Walter Bright wrote: On 2/11/2018 5:05 PM, Nick Sabalausky (Abscissa) wrote: Know what is a heavyweight problem worth our while? Having dmd be able to directly read C .h files, so the poor user does not have to manually translate them. We've already got a huge chunk of that problem solved. The Digital Mars C/C++ front end is now Boost licensed. It can be used. It's already been converted to D! The preprocessor in it is a bit dated and a bit too specific to Windows - but we've got Warp now! Replace the preprocessor in dmc++ with Warp, slice off the back end, and make it a module that dmd can import. Wouldn't it be nice to support: import stdio.h;// Look, Ma! C headers! There are some intractable issues, and it may be impossible to get 100% to "it just works", but looking past that it might be a huge win for us. Wow, you converted DMC++'s front-end to D? To chime in on that, Calypso i.e the LDC+Clang equivalent of what you described isn't dead (it just revived a few weeks ago from a long slumber) and it should be possible to make a smaller codegen-less version for DMD that only depends on a few Clang and LLVM support libraries. Another possibility..
Re: Solving the spurious forward/cyclic reference errors in DMD
I'll start working on this tomorrow, so if you believe this effort will be in vain, please leave a comment.
Solving the spurious forward/cyclic reference errors in DMD
Timon, any update on this? What are the insights you gained with
your frontend?
I recently reported two cases without a simple fix:
https://issues.dlang.org/show_bug.cgi?id=17656
https://issues.dlang.org/show_bug.cgi?id=17194#c1
and have seen a lot more referencing errors with Calypso,
especially when this gets enabled:
https://github.com/Syniurge/Calypso/commit/1e1ae319e32120bd9ef0009716ddabed92f69ac2
Calypso makes its mapped C++ symbols go through the same
importAll -> semantic1,2,3 route that D symbols take. Ultimately
this is mostly useless work that should be skipped, the reason it
currently works this way being that I wasn't familiar yet with
the DMD source code when I started. But what this hard and
ungrateful work has also been doing (and many large libraries are
blocked by this) is exposing a seemingly infinite number of bogus
forward/circular/misc referencing DMD errors.
Those errors boil down to semantic calls getting triggered at the
wrong time, on symbols that the caller doesn't really depend upon.
Because most of the time, the semantic() call on the LHS of
DotXXXExp, inside AggregateDeclaration.determineSize, etc. is
there in case there are:
- mixins to expand
- attributes whose members have to be added to the parent symtab
- if LHS is a template to instantiate
These are (AFAIK) the only cases where the symtab of the LHS or
the aggregate may get altered, and if I understand correctly
that's what the semantic call is checking before searching for
the RHS or determining the aggregate fields and then its size.
So would splitting semantic() into determineMembers() preceding
the rest of semantic() be worth exploring? The thing is, this
would help in most cases but I can imagine scenarios where simply
splitting may not be enough. Example:
enum E { OOO = S.UUU }
import std.conv;
string genMember1() { return "enum G8H9 = " ~
(cast(int)E.OOO).to!string; }
string genMember2() { return "enum UUU = 1;"; }
struct S {
mixin(genMember1());
mixin(genMember2());
}
We'll have S.determineMembers -> E.OOO.semantic ->
S.determineMembers, and although in this case the value of OOO
may be interpreted to 1, at this point the compiler can't easily
know whether mixins will generate zero, one or more UUU members
or not. To attenuate the problem determineMembers() could be made
be callable multiple times (recursively), each time starting from
where the previous (on-going) call left off, so in this
particular case the second S.determineMembers call would expand
the second mixin to enum UUU = 1. But then how does the compiler
knows and react if genMember1 generate a new UUU member? Ok a
second UUU enum will error, but what if UUU was a function and
genMember1() generates a more specialized overload of UUU? I.e:
enum E { OOO = S.UUU(1) }
import std.conv;
string genMember1() { return "static int UUU(int n) { return n;
}; enum G8H9 = " ~ (cast(int)E.OOO).to!string; }
string genMember2() { return "static int UUU(int n, int a = 5) {
return n + 5; }"; }
struct S {
mixin(genMember1());
mixin(genMember2());
}
At this point well it's getting a bit contrived, so maybe it's
not really worth finding a solution to make this compile (but
ideally the compiler should still warn the user).
Should I try splitting semantic() and make a PR? It might be a
lot of work, so I'd like to know if this makes sense first.
Re: how to catch D Throwables (or exceptions) from C++?
On Friday, 2 December 2016 at 08:13:51 UTC, Jacob Carlborg wrote:
On 2016-12-01 02:58, Timothee Cour via Digitalmars-d-learn
wrote:
eg:
```
dlib.d:
extern(C) void dfun(){assert(0, "some_msg");}
clib.cpp:
extern "C" void dfun();
void fun(){
try{
dfun();
}
catch(...){
// works but how do i get "some_msg" thrown from D?
}
}
```
At least for a C++ exception it's possible to get the current
exception with __cxxabiv1::__cxa_current_primary_exception(). I
verified and it works for C++ exceptions. I would think that
the following works for D exceptions, but I cannot even catch
the D exception in C++. Maybe it's not working properly on
macOS.
// c++
void foo();
const char* getExceptionMessage(void*);
void bar()
{
try
{
foo();
}
catch(...)
{
void* e = __cxxabiv1::__cxa_current_primary_exception();
if (e)
{
const char* msg = getExceptionMessage(e);
if (msg)
printf("%s\n", msg);
else
printf("no message\n");
}
else
{
printf("no exception\n");
}
}
}
// d
extern(C++) void foo()
{
throw new Exception("foo");
}
extern(C++) immutable(char)* getExceptionMessage(void* e)
{
if (e)
{
auto t = cast(Throwable) e;
return t.msg.ptr;
}
return null;
}
I'm compiling the C++ code with clang++ and I need to link with
libc++abi.
Exceptions thrown from D set a different exception class in the
header, and the C++ personality routine (i.e the function that
gets called for each catch block) only handles exceptions which
displays the C++ exception class, so let D exceptions slip
through.
To catch exceptions thrown by D code in C++ I think this would
have to be done by throwing a C++ exception (eventually wrapping
a D class), but this is yet to be implemented.
Re: Need DMD AST expertise
On Tuesday, 21 June 2016 at 19:42:54 UTC, Elie Morisse wrote: On Monday, 20 June 2016 at 20:52:02 UTC, Guillaume Chatelet wrote: « (cast(TypeFunction) fd->type)->parameters » Mixing C++ and D once more..
Re: Need DMD AST expertise
On Monday, 20 June 2016 at 20:52:02 UTC, Guillaume Chatelet wrote: I'll have a look at `parameters` from TemplateDeclaration [2] but I still need to match it to the function arguments somehow. The templated function is the child symbol of the TemplateDeclaration which shares the same name i.e Dsymbol* s; Dsymbol.oneMembers(tempdecl->members, , tempdecl->ident); auto fd = cast(FuncDeclaration) s; You then need to visit the templated function parameters « (cast(TypeFunction) fd->type)->parameters » and look for identifiers that match the TemplateDeclaration.parameters[].ident. In the simplest cases the types of templated function parameters are TypeIdentifier.
Re: Operator overloading through UFCS doesn't work
On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote: The difference is that it's impossible to do 10.opBinary!"+"(15), so if you're forced to do foo.opBinary!"+"(bar) to get around a symbol conflict, it won't work with built-in types. Obviously operator overloading should be limited to class and struct types, so that's not really relevant. UFCS does not have that problem, because you're dealing with free functions and can choose to not use UFCS and provide the full import path or to alias the function, which you can't do with operators - particularly built-in operators. I still don't understand what you're getting at, unfortunately. D was designed to be much cleaner with operator overloading than C++ is. It restricts what the definitions of the operators are so that you don't have to define as many of them to get the basic operations (e.g. opCmp for most of the comparison operators or op!"++" for both pre-increment and post-increment) and so that they aren't easily overloaded to do stuff that does not correspond to what that operator does for built-in types. D doesn't even use + for string concatenation, because Walter thought that that was operator abuse. Allowing arbitrary code to add overloaded operators to an existing type is not at all in line with that philosophy. Regardless, there really isn't much point in arguing this. If you want things to change, you're going to need to convince Walter, which I very much doubt is going to happen. - Jonathan M Davis Thanks for taking the time to explain, although I still fail to see a good justification for disabling UFCS for operators. I will look for more discussions on the topic and if still no opposing argument seems valid I might push the issue forward.
Re: Operator overloading through UFCS doesn't work
On Wednesday, 25 May 2016 at 21:50:06 UTC, Jonathan M Davis wrote:
It's not an overloaded operator anymore at that point, and that
definitely fails to work for generic code, since not all
operators are overloaded operators. Free functions don't have
that problem.
Sorry to reiterate the previous post but is that really the case?
void FuncTemplate(...)(...) {
X.FreeFunc(Y);
}
import ModuleA; // contains FreeFunc
import ModuleB; // contains a conflicting FreeFunc overload
FuncTemplate!()(); // fails
Where is the difference with writing generic code with operators
(overloaded or not)?
Re: Operator overloading through UFCS doesn't work
On Tuesday, 24 May 2016 at 23:43:46 UTC, Jonathan M Davis wrote: On Tuesday, May 24, 2016 23:19:32 Elie Morisse via Digitalmars-d-learn wrote: On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote: > Afaik free-function operator overloads (but not in the > context of UFCS) were considered and turned down because D > did not want to get amidst discussions about adding Koenig > lookup. UFCS does not do Koenig lookup. I don't get it, aren't the current symbol lookup rules enough to make free function operator overloads useful? To me it looks like they are. Sorry for digging up this thread, just getting irritated by a restriction that seems pointless and arbitrary. Overloaded operators would suffer from the same potential abuses other methods are subjected to if UFCS was enabled, nothing more as far as I can see. If UFCS doesn't work, because there are two free functions with the same name which take the same arguments, then you can differentiate between them by not using UFCS and using their full import paths, or you can alias them so that they don't have the same name. Neither of those would be possible with operator overloading. If overloaded operators were allowed as free functions, then if there were ever a symbol conflict, you'd be screwed. - Jonathan M Davis X.FreeFunc(Y); // multiple matches error ModuleA.FreeFunc(X, Y); // ok X * Y; // multiple matches error ModuleA.opBinary!'*'(X, Y); // ok Is there much of a difference between the two?
Re: Operator overloading through UFCS doesn't work
On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote: Afaik free-function operator overloads (but not in the context of UFCS) were considered and turned down because D did not want to get amidst discussions about adding Koenig lookup. UFCS does not do Koenig lookup. I don't get it, aren't the current symbol lookup rules enough to make free function operator overloads useful? To me it looks like they are. Sorry for digging up this thread, just getting irritated by a restriction that seems pointless and arbitrary. Overloaded operators would suffer from the same potential abuses other methods are subjected to if UFCS was enabled, nothing more as far as I can see.
Re: D frontend
On Friday, 6 May 2016 at 09:34:39 UTC, Timon Gehr wrote: One major goal of this project is to figure out a good way to handle non-trivial compile-time dependency structures (i.e. solving the "forward reference error" problem). As it does explicit dependency tracking on AST nodes, it can possibly be used for fine-grained (AST-level) incremental compilation in the future. Great initiative! While mapping big C++ librairies with a lot of templates with Calypso I still hit forward referencing errors from time to time. Some of them were easily fixed but I feel that making the whole thing more robust is a complex task that can't be achieved through small fixes/hacks, it needs a drastic solution like yours.
Re: Qt's MOC getting replicated in D for Calypso
On Saturday, 20 February 2016 at 17:34:48 UTC, Nicolas F. wrote: This is really cool and an interesting project, though I've got one concern: How will this fit in with the rest of the C++ efforts done upstream? (...) or is the goal to upstream these changes and make them an officially supported feature? The two efforts are independent, and the main issue with Calypso's approach: it's tied to LDC, LLVM and Clang. Although I had a slight hope that the approach would get recognized as allowing perfect interfacing with C++ incl. things unthinkable with the « from scratch » approach (like C++ template instantiation) and give D an edge that would probably be sufficient to make lots and lots of people switch from C++ to D, as long as DMD is there and a GDC/GCC version isn't proved feasible there's no question about whether this approach should get officially endorsed or not, and nevertheless the current efforts towards better C++ support in DMD should still yield important results. Calypso will exist as a LDC plugin, and yes code using Calypso features will only be build-able by LDC+Calypso. As I see it the goal here is to spearhead a working Qt <-> D interaction, but how would this be used in production? Would Calypso simply be run to generate bindings The goal of Calypso is to make any C++ library of any complexity usable in D straightaway, and there's no binding involved. moc was a barrier for Qt because it only parses C++ code, and Qt's C++ API can hardly be used without the code moc generates.
Re: Qt's MOC getting replicated in D for Calypso
On Thursday, 18 February 2016 at 03:07:22 UTC, Ali Çehreli wrote: Congratulations! Any project that can get rid of moc is a big achievement. :) Folks at CopperSpice had done the same in C++ with their Qt replacement: http://www.copperspice.com/ Ali Nice! I've never heard of them, interesting how they proved the moc maintainer partly wrong. On Thursday, 18 February 2016 at 03:36:20 UTC, ZombineDev wrote: Congratulations! This is an extremely promising result! BTW, what do you think about DMD's recent advancement in this area? Can you reuse some of this work for Calypso? When do you think you'll be ready to start upstreaming some of your work to LDC and/or DMD? https://github.com/D-Programming-Language/dmd/pull/5261 - Parameter types should have namespace std mangling too https://github.com/D-Programming-Language/dmd/pull/5262 - Add versioned-out branch to support new C++-11 implementations of std::string https://github.com/D-Programming-Language/druntime/pull/1470 - Add catching C++ exception support to dwarfeh.d https://github.com/D-Programming-Language/druntime/pull/1473 - add core.stdcpp.exception and core.stdcpp.typeinfo https://github.com/D-Programming-Language/dmd/pull/5330 - fix Issue 15389 - extern(C++) forward referencing problem https://github.com/D-Programming-Language/dmd/pull/5333 - fix Issue 15519 - Circular imports leads to fwd ref error with aliased imports https://github.com/D-Programming-Language/dmd/pull/5342 - C++ EH: initial front end work https://github.com/D-Programming-Language/dmd/pull/5361 - fix Issue 15579 - extern(C++) interfaces/multiple-inheritance https://github.com/D-Programming-Language/dmd/pull/5372 - fix Issue 15610 - extern(C++) multiple inheritance - calling with wrong 'this' ptr https://github.com/D-Programming-Language/dmd/pull/5397 - fix Issue 15644 - Switch object layout ABI to MI style https://github.com/D-Programming-Language/dmd/pull/5402 - fix Issue 15647 - Casting from one C++ interface in a hierarchy to another is a noop https://github.com/D-Programming-Language/dmd/pull/5403 - fix Issue 15626 - extern(C++) calling crash Most of Calypso lives independently from the C++ support in DMD, and instead queries Clang whenever possible on C++ matters. It was actually catching C++ exceptions some time before DMD (https://github.com/Syniurge/Calypso/tree/master/tests/calypso/eh), has no C++ multiple inheritance layout issue since that's handled by Clang, and the only way extern(C++) affects Calypso is by not reverting the order of function parameters so these functions can be correctly called by C++ code (function pointers, overridden virtual methods), and if I understand correctly this is only necessary because there's a discrepancy between DMD and what the docs say: http://forum.dlang.org/thread/zogygbvfszssudpae...@forum.dlang.org?page=2 When do you think you'll be ready to start upstreaming some of your work to LDC and/or DMD? My big concern is the switch to DDMD. It seems that the transition is going pretty smoothly for LDC, but what about Calypso's extensions to DMD? Calypso classes deriving from DMD ones will have to be converted to D and those classes happen to sollicit Clang's C++ API a lot, so I'm counting on C++ Calypso to build D Calypso meaning it has to be pretty solid at that point to support both Clang and LLVM. Anyway as long as both LDC and Calypso haven't both caught up with DDMD it's probably too early for upstreaming. The downside is that Calypso is marginalized, I don't get many testers (<- euphemism, only wilsonk helped a lot and right now I'm about the only one testing). The neglecting of MSVC, the "still experimental" label and the lack of releases probably don't help in that regard. It's not a big deal though since I have enough on my hands, coming next is the LDC 0.17 merge, and rework on the PCH generation that should increase the speed 3x according to cachegrind.
Qt's MOC getting replicated in D for Calypso
Hi all, I now have a working D replacement for moc: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/moc For those unfamiliar with Qt, moc (the Meta-Object Compiler) is a tool that generates additional code for Qt classes, code then used by the signal/slot system, properties and other Qt-specific extensions. While C++ moc is not going away for probably a very long time (http://woboq.com/blog/reflection-in-cpp-and-qt-moc.html), D's compile-time reflection makes it possible to replicate moc's functionality entirely with templates and CTFE, with the help of some Calypso features: C++ template instantiation, overriding C++ virtual methods, and member function pointers. Calypso had been partially supporting Qt5 for a while and there was a Qt5 demo written by Kelly Wilson, but to work around the lack of moc he had to write an intermediate C++ class with virtual slots and the signal <-> slot connections were done in C++ code. Now everything is in D: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d The moc package is as faithful as possible to Qt 5.5.0's moc. It's not finished yet (missing: properties, class info) but signals, slots and connections are working, making Qt 5 development in D much more practical than before.
Re: Fun with extern(C++)
On Tuesday, 26 January 2016 at 15:53:39 UTC, Manu wrote:
So, you're saying that if you have an 'I' pointer, which may be
implemented by a C++ class, it still needs to be able to cast
to Object, and therefore fails? I wonder if a C++ class could
somehow be promoted to a D class when being derived in D, by
having an Object placed somewhere.
It helps that Object is a just a handful of virtual methods.
On Tuesday, 26 January 2016 at 16:25:35 UTC, Benjamin Thaut wrote:
For a D class the first entry in the vtable is the classinfo.
Thus the problem if you derive a D class from a extern(C++)
base class. I don't see any way to actually fix this, adjusting
the this pointer won't help. Once you derive a D class from a
extern(C++) base class it is no longer a fully functional D
class. For example monitor (e.g. synchronized methods) won't
work.
Calypso has "hybrid" D classes inheriting from C++, with this
layout:
- D vptr
- D monitor
{ start of C++ class }
- C++ vptr
- C++ fields...
- might be other vptr and fields if the C++ class has more than
one base
{ end of C++ class }
- D fields...
and when downcasted to the C++ base class the "this" pointer gets
adjusted to point towards the start of the C++ class.
Re: Catching C++ Exceptions in D
On Tuesday, 5 January 2016 at 17:23:38 UTC, Walter Bright wrote: Function bodies cannot mix catching C++ and D exceptions. (The reason is C++ catch types need to be distinguished from D catch types, and the most straightforward method to deal with that is have a different 'personality' function for functions that catch C++ exceptions.) why not distinguish C++ exceptions from D ones in the personality routine?
Re: Catching C++ Exceptions in D
On Tuesday, 5 January 2016 at 20:07:11 UTC, Walter Bright wrote: On 1/5/2016 10:51 AM, Elie Morisse wrote: why not distinguish C++ exceptions from D ones in the personality routine? How? Are you aware of https://syniurgeblog.wordpress.com/2015/11/20/calypso-catching-cpp-exceptions-in-d/? For DMD if the personality functions sees the C++ exception class (3rd arg passed to the personality func) would it be hard to make it look for C++ catch clauses? With Calypso those catch clauses are std::type_info pointers wrapped inside a D class so that cast() is used to differentiate D catch clauses from C++ ones in the action table, and the personality function match those std::type_info against the one from the C++ exception header by calling the virtual function type_info::__do_catch(type_info*). A single personality routine handles both D and C++ exceptions, and I don't think having a different one for C++ exceptions would make things much easier. The tricky part for DMD is probably the std::type_info generation.
Re: Calypso progress report (+ updated MingW64 build)
On Wednesday, 25 November 2015 at 06:57:14 UTC, deadalnix wrote: I can't find the runtime that goes with this. My best guess was here: https://github.com/Syniurge/druntime/blob/release-0.16.1/src/ldc/eh/common.d But it doesn't check the source language. Can I get some pointers ? In case you haven't found already, the rest of the changes lies next door in libunwind.d. Then if you're after the differences from vanilla LDC you could ctrl+f for // CALYPSO comments (I've made a habit of tagging all the departures from vanilla code with these), or you could browse the diff from the single commit: https://github.com/Syniurge/druntime/commit/d33d8bf32c739bf9a30705dfc764718c817f16b1#diff-da783b0dc7ec2a5b78b6c4479a320d08
Re: Calypso progress report (+ updated MingW64 build)
On Tuesday, 24 November 2015 at 06:44:31 UTC, deadalnix wrote: Yeah that's what I wanted to look int he IR. Where is _D_ZTISt9exception7__tiwrap defined ? Looks like you trimed the output :( Sorry I got a little heavy handed, here's the full IR: https://paste.kde.org/piivojs0s
Re: Calypso progress report (+ updated MingW64 build)
On Monday, 23 November 2015 at 00:04:44 UTC, deadalnix wrote: I'd be very interested by the LLVM IR that this spout out. Here's the IR for https://github.com/Syniurge/Calypso/blob/master/tests/calypso/eh/std_exception.d : https://paste.kde.org/pjxrqjjhp Also, good work, pulling that one is hard. It wasn't that hard to be honest, I took many shortcuts thanks to Clang and Calypso. But even without them it's doable. About the issue you mentioned in the other thread, I don't think generating std::type_info values will be too big of a hindrance for Walter. Looking at cxxabi.h the classes derived from type_info all have simple layouts so generating values at least for classes singly inheriting from std::exception should be achievable without too much sweat.
Re: Calypso progress report (+ updated MingW64 build)
On Monday, 16 November 2015 at 19:35:58 UTC, Andrei Alexandrescu wrote: That's great progress. Do you have documentation for how things work? For example, what's the lifetime of the pointer people will get from std::exception::what(). IMHO: don't worry about catching exceptions by value; it's almost always either incorrect, uninteresting, or both. The prize is catching (references to) classes rooted in std::exception. Nice-to-have is catching (references to) classes rooted in other C++ classes. A blog post would be fantastic. Andrei Finally there: https://syniurgeblog.wordpress.com/2015/11/20/catching-cpp-exceptions-in-d/ Although a little late and probably less user-oriented than you wanted? For example, what's the lifetime of the pointer people will get from std::exception::what(). The exception object gets destroyed on exiting the catch (C++) block if the exception isn't rethrown.
Re: Calypso progress report (+ updated MingW64 build)
On Thursday, 22 October 2015 at 01:19:19 UTC, Andrei Alexandrescu
wrote:
Great news! What's the story on exceptions? Does Calypso allow
D code to catch exceptions thrown from C++ code? -- Andrei
Small update: the LDC 0.16.1 merge was done and it's now possible
to catch about any C++ exception with catch (C++) (..) {..}
statements.
https://github.com/Syniurge/Calypso/blob/master/tests/calypso/eh/std_exception.d
Output:
Throwing an ooops exception
Catching the ooops, e.what() == Ooops!
Throwing another ooops exception
Catching the std::exception, e.what() == Ooops!
Now throwing a float
Catching the float, f == 20.16!
What's left to implement for full C++ EH support:
- catching class/struct by value (it's already possible to catch
thrown class values by reference though)
- thrown object lifetime
- rethrowing
Re: Catching C++ std::exception in D
Sorry for the delay, here's the initial commit for C++ exception catching in Calypso: https://github.com/Syniurge/Calypso/commit/8b55ec1f013c29df86455ab055fbba91a72d92af https://github.com/Syniurge/druntime/commit/d33d8bf32c739bf9a30705dfc764718c817f16b1 The main files of interest are: https://github.com/Syniurge/druntime/blob/release-0.16.1/src/ldc/eh/cpp/gnu.d https://github.com/Syniurge/Calypso/blob/master/gen/cpp/cppeh.cpp And a basic example which segfaults at e.what() because __cxa_begin_catch returns null: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/eh/std_exception.d Resulting IR : https://paste.kde.org/pvi2bokqx catch (C++) were added to be able to catch any type, and that's the only cost for being able to catch any C++ exception and not just std::exception I think, Clang and the libstdc++ makes working with std::type_info very easy. For the time the handler uses unwind-cxx.h copied from GNU's libstdc++ (it's an internal header which doesn't ship with any Ubuntu package). Its license is more permissive than the GPL, but if it isn't compatible it could be replaced by its libc++ equivalent.
Re: Catching C++ std::exception in D
On Thursday, 12 November 2015 at 06:50:31 UTC, Walter Bright wrote: In order to interoperate with modern C++, it has been abundantly clear for some time that D needs some support for C++ exception handling: 1. Have D finally blocks executed in D code that sits between a C++ try and catch 2. Have C++ finally blocks executed in C++ code that sits between a D try and catch 3. Be able to catch in D code an std::exception* or a C++ class derived from that. 4. Throw an std::exception* from D code. That's the minimum credible support, and is likely all D will actually need. I also started working on C++ exception handling for LDC/Calypso, I almost caught my first std::exception yesterday! (it went into the right catch and the IR looks right but _cxa_begin_catch() seems to return null instead of the exception object for some reason) Clang and Calypso made the std::type_info stuff a breeze, getting the type_info value for any C++ type was one line of code. I'll push the changes as is into a branch tonight, it's about ~400 lines. The tricky part with the personality function will likely be recognizing std::exception* exceptions. I wonder if forwarding the call to __gxx_personality_v0 will work. From what I gathered even if you manage to make the format of the LSDA tables compatible with __gxx_personality_v0, one blocker is that it still expects std::type_info pointers in the action table so will choke if it encounters D's TypeInfo_Class in there. To check if a type_info from a catch clause handles the thrown exception it calls the virtual method type_info::__do_catch (which is what Calypso does too) so can't work with D classes.
Re: Calypso progress report (+ updated MingW64 build)
On Sunday, 25 October 2015 at 21:42:15 UTC, Stefan wrote:
Hello,
// compile with: ldc2 -cpp-args -std=gnu++11 main.d
modmap (C++) "cmath";
import (C++) std._;
import std.stdio;
int main()
{
writeln(sin(cast(float)0.8159));
return 0;
}
gives a lot of "error: constexpr function never produces a
constant expression" messages. Not sure this is supposed to
work?
Hi and thank you for testing!
The code compiles and runs with C++11 disabled, I don't know why
these errors occur while generating the PCH with C++11 enabled,
looking into it.
Re: Calypso progress report (+ updated MingW64 build)
On Monday, 26 October 2015 at 01:52:37 UTC, Laeeth Isharc wrote: any chance of some release builds on github when the time is right? I've tried a few times, and somewhat embarrassingly each time I get a bit further, but still never made it to a usable version of ldc-calypso. I didn't want to file bug report as figure you have better things to do at this stage and it's a moving target. ldc itself I can compile fine (without your mods). I'd be interested in seeing if quantlib is usable. it's a library that's quite popular in finance world, and might open up the set of people that are interested in exploring D. Hi Laeeth, Were you trying to build it on Linux? I uploaded a Linux build: http://www.homo-nebulus.fr/dlang/Calypso-x86_64-Ubuntu15_04-2015_10_25.tar.xz The build process got much simpler 2 weeks ago though, now that it doesn't depend on an LLVM source tree and an external Clang executable anymore it's almost identical to building LDC. Let me know how Calypso fares with quantlib.
Re: Calypso progress report (+ updated MingW64 build)
On Sunday, 25 October 2015 at 21:42:15 UTC, Stefan wrote:
Hello,
// compile with: ldc2 -cpp-args -std=gnu++11 main.d
modmap (C++) "cmath";
import (C++) std._;
import std.stdio;
int main()
{
writeln(sin(cast(float)0.8159));
return 0;
}
gives a lot of "error: constexpr function never produces a
constant expression" messages. Not sure this is supposed to
work?
It's fixed with the latest commit.
Re: Calypso progress report (+ updated MingW64 build)
On Friday, 23 October 2015 at 09:19:44 UTC, Kagamin wrote:
On Thursday, 22 October 2015 at 23:24:57 UTC, Elie Morisse
wrote:
Default constructors are invoked
Including class fields?
class A
{
QString s_myFilename;
this()
{
//is s_myFilename constructed already?
}
}
That triggered my own assert, oops. It's fixed now, the field
default ctor is called if the field has no initializer, just
before A's ctor.
Re: Calypso progress report (+ updated MingW64 build)
On Thursday, 22 October 2015 at 18:02:08 UTC, Kagamin wrote:
Cool, is that a value type QString? Really? Then functions in
Qt5 demo should accept QString by ref to better match C++.
Not sure if I already announced it here but one major change a
few months ago is that all C++ classes are now value types, it
made things a lot saner.
I think the reason why Kelly didn't use ref was to be able to
write loadFile(QString("myFilename")) instead of:
auto s_myFilename = QString("myFilename");
loadFile(s_myFilename); // only takes lvalues
Add me to the people who'd really love D to get through this once
and for all btw :)
Are copy constructors and assignment operator invoked?
As I see default constructors are not invoked yet?
Default constructors are invoked, and I should have added another
line to the list of main features:
• Maps C++ overloaded operators to D operators when an
equivalent exists (and others are mapped to normal functions
named e.g __opUnaryArrow for operator->)
Since D doesn't support non-member overloaded operators those
aren't usable as in C++, I need to work on a solution for this
(there's already some groundwork actually, non-member operators
that take for example a std::basic_string left operand are mapped
as part of the std.basic_string module).
Currently copy constructors aren't invoked when calling functions
with class/struct byval arguments, arguments are memcpy'd. This
is another important missing feature I should implement asap.
Re: Calypso progress report (+ updated MingW64 build)
On Thursday, 22 October 2015 at 06:28:06 UTC, Suliman wrote: Does it's mean, that Calypso can be work as plugin for Clang? As a LDC plugin, so that LDC doesn't depend on Clang. On Thursday, 22 October 2015 at 15:22:16 UTC, Szymon Gatner wrote: Wow, this is fantastic. What about Windows and iOS support? MSVC hasn't been tested since 5 months ago. Calypso built by MSVC compiles basic examples but last time we tried none of the C++ standard lib test cases worked. Maybe it's better now that the template support is more robust but I've postponed work on MSVC until LDC 0.16 which includes the Win64 work by kinke. The MingW x86 build works better and compiles most libstdc++ samples but hasn't been tested much either. I'll come back to MSVC after improving the C++11 support, because one Achilles' heel of Calypso is currently whenever template argument deduction is involved and both MSVC's standard lib and C++11-enabled GNU libstdc++ makes heavy usage of template argument deduction. It's because Calypso relies on a hack that doesn't handle every case yet, although the situation has improved a lot and it works well enough to handle some Boost libraries.
Re: Calypso progress report (+ updated MingW64 build)
On Thursday, 22 October 2015 at 01:19:19 UTC, Andrei Alexandrescu
wrote:
On 10/21/2015 07:40 PM, Elie Morisse wrote:
It's been a while since the last update, so here's a quick one
before
making the jump to LDC 0.16.
Great news! What's the story on exceptions? Does Calypso allow
D code to catch exceptions thrown from C++ code? -- Andrei
Hi Andrei,
Not yet but I've looked into it, the plan is to add:
catch (C++) (...) { }
statements and make Clang translate them into C++ landing pads
(as for imports the parser will query the language plugins when
encountering two pairs of (), so the C++-specific statement will
be part of Calypso, not DMD).
Then add a "C++ exception class" handler in LDC's personality
function:
https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/eh/libunwind.d#L327
Easier said that done but Clang should make the std::type_info
matching doable.
So it's on the roadmap just after the merge of LDC 0.16.
Calypso progress report (+ updated MingW64 build)
It's been a while since the last update, so here's a quick one before making the jump to LDC 0.16. Kelly added a more complex Qt5 demo, I recently added an Ogre3D one: https://www.youtube.com/watch?v=eryhDOa9MV0 https://github.com/Syniurge/Calypso/blob/master/tests/calypso/ogre3d/demo.d Ogre3D is a much more "sophisticated" creature than Qt5, relies on some Boost libraries, so Calypso had to reach quite another level to support it. As a reminder Calypso (https://github.com/Syniurge/Calypso) is an experimental LDC fork which lets you use C/C++ libraries without having to write bindings. Its main additions: • Maps C++ functions, global variables, structs, classes, unions, enums, typedefs, templates • C++ class and function template instantiation (including global variables inside class templates with their proper initialization in the global ctor) • C++ class creation with the correct calls to ctors (destruction is still disabled) • Virtual function calls • Static casts between C++ base and derived classes (incl. multiple inheritance offsets) • D classes inheriting from C++ classes, including the correct vtable generation for the C++ part of the class (except for MSVC which has a different ABI) • Debug info generation for any C++ symbol instantiated by D code The roadmap is: merge upstream LDC 0.16 into Calypso → C++ exception support → better C++11 support → MSVC support → extend magicport2 to convert Calypso to D (and Calypso could "bootstrap" itself to avoid writing bindings to Clang) → make Calypso an optional shared library On Linux Calypso should be in a state usable enough to start a project assuming the lack of C++ exceptions or class destruction isn't a blocker to start it (but I'm looking into the latter right now), it has held up quite well while expanding the Ogre and Qt5 demos, and my own project based on Qt5 and OpenCV. So far only Kelly Wilson has been testing Calypso with various libs and expanded the test cases (most of the libstdc++ samples are his), so more testing would be very helpful. Updated MingW build: http://www.homo-nebulus.fr/dlang/Calypso-Mingw64-i686-4.9.3-posix-dwarf-rt_v4-rev1.tar.xz
Re: DMD 2.68's promised C++ interface
On Monday, 20 July 2015 at 16:06:43 UTC, Shriramana Sharma wrote: I really really want to interface to Qt 5 and am groping in the dark here as to what to do with c'tors, inheritance, c c... Maybe not the original meaning of the promise but: http://forum.dlang.org/thread/xzjsdsuskarkllhmw...@forum.dlang.org Despite the lack of update it has kept progressing and I'm within an inch or two of breaking the silence and making a new announcement. It's pretty close to usability with C++ libraries of any complexity. The approach is not the official one though, and ties yourself to LDC until probably a very long time. (Calypso was helped by the code cleanness of Clang, does GCC offer things like template instantiation or vtable manipulation by an outsider without having to alter too much the code of GCC? and a DMD version would probably be multiple orders of magnitude harder to do)
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 17:44:38 UTC, CraigDillabaugh wrote: Just to clarify then. If gdalwarper.h includes gdal.h and GDALDatasetH is declared in gdal.h, then gdal.h gets imported too? Craig On Tuesday, 19 May 2015 at 19:57:45 UTC, Suliman wrote: How do you understand which files should be imported? +1 for question! modmap is only telling Clang which headers to parse. Then all those headers form a big monolithic AST that Calypso split into modules following a few rules: import (C++) namespace1.testStruct; // imports namespace1::testStruct import (C++) namespace2.testClass; // imports namespace2::testClass import (C++) test.anotherClass; // etc. each struct/class/enum template or not is placed in a module named after it import (C++) test.tempWithPartialSpecs; // imports the primary class template + all its partial and explicit specializations import (C++) test._; // « _ » is a special module that contains all the global variables, global functions and typedefs of a namespace (the ones which aren't nested inside a struct or a class, or another namespace). Why the header paths can't be used in imports is explained here: http://syniurge.blogspot.fr/2013/08/calypso-to-mars-first-contact.html#namingquestion Documentation is scarce at the moment, the examples (starting with showcase.d) try to give a quick overview of how to use Calypso but yep we really should write a tutorial of some sort, either I or Kelly will do it before DConf.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 17:44:38 UTC, CraigDillabaugh wrote: Just to clarify then. If gdalwarper.h includes gdal.h and GDALDatasetH is declared in gdal.h, then gdal.h gets imported too? Craig So to give a more straight answer, modmap is an #include directive so every header gdalwarper.h includes will be parsed too. But it doesn't import anything.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 08:02:47 UTC, Suliman wrote: Oh, I forgot to fix path at: /etc/ldc.conf Am I right understand that: C:/Program Files (x86)/ldc/lib = C:\Program Files (x86)\mingw-w64\i686-4.9.2-posix-dwarf-rt_v4-rev2\mingw32\lib ? Or I can't find more proper folder The Unix path for C:\Program Files (x86)\mingw-w64\i686-4.9.2-posix-dwarf-rt_v4-rev2\mingw32\lib is simply: /lib. ( The root the leftmost / refers to in every Unix path is C:\Program Files (x86)\mingw-w64\i686-4.9.2-posix-dwarf-rt_v4-rev2\mingw32 ) You're almost in uncharted territory, but thanks for helping with testing! I'll write clearer instructions for Windows too when I get the time. And BTW the MingW build is pretty old by now. I don't have much free time atm and I'm working on important fixes, but as soon as they're ready I'll update the MingW build.
Re: Calypso: Direct and full interfacing to C++
On Monday, 18 May 2015 at 12:27:35 UTC, Kagamin wrote: BTW how does it rely on having everything on the D side? Maybe it's enough to have just instance size and method symbols? I'm not sure what you mean. But then there's problem with this inference: what if the type is intended to be used as a reference type and you infer it to be POD, and it can also flicker between POD and non-POD depending on defines. This is true and it may not even be rare: turning C++11 on or off is doing it for some Qt classes. But there is another issue that will make me revisit their semantics anyway, it's that C++ structs and classes shouldn't be garbage collected because they weren't made with GC in mind and might have weak refs. So unless someone has a better solution C++ classes will go back to manual memory management, and the plan is while changing class and new's semantics to also make all C++ classes values.
Re: Calypso: Direct and full interfacing to C++
On Sunday, 17 May 2015 at 13:37:45 UTC, Suliman wrote: Where set where Calypso should look header files? It works the same as in C++, there are the standard header paths: /usr/include, /usr/include/c++/4.9, /usr/local/include And to add another header search path you can pass options to Clang with -cpp-args, i.e « ldc2 (...) -cpp-args -I/another/include/folder ». With the MingW version all those Unix paths refer to the MingW root directory.
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 13 May 2015 at 15:54:47 UTC, John Colvin wrote: That's great! I'm looking forward to being able to easily make direct use of some of the great C++ code out there. Are there are performance pitfalls to watch out for that are unique to the way calypso interfaces between D and C++? E.g. sneaky copies, implicit callbacks to keep things synced etc. There are a few: - Many simple non-POD C++ classes are being mapped to D classes instead of structs, for example QFlagsAlignmentFlag (qt5demo.d uses its alias Qt::Alignment) which is a wrapper around a single int but contains an overloaded assignment operator so is considered non-POD in C++. Same story for QString. string, vector, almost all STL types are non-POD too because they have base classes. So this may be inconvenient when trying to avoid heap allocations.. For QFlags and QString we could do more than just checking if the class/struct is POD according to the C++ definition (i.e we could ignore overloaded operators, which are allowed in D structs), but STL types will most likely stay that way. - For the time being when calling a C++ function taking a class value argument with FunctionB(new ClassA(...)), the ClassA instance is 1/GC-allocated 2/ctor is called 3/copied to the stack-allocated memory for the call. Whereas in C++ FunctionB(ClassA(...)) the ClassA constructor is directly called over the stack-allocated memory. In D there's no way to avoid the copy yet, I think we could mimic the C++ way but that'd involve another small alteration to the language. That's about it, I can't think of anything else, what's cool is that almost all symbols Calypso exposes are the C++ symbols themselves with no wrapper layer in-between, with a few exceptions such as overloaded operators opBinary!+ etc. which dispatch the call to the C++ operator mapped to a non-templated function (because the C++ overloaded operator might be virtual, it can't be mapped directly to a template).
Re: Calypso: Direct and full interfacing to C++
On Thursday, 14 May 2015 at 20:23:47 UTC, Laeeth Isharc wrote: Elie, Congratulations on this very impressive work. Out of curiosity, how far away do you think it is from being at a beta stage that one can use to write non-critical work in ? Thanks Laeeth, It's not too far I think. When finally comes the time when I can test one or two new complex libraries without triggering new bugs it should be good enough. At the moment I'm focusing on libraries that depend on Boost and are one order of magnitude more sophisticated than Qt, once they work the way out to usable state with any library may be in sight. One open source library that might not be too tough but would have high value in the financial domain is Quantlib. (I don't think it is heavily templated, but I don't yet know the codebase well). https://github.com/lballabio/quantlib Also, I am embarrassed to confess that I still have trouble building calypso (although I can build LDC fine). Specifically some symbols not found during compilation. I can pull them out if helpful, but I have tried several times over the past months and it is different ones each time. Missing symbols might be caused by your LLVM source tree having a different version from Arch's LLVM libraries. The changes made to LDC's CMake file are very primitive and won't check if the selected LLVM include/ and libraries match the one in LLVM_SOURCE_PATH added by Calypso. If you built and installed LLVM + Clang 3.6 yourself to /usr/local and if there's a different version from Arch packages in /usr, check that cmake got the right LLVM_CONFIG path with: $ cmake -LA |grep LLVM If it didn't fix the value with $ cmake -DLLVM_CONFIG=/usr/local/bin/llvm-config ../Calypso Which commit of Calypso should I use, and which versions of clang and llvm? I am using arch linux. The versions are the ones in the README, i.e the 3.6 branch of LLVM, Clang and compiler-rt. I'll add a note about the not very smart detection of LLVM libs, and if some of the instructions in the README are still confusing or incomplete please tell me.
Re: Calypso milestone hit: D adaptation of Qt5 tutorial working
On Saturday, 9 May 2015 at 19:16:33 UTC, Elie Morisse wrote: On Saturday, 9 May 2015 at 02:58:58 UTC, Mike wrote: Question: You are using a modified version of LDC, but is that compiler required to consume link to a library created with that custom compiler? What I mean is: Can you use this modified version of LDC to create a library, and then use a generic D compiler to build an application that links to that library? If you manage to hide every C++ symbol from the normal compiler I should have said, sorry for the vague answer. Linking would work like with normal D libraries, but the .d or .di files parsed by the normal compiler would have to be emptied of C++ imports so any symbol those imports provided shouldn't appear in the .di file.
Re: Calypso milestone hit: D adaptation of Qt5 tutorial working
On Saturday, 9 May 2015 at 02:58:58 UTC, Mike wrote: Question: You are using a modified version of LDC, but is that compiler required to consume link to a library created with that custom compiler? What I mean is: Can you use this modified version of LDC to create a library, and then use a generic D compiler to build an application that links to that library? If you manage to hide every C++ symbol, including C++ class/struct/enum types, that should work. On Saturday, 9 May 2015 at 09:56:03 UTC, Rainer Schuetze wrote: Probably discussed before, but as an alternative to a library, would it be possible to use the header generation (-H) to emit .di files compatible with other compilers? I don't think this is possible since C++ functions for instance are mapped directly and not wrapped inside a D function, and only the Clang libraries know how to properly emit a call.
Calypso milestone hit: D adaptation of Qt5 tutorial working
Hi! Calypso just got a D translation of the first Qt5 Widgets tutorial building and running: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d Result: http://homo-nebulus.fr/dlang/oh%20my.webm Compilation log: https://paste.kde.org/pewbbsw45 Previously Calypso was merely able to work with STL types, this is the first time a large C++ library is successfully mapped and used by D code (Ogre3D is probably close as well, but after Kagamin's suggestion and for a change of scene I switched my focus from Ogre3D to Qt).
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 22 April 2015 at 14:57:43 UTC, Kagamin wrote: What about Qt? I don't remember it being heavily templated. Thanks for the hint, it's definitely true for most of the code of Qt although there are still a few areas like QtCore/qtypetraits.h or Q_STATIC_ASSERT in non-C++11 mode that are tormenting Calypso (and helped fix bugs). But overall it seems like a much shorter list of errors compared to other libs, so there may be something to show soon :) On Wednesday, 29 April 2015 at 15:33:38 UTC, Kelly wrote: This isn't a problem anymore because Calypso can import libraries without an explicit namespace now, as long as it has a modulemap (that was part of the updating effort over the last week). Actually it's not due to that directly but because there were a few Qt global functions and variables (e.g in QtCore/qnumeric.h) that some Qt classes depend upon and caused a large part of the C standard lib to be imported, which would fail because there are some variables and structs that share the same name. It works properly now that symbols from the C standard lib are split across several modules (so no more name conflicts).
Re: Calypso: Direct and full interfacing to C++
On Thursday, 16 April 2015 at 06:43:25 UTC, Suliman wrote: Could anybody wrote very simple tutorial, that show how to use any popular C/C++ lib without binding? I mean step by step manual. Also it would be nice to get binary builds for Windows to test. Sorry for the wait. So Calypso still can't load the MSVC C++ standard lib. I thought Kelly managed to build some STL examples but actually it's not remotely possible yet. The main blocker is that template instances often depend on each other (but not in their entirety) which cause forward reference errors in DMD. However it works with MinGW-w64, but this wasn't remotely straightforward either, I had to modify Clang to make it detect correctly the MinGW paths (which are hardcoded in Clang and obsolete): - install mingw-w64, in the installer choose 4.9.2, DWARF exceptions and POSIX threads - download http://homo-nebulus.fr/dlang/Calypso_mingw-w64.7z - extract the archive over the MinGW root directory (where the bin/, etc/, etc. folders lie) - correct the paths in /etc/ldc.conf - add Z:\path\to\MingW\bin to your PATH environment variable in your System settings (e.g follow: http://geekswithblogs.net/renso/archive/2009/10/21/how-to-set-the-windows-path-in-windows-7.aspx) Then you can build the examples in tests/
Re: Calypso: Direct and full interfacing to C++
I should have given the same warning, there's a chance that Calypso may work with not too sophisticated C++ libraries but new bugs are around the corner if you try anything too big. Nevertheless Suliman, Laeeth and maybe others have been wanting to try it out in its current state, and it was useful because new errors seems to have appeared while compiling the STL examples by a MSVC build since Kelly's successful attempt two months ago (no idea whether it's because more of the MSVC runtime/standard lib gets mapped or because he used another standard lib?). So sorry for the wait but this is taking longer than expected, first I could only start building LLVM yesterday's evening because of slow download speeds, and today the MSVC build is triggering these new errors I'm investigating.
Re: Calypso: Direct and full interfacing to C++
On Thursday, 16 April 2015 at 06:43:25 UTC, Suliman wrote: Could anybody wrote very simple tutorial, that show how to use any popular C/C++ lib without binding? I mean step by step manual. Also it would be nice to get binary builds for Windows to test. Suliman sorry for keeping you waiting :) I'll be spending the evening installing MSVC and Qt Creator, and building Calypso for Windows users to play with and to help with testing. Expect binaries tomorrow. The usage should be clear just by looking at and building the examples in tests/calypso.
Re: Calypso: Direct and full interfacing to C++
Sorry for the lack of updates, progress was a bit boring for the past 2 months and consisted mostly in crawling my way up a bottomless pit of errors generated by « import (C++) Ogre.Light; ». And then this happens: https://paste.kde.org/pse8pqzch :D The compilation speed could be improved, more bugs should get triggered by actual usage of Ogre, but close to everything gets mapped, semantic'd and codegen'd and this is the milestone I've been working towards for months. Last week also introduced was the Clang module map file support, which helps breaking namespaces into smaller pieces and thus makes probably most C libraries usable right now without having to maintain bindings, only a module map file which may also be generated by clang-modularize.
Re: Mitigating the attribute proliferation - attribute inference for functions
Freeing D users from the burden of writing redundant attributes that the compiler can infer would be a fantastic enhancement imo. For public functions I was thinking of a way to make inference safer: generating a .di file with the inferred attributes and auto substituted by the return type, and then make the compiler check the inferred attributes against the previous ones and trigger an error if there was an API breakage, forcing the programmer to acknowledge it by removing the function from the .di file, or by fixing the function to match its previous signature. Would this make inference safe enough for public functions?
Re: C++ to D
On Tuesday, 31 March 2015 at 20:37:37 UTC, Jeff Jones wrote: Is it possible to modify either a C++ compiler or in code to make classes more D ish? e.g., instead of just the vtable(which, IIRC is slightly different between the two) add the metadata pointer and whatever else? What I'm getting at, is there a somewhat simple way(not creating a new C++ but either through macros, small compiler changes, or whatever) to make C++ objects D compatible instead of the other way? I.e., we can't take anything away from D classes since we will break D. But we should be able to add to C++ classes without breaking C++. If we can add the info that D needs then both should get along happily? I'm mainly talking about a simple code based solution but I'm also curious about how easily this would be by compiler modification. You can't make the layout of C++ classes inheriting from multiple bases match D's class layouts because D's multiple inheritance is more limited. Also a big downside is that D-flavored ABI C++ binaries couldn't interact easily with normal ABI C++ binaries because even if the modified C++ compiler is explicitly told which library/set of headers is normal and which isn't, the usage of any class from the normal C++ libs by D-flavored ones will form a mixture of both ABI so not usable by D, and it's not helping that some classes can be codegen'd into several libs. So every C++ lib would need to be recompiled to avoid the ramifications of interacting with both ABI? From my time poking around Clang's code it just seems easier and more convenient to reimplement C++ multiple inheritance and downcasts in DMD.
Re: Mid-term vision review
On Friday, 3 April 2015 at 21:59:38 UTC, Kai Nacke wrote: On Friday, 3 April 2015 at 18:04:14 UTC, deadalnix wrote: Also, what are the plan for GDC and LDC if we move toward DDMD ? My plan with LDC is to use the CPP backend to produce a boot strap compiler and then compile the D source. Much work... Regards, Kai Bindings for LLVM and GCC would still have to be written/generated (and work). Calypso could help with building D versions of GDC and LDC, H1 seems a bit early but it's shaping up.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 24 February 2015 at 08:44:25 UTC, Kagamin wrote: On Tuesday, 24 February 2015 at 08:39:39 UTC, Kelly wrote: due to class value support being incomplete What about using that trick: recognize C++ classes and represent them internally as structs with altered mangling - at least it frees you from messing with D classes. What about inheritance, polymorphism and virtual methods that aren't supported by D structs? I'm worried that it's going be a lot harder to reimplement everything in structs. Atm to quickly make functions that take or return class values work what's missing is implicit casts between the class value types I added recently (the hacky TypeValueof) and the normal class types, and support in codegen. So it's not too far away I think.
Re: DDMD just went green on all platforms for the first time
On Saturday, 21 February 2015 at 14:02:41 UTC, Daniel Murphy wrote: https://auto-tester.puremagic.com/?projectid=10 This is a pretty big milestone for the project. For the first time, an unpatched dmd can build ddmd, and that ddmd can build druntime and phobos and pass all the test suites. Hopefully in the next couple of weeks the remaining minor issues will be fixed (eg makefile changes, ddmd runs out of memory compiling std.algorithm unittests on win64) and we can start adding ddmd to master alongside the C++ compiler. A big thanks to Brad for upgrading the autotester, and to everyone who has helped fix bugs and get patches merged over the last couple of years. Github shows 376 closed DDMD pull requests, which is about 8% of all dmd pull requests ever. WOW!²
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 18 February 2015 at 08:52:33 UTC, Kelly wrote: Hello Elie, I just pushed a small pull request for fromTypeTemplateSpecialization. I forgot to mention in the request that the changes allow bitset.d to be compiled and run again. Thanks for looking into this, I'll check your PR. With those changes all the examples compile and run again. There are still two errors when compiling vector.d. Clang errors when making the pch file. LDC2 still runs and produces a working binary anyways. Not sure what you are working on, but I can look at those errors if you like. Are these errors occurring when Clang generates the PCH or later in the semantic pass? There might be errors during the instantiation of member functions of class templates because Calypso tries to instantiate everything (whereas Clang instantiates them lazily), but it's no big deal, later they'll be made silent. BTW I just pushed support for function template instantiation. So lately thanks to a bit of free time there has been quite a lot of new features implemented: overloaded operators, function templates, and groundwork for class value types (they were added to the AST as a new semi-hackish kind of type, they make mapping any C++ type possible but they can't be used directly from D code yet). Operators should make std::map usable, so I'm going to resume testing further STL types.
Re: Calypso: Direct and full interfacing to C++
Hi Kelly, It's done, I've merged latest LDC upstream + your build fixes into Calypso. About Microsoft vtables they work much more differently from the Itanium ones than I thought, it's going to a lot trickier than just a few lines of code so I won't be able to make D classes inheriting from C++ ones work on MSVC until I setup a dev environment on Windows. It's just those « D-C++ classes » though, the rest has a better chance to work now.
Re: Calypso: Direct and full interfacing to C++
On Sunday, 15 February 2015 at 11:48:50 UTC, Kelly wrote: Alirighty, Calypso builds and runs on both Linux and Win64 with that last change from today in my fork. Now when I say 'runs' on Linux, I mean it runs properly and fully (compiling and running all examples from Feb 8th)...but when I say 'runs' on Win64, I should say 'runs as far as it can' because there is an internal LLVM assert with getVTableContext Microsoft VTableContext not yet supported UGH! :( It's from Calypso actually, the assert is in gen/dcxxclasses.cpp and is only triggered by D classes inheriting from C++ classes with a vtable. If the rest works as usual on Linux you got the most important covered. I'll check your merge as soon as I'm done fixing a linking error with the std::string example the latest additions introduced, then I'll add the Microsoft VTableContext support so we could get those first working binaries for Windows users :) However LLVM and Clang 3.6 aren't even released yet (next week), IMHO it would be wiser to stick with 3.6 and get LDC/Calypso working with 3.6 until 3.7 is more stable. Did you mean that even LDC can't be built by MSVC with LLVM 3.6 atm?
Re: Calypso: Direct and full interfacing to C++
Anyway I'm probably fixing the last issue right now preventing std::vector from instantiating so I'm going to push the commits to master in the hour.
Re: Calypso: Direct and full interfacing to C++
On Friday, 13 February 2015 at 09:49:51 UTC, Kelly wrote: Hello Elie, Ok, I have merged in the newest LDC with Calypso from github today and built it with vs2013 on Win7 :) There is a small diff involved in getting things to compile. The resulting ldc2 runs and builds a simple hello world program, but it fails when trying to use calypso. I guess I've made a mistake with my patch since I am getting an assert in ASTReader with input for calypso to compile. I will look at it tomorrow and once I can get calypso to work I will push to my github fork. Hoping for better news tomorrow, Kelly Awesome news Kelly. Did you use rebase to merge? You've probably saved me a lot of work which I was planning to do this week-end after seeing your post about Win64 support. There are a dozen of new commits in store since last week-end for operator support and groundwork for class values, but mapping operators trigger new bugs which prevent std::vector from instantiating so I haven't pushed them yet to master, but do you want me to push them into a new branch so you can merge with the latest? Let me know when you make your fork available so I can check your merge and then incorporate it into master.
Re: Calypso: Direct and full interfacing to C++
On Monday, 9 February 2015 at 04:27:06 UTC, Kelly wrote: Thanks, just got that tangled mess of templates that is std::string working too: Hey Elie, this is great stuff, as usual. I have written a test file for bitset here also (including a couple failures I am sure you are aware of, but others might want to see what works and what doesn't). Hi Kelly, Good to see bitset instantiating and basically working too! Can I add your code to the tests? So yes to clear things up a bit, operators are still missing and so are many other features. Off the top of my head: - Function templates = the groundwork is here, they're already mapped and it shouldn't be too difficult to get them instantiating from D - Operators = probably easy to add although there might be differences between C++ and D operators - Functions with class values parameters aren't even mapped yet, since I haven't made my mind on how to handle class values. Despite the POD or not issue it still feels more consistent to treat C++ classes like D classes, while adding C++ class value types to DMD's types like C++ reference types were with TypeReference (which makes C++ variables with reference types usable but which can't be assigned as the types of D variables) - C++ reference types are supported by DMD but not by LDC yet, they only work for function parameters and return types since Calypso replace them by ref
Re: Calypso: Direct and full interfacing to C++
On Monday, 9 February 2015 at 07:10:56 UTC, Suliman wrote: If somebody have working Windows build, could you please share it? It would be nice to know if someone even managed to build Calypso on Windows yet :) On Monday, 9 February 2015 at 20:17:33 UTC, Andrei Alexandrescu wrote: You may want to put this on reddit too (unless you're the one who did): http://www.reddit.com/r/programming/comments/2vc0eg/calypso_dc_interface_using_stdvector_and/ Andrei Nice, I'll dust my antique barely used account if questions pop up.
Re: Calypso: Direct and full interfacing to C++
Small update: std::vector is now working. https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/vector.d I went back to simpler problems than getting Ogre to work and will focus on the C++ standard lib until the common class templates work.
Re: Calypso: Direct and full interfacing to C++
On Sunday, 8 February 2015 at 20:56:31 UTC, Syro wrote: That is really cool. Thanks, just got that tangled mess of templates that is std::string working too: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/string.d
Re: Calypso: Direct and full interfacing to C++
Hi Laeeth, Could you post the errors and which compiler you are using? If you managed to build both LDC and Clang you should be pretty close to get Calypso working. Would there be any chance you could fork a version of clang that works with Calypso, and then link to it in the instructions? As said in the README the 3.5 branch of LLVM/Clang should work, it's stable and there hasn't been a single commit since December 8: https://github.com/llvm-mirror/clang/commits/release_35
Re: Kythe
On Tuesday, 27 January 2015 at 18:55:13 UTC, Andrei Alexandrescu wrote: Google just open sourced https://github.com/google/kythe. Would it help Calypso? -- Andrei Not sure how it would help. Kythe seems to handle every C++ feature but if I understand correctly it translates the AST into its own representation and that's it with Clang, whereas Calypso needs to make Clang instantiate templates and to use its codegen. Maybe if Kythe was expanded it could serve as the basis for language extensions, make the writing of new plugins easier and more uniform. If they add GCC to the supported C++ compilers that'd form a single interface to both Clang and GCC's AST.
Re: Calypso and the future of D
On Monday, 26 January 2015 at 19:35:11 UTC, Laeeth Isharc wrote: I posted some thoughts on web docs writeup of C+= interface here. http://forum.dlang.org/thread/fmjehcyzhnirybmnj...@forum.dlang.org#post-fmjehcyzhnirybmnjloj:40forum.dlang.org Do you think we could make binaries of calypso available for download ? I know it is alpha, but it is so strategically important, and just getting clang to build is not always so easy given the stuff in gcc 4.9 with size__align_t ? We should mention calypso in the web docs, and link to it too (with appropriate caveats). It feel slightly too early, Calypso shouldn't be far from getting most of the C++ standard library to work but it still chokes on most tangles of templates (afaics it all boils down to a few issues). Also operators, function templates and merging latest LDC would be nice and not a lot of work away (last merge was mid-October, before better Win64 ABI support). As soon as this is done I'll make builds for Windows and Linux users.
Re: Calypso and the future of D
On Monday, 26 January 2015 at 00:37:02 UTC, Walter Bright wrote: Excuse the creator's bias :) I agree that Jacob's description makes things more clear, added!
Re: Calypso and the future of D
On Sunday, 25 January 2015 at 22:45:31 UTC, Walter Bright wrote: Not what I meant. What does parse.c have to do with the user of Calypso? How does the user use Calypso? Where is Calypso? How do I run Calypso? A user of Calypso will be baffled when encountering user documentation of Calypso that explains it in terms of dmd internal source code. Is the new README any better? Once I succeed making the nature of Calypso intelligible does the showcase example seem self-explaining enough to make the usage straightforward?
Re: Calypso and the future of D
On Sunday, 25 January 2015 at 10:18:34 UTC, Walter Bright wrote:
Next, in the README example, it says:
$ clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o
$ ar rcs libshowcase.a showcase.cpp.o
$ ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++
showcase.d
Where's Calypso in that?
On Sunday, 25 January 2015 at 11:12:50 UTC, Kelly wrote:
Calypso is part ldc2 and, as far as I understand it, is invoked
via the -cpp-args command line arg.
-cpp-args is only to pass arguments to Clang while generating the
precompiled header.
Calypso registers itself as a language plugin, and when parse.c
encounters « import (ABC) xxx.yyy; » it asks the registered
plugins if one of them handles the ABC language id. If that's
the case it lets the plugin create the Import symbol by itself,
for instance Calypso creates a cpp::Import which derives from
Import and has a completely different load() method, which won't
look for modules in .d files but inside the PCH generated by
Clang.
Here's the LangPlugin interface:
class LangPlugin
{
public:
// returns -1 if said lang isn't handled by this plugin, or
its id number
// to be passed to createImport otherwise
virtual int doesHandleModmap(const utf8_t *lang) = 0;
virtual Modmap *createModmap(int langId,
Loc loc, Expression *arg) = 0;
// returns -1 if said tree isn't handled by this plugin, or
its id number
// to be passed to createImport otherwise
virtual int doesHandleImport(const utf8_t *tree) = 0;
virtual Import *createImport(int treeId,
Loc loc, Identifiers *packages, Identifier *id,
Identifier *aliasId, int isstatic) = 0;
// = - - - - - = //
virtual Expression *getRightThis(Loc loc, Scope *sc,
AggregateDeclaration *ad,
Expression *e1, Declaration *var, int flag = 0) = 0;
// = - - - - - = //
virtual FuncDeclaration *buildDtor(AggregateDeclaration *ad,
Scope *sc) = 0;
virtual FuncDeclaration *buildCpCtor(StructDeclaration *sd,
Scope *sc) = 0;
// = - - - - - = //
virtual CodeGen *codegen() = 0;
};
getRightThis, buildDtor and buildCpCtor are needed because they
override the global functions with the same name.
About Andrei's query about a general plugin system I don't know
how one could be architectured. The hooks created for Calypso are
specific to C++, so the help I could get is simply to be open to
those hooks (which aren't really intrusive and don't uglify the
code except for one or two that could probably be done
differently:
https://github.com/Syniurge/Calypso/commit/debd83f49363bf6805573d141a62b25d068d8a14)
The problem with arbitrarily limiting where the hooks could occur
is that it might force the plugins to copy and paste redundantly
the base functions, which is bad especially for big semantic()
functions.
This probably deserves more thought, maybe there's a more elegant
way waiting to be found.
Re: Calypso and the future of D
The README should be clearer now about what Calypso is supposed to do, links to the showcase example which I improved and expanded with a template partial and explicit spec example, and explains how to build it and link it to a C++ library. (thanks to the simple partial spec example a nasty oversight about partial specializations was also fixed in the process, which may well be the #1 source of the snags I hit while importing Ogre)
Re: Calypso: Direct and full interfacing to C++
On Friday, 23 January 2015 at 12:29:56 UTC, Kelly wrote: Hello Elie, This project looks great, thanks for the hard work. I downloaded Calypso and ldc2 about 6 hours ago to try your project out. I can get Calypso to compile with a couple small changes to assistbuilder.cpp (just adding a namespace qualifier for two class instantiations of CodeGen). That is with clang-3.5 from todays svn. Maybe a recent clang commit has changed things? Once I had a working Calypso ldc2 build, I unfortunately couldn't get the showcase example to build. I just use the build line from your git page to try to build, but I get an 'undefined identifier size_t' error. The pch file is produced properly but then this error comes up...it seems like while compiling druntime from the '-v' output?? Maybe something changed in the druntime submodule in the last few days...but I didn't really look into it yet. I hacked a couple things to just get around this error and then things fail because libshowcase.a isn't available. I assume that is a remnant from an earlier compilation technique, because it appears everything is self contained in the .o files being produced and then linked on the command line...so I just thought I would let you know this part doesn't work. If you could give me a hint on the 'undefined identifier size_t' error, I can look into it a bit further here...I am just getting tired and probably not seeing what is going on there. If you are on #ldc I will be on there later today. Not sure what your username is in #ldc. At least one other person has been by asking if you were there also :) Thanks, Kelly (wilsonk-laptop) Thanks for the feedback Kelly, you're probably the first person to give it a serious try, sorry for the bumpy ride :) Since I was focused on getting Ogre working and neither rebuilt druntime/phobos nor tested the showcase example against the latest commits they might have broken something. Also the README forgets to say how libshowcase.a should be built: clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o ar rcs libshowcase.a showcase.cpp.o ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ showcase.d Adding this now. I'm going to fix the rest this afternoon (finally some free time), and also figure out why assistbuilder.cpp failed to compile against the latest Clang 3.5. Also going to setup a testing script to ensure not everything gets broken again by a commit.
Re: Calypso: Direct and full interfacing to C++
On Friday, 23 January 2015 at 10:02:55 UTC, Jacob Carlborg wrote: Could this work for Objective-C as well. I'm working on adding support for Objective-C to DMD [1]. [1] https://github.com/D-Programming-Language/dmd/pull/4321 It's planned to add Objective-C to Calypso, although I never used it and know little about it. Would you be interested in implementing support for its different flavors in Calypso, Jacob? You'd be welcome to the team :-)
Re: Calypso and the future of D
On Friday, 23 January 2015 at 00:24:45 UTC, Andrei Alexandrescu wrote: I think it's important that we enable Calypso (https://github.com/Syniurge/Calypso) and related tooling that interfaces D with other languages, notably C++. A key topic in 2015 for D is playing well with C++. A good C++ interface will give access to a host of mature C++ libraries, starting of course with the C++ standard library. More importantly, it will provide a smooth migration path for organizations that want to do development in D whilst taking advantage of their legacy code. I'd like to open the topic of what can we do in core D to make Calypso better. But first, I want to get better acquainted with Calypso and raise awareness of it with coworkers and the larger community. To my dismay, the github homepage provides exactly zero look and feel use examples beyond the mechanics of building Calypso itself. To Calypso's creator: is it possible to beef up the documentation of Calypso with a few use cases? Ideally there'd be a soup-to-nuts step by step guide of making a C++ library (either artificial or extant) interfacing with D. Also: what things on the D side would be necessary to make the interface better? Exceptions would be an obvious topic on which we have an attack already (more on it later). Andrei thanks for finally sharing your thoughts on the matter :-) I'll see what I can do this week-end to expand examples and write a tutorial. As for what could be done in core D, I haven't struck anything blocking while writing Calypso. Exception catching is next after the first light of my Ogre3D demo, Clang will probably simplify handling of C++ exceptions a lot.
Re: Calypso: Direct and full interfacing to C++
Nevermind it's just that CodeGen is ambiguous with clang::CodeGen although my compiler doesn't complain. Fixed.
Re: Calypso: Direct and full interfacing to C++
On Friday, 23 January 2015 at 23:06:16 UTC, Kelly wrote: People might still need the small quick fixes for gen/cpp/assistbuilder.cpp, but just adding clang:: in a couple spots shouldn't be too arduous for anybody if they really want to compile and play with Calypso. Weird, assistbuilder.cpp compiled fine here with up-to-date Clang 3.5. Did you checkout the 3.5 branch?
Re: Calypso: Direct and full interfacing to C++
On Thursday, 22 January 2015 at 07:27:03 UTC, Suliman wrote: First you need a LLVM + Clang 3.5 source tree, built libraries and the Clang binaries. Installing binary packages from your distribution isn't enough since the include/ files aren't exposing many symbols, so the source packages are needed as well Do I need to compile from source just Clang or both? Usually Clang is built with LLVM, i.e running make inside the LLVM build directory will build both LLVM and Clang. On Thursday, 22 January 2015 at 07:07:42 UTC, Suliman wrote: Currently making D classes derive from C++ classes with a virtual table only works with MinGW because only the Itanium ABI is supported. I'm going to add the Microsoft ABI ASAP (it's just a few lines of code) but it'll be untested. Could you explain can I call function from C++ dll directly? I am need only basic C++ support -- just ability to call very basic functions. Am I right understand that with Calypso I do not need to create bindings? If it's correct - could you provide any example of calling C++ function from dll? On Windows the Clang executable has to be in one of the %PATH% folders and then in your D code: modmap (C++) headerofyourdll.h; // will make Clang generate a precompiled header import (C++) Namespace1.Namespace2._; // If your functions are global functions inside Namespace1.Namespace2, _ is a special module (for now) that contains all the global funcs, vars and typedefs import (C++) Namespace1.Struct1; // If they are inside a struct named Struct1 The imports expose symbols that you can use like you'd use D structs and functions. Finally you need to tell LDC to link to your library: ldc -L=yourDLL.lib (...)
Re: Calypso: Direct and full interfacing to C++
On Thursday, 22 January 2015 at 00:08:13 UTC, Walter Bright wrote: Just making STL work would be an achievement! Is the output of Calypso a file that can be imported? The only outputs specific to Calypso are ligthweight object files per C++ module that contain symbols created by LDC for aggregates (InitZ...) and template specializations by Clang if they're not defined in the PCH. What Calypso basically does is tell Clang to generate a big PCH for all the headers in modmap directives, and to map on demand C++ declarations from the PCH to D symbols in a separate tree of modules (hence the (C++) in imports, they're not physical modules). Those symbols can be used like D's, although they have different implementations to handle the C++ specificities, and all the non-trivial semantic work is done by Clang libraries and queried back by Calypso (aggregate layout, partial template argument deduction, ...). There are still some very feels hackish areas like the fact that DMD considers C++ classes to derive from Object too (fortunately Object is only a handful of virtual functions), I haven't solved yet how class values should be treated, etc. Also the PCH is a temporary solution because at the time I began working on Calypso Clang's support for modules was broken. But they would be great to break the global namespace in smaller pieces, so now that they seem ready to use the plan is to replace the PCH by them, or by a slightly different flavor of them (because there's currently one limitation that reduces its usefulness, it's that one header can't be split across several modules).
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 21 January 2015 at 10:37:18 UTC, Suliman wrote: Could you explain how to build it's on Windows. I read readme, but do not fully understand what I should to to to get it's work? You should follow the guides for LDC only you need to build Clang 3.5 as well beforehand and add the -DLLVM_SOURCE_PATH=/path/to/llvm/source/tree argument to the cmake command while building Calypso. Using Visual Studio: http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC Using MinGW : http://wiki.dlang.org/Building_LDC_on_MinGW_x86 Currently making D classes derive from C++ classes with a virtual table only works with MinGW because only the Itanium ABI is supported. I'm going to add the Microsoft ABI ASAP (it's just a few lines of code) but it'll be untested. On Wednesday, 21 January 2015 at 21:27:27 UTC, Walter Bright wrote: I think this is an exciting development! Considering the new D support for C++ namespaces, template mangling, etc., I think it would make Calypso's job easier. The big challenge is to get an interface to C++ STL, so one could do: import core.stdcpp.stl.vector; for example. I'd also like to encourage you to submit a Dconf 2015 presentation proposal on this. Thanks, Walter! A small update since the announcement: instantiation of C++ class templates is now working, with the right partial specialization selected if any. I'm still working as fast as I can to get Ogre3D working. Ogre3D makes wide usage of the standard C++ library so getting it running would be a milestone and at that point most C++ libraries will be usable or in close reach as well. And it'd also make a sweet demo :)
Re: @api: One attribute to rule them All
On Tuesday, 6 January 2015 at 12:07:21 UTC, Joseph Rushton
Wakeling wrote:
I think you have missed the point I was making.
If you have final-by-default for classes, and you accidentally
forget to tag a public method as 'virtual', then you can fix
that without breaking any downstream user's code. If by
contrast you have virtual-by-default and you accidentally
forget to tag a public method as 'final', then you can't fix
that without the risk of breaking downstream; _someone_ may
have relied on that function being virtual.
For people making libraries which really need to keep ABI
compatibility there should be some quick trick to tell the
compiler to build those ABI-stable interfaces like:
class {
final @api:
...
virtual @api:
...
}
It's imho a small price to pay for not having to always write
explicit attributes for most D functions.
Re: D and Nim
On Sunday, 4 January 2015 at 18:10:52 UTC, Jonathan wrote: Hey folks, I've been recently checking out Nim/rod and feel like it takes a lot of inspiration from D (I think the creator was in the D community too as some point). How do you think it compares? What areas does D, in principle, makes it a better choice? To give you my background, I like creating games (mostly using SDL bindings) using new languages, aiming for the most efficient yet concise way to write the engine and game logic. FYI, this is NOT a language war thread. I'm just curious about what separates them from a principle level. D and Nim have similar goals (conciseness, CTFE, other advanced metaprogramming features to reduce code redundancies to zero..), but although Nim has cool ideas it's not without some drawbacks: - Only limited polymorphism, Nim doesn't use virtual tables but dispatch trees for performance, and that means that you can't have opaque base classes running derived methods if the overriding methods are unknown to the compiler: http://nim-lang.org/manual.html#multi-methods http://forum.nimrod-lang.org/t/278 - No conditional evaluation of code - No type traits - Declarations are order-dependent - Generics are redundant with templates (they are going to be removed though: http://forum.nimrod-lang.org/t/638 ) IMHO the two languages are similar but D is more advanced, and apart from AST macros I don't see any notable appealing features from Nim compared to D.
Re: Happy new year!
Happy new year everyone!
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 23 December 2014 at 11:53:38 UTC, Dicebot wrote:
By upstream I don't mean LDC upstream but D upstream - we don't
want it to become part of full language spec if implementation
is so reliable on specific toolchain. It has been already
discussed when Jacob proposed dstep integration AFAIR.
Actually it's meant to be optional and Calypso should ultimately
go in a separate shared library.
As I implemented it I added this virtual function to Dsymbol:
virtual LangPlugin *langPlugin() { return NULL; }
The import (C++) create cpp::Decl which derive from the DMD
Decl and override some of its parent methods. E.g:
bool isBaseOf(::ClassDeclaration* cd, int* poffset) override;
makes isBaseOf take into account multiple inheritance and ask
Clang to compute the right offsets.
Then in gen/, there is a different kind of hook which checks if a
langPlugin is attached to the declaration:
if (auto lp = s-langPlugin()) // yeah C++11, it's a prototype
return lp-codeGen()-toCallFunction(s, ...);
And that way neither DMD nor LDC has to depend on Clang. The
intrusions are the methods made virtual and the hooks, but if no
language extension is present LDC would work as usual.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 23 December 2014 at 15:20:18 UTC, Kagamin wrote: On Monday, 22 December 2014 at 23:14:44 UTC, Elie Morisse wrote: • Structs https://github.com/Syniurge/Calypso/blob/master/tests/calypso/showcase.d testClass cls = new testInherit; This should be written testClass* cls = new testInherit; In C++ struct and class differ only in symbol mangling. They are both value types, support inheritance, copy constructors etc. By looking at the declaration you can't decide if a class should be used as value type or reference type, so better treat it as value type like in C++. At the moment Calypso maps C++ POD records to D structs, and non-POD ones to D classes. But then it's true that this creates a conundrum because I can't translate class value types to D types, so currently functions that expect class value arguments are ignored. Making C++ classes value types would have lots of implications, so the way I see it (for now, not sure if that's the best solution) I'll probably stick to D class semantics but I'll have to create C++-specific class value types to map C++ fields or functions that take class value arguments.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 23 December 2014 at 15:20:18 UTC, Kagamin wrote: On Monday, 22 December 2014 at 23:14:44 UTC, Elie Morisse wrote: • Structs https://github.com/Syniurge/Calypso/blob/master/tests/calypso/showcase.d testClass cls = new testInherit; This should be written testClass* cls = new testInherit; In C++ struct and class differ only in symbol mangling. They are both value types, support inheritance, copy constructors etc. By looking at the declaration you can't decide if a class should be used as value type or reference type, so better treat it as value type like in C++. Ah and you're right that this might confuse the user since he has to know whether the class/struct is POD or not to know whether to use values or references. Hmm.. also simply adding a virtual function to a C++ class would break the D code which previously considered that class POD :) So maybe you're right, it might be a better idea to make C++ classes values.
Calypso: Direct and full interfacing to C++
Hi everyone, I have the pleasure to announce to you all the existence of a modified LDC able to interface directly to C++ libraries, wiping out the need to write bindings: https://github.com/Syniurge/Calypso It's at a prototype stage, but its C++ support is pretty wide already: • Global variables • Functions • Structs • Unions (symbol only) • Enums • Typedefs • C++ class creation with the correct calls to ctors (destruction is disabled for now) • Virtual function calls • Static casts between C++ base and derived classes (incl. multiple inheritance offsets) • Mapping template implicit and explicit specializations already in the PCH to DMD ones, no new specialization on the D side yet • D classes inheriting from C++ ones, including the correct vtable generation for the C++ part of the class So what is this sorcery? Let's remind ourselves that this isn't supposed to be feasible: Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable. http://dlang.org/cpp_interface.html Well.. it is :D Calypso introduces the modmap keyword, as in: modmap (C++) cppheader.h; to generate with the help of Clang libraries a virtual tree of C++ modules. Then after making Clang generate a PCH for all the headers, the PCH is loaded and classes, structs, enums are placed inside modules named after them, while global variables and functions are in a special module named _. For example: import (C++) Namespace.SomeClass; // imports Namespace::SomeClass import (C++) Namespace._; // imports all the global variables and functions in Namespace import (C++) _ : myCfunc, myGlobalVar; // importing the global namespace = bad idea, but selective imports work Being a prototype, I didn't really pay attention to code conventions or elegance and instead focused on getting things working. And being tied to LDC and Clang (I have no idea how feasible a GCC version would be), it's going to stay like this for some time until I get feedback from the contributors on how this all should really be implemented,. For example Calypso introduces language plugins, to minimize the amount of code specific to C++ and to make support of foreign languages cleaner and less intrusive, although it of course needs numerous hooks here and there in DMD and LDC. Calypso is still WIP, but it's in pretty good shape and already works in a lot of test cases (see tests/calypso/), and is almost ready to use for C++ libraries at least. Since C libraries are in the global namespace, it's not a convenient replacement yet for bindings until I implement the Clang module map format. More info this blog post detailing some of the history behind Calypso: http://syniurge.blogspot.com/2013/08/calypso-to-mars-first-contact.html So.. Merry Christmas dear D community? :) My take on the current talks of feature freezing D: the strength of D is its sophistication. The core reason why D fails to attract more users isn't the frequent compiler bugs or regressions, but the huge amount of time needed to get something done because neither equivalent nor bindings exist for most big and widespread C++ libraries like Qt. All these talks about making D a more minimalist language won't solve much and will only result in holding back D, which has the potential to become a superset of all the good in other system languages, as well as bringing its own powerful unique features such as metaprogramming done right. By removing the main reason why D wasn't a practical choice, this will hopefully unlock the situation and make D gain momentum as well as attract more contributors to the compilers to fix bugs and regressions before releases.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 23 December 2014 at 00:01:30 UTC, Rikki Cattermole wrote: Will you be upstreaming this? Or maintaining this completely yourself? The ultimate goal is upstream, but first I need to agree with the main DMD and LDC contributors about how this should really be done. I.e atm the Calypso code coexists with the vanilla C++ support which has a different coding philosophy and is more intertwined with the rest of the code. So I expect that I'll have to maintain it myself quite some time before this happens. And of course I'll make Calypso catch up with upstream LDC frequently.
Re: 2 types of D users, both can live together happily if we adjust
On Friday, 28 November 2014 at 20:00:36 UTC, Vic wrote: (...) IMHO you should be ready to debug the compiler. DMD's codebase can be obscure at times (while the LDC mid-end is pretty straightforward) so the first time looking for the source of a bug may be a frustrating and time-consuming learning experience, but you'll be empowered to tackle compiler bugs without relying on volunteers to do it for you, and without stopping D from evolving.
Re: Stroustrup's slides about c++11 and c++14
On Saturday, 13 September 2014 at 20:10:55 UTC, eles wrote:
Are those points valid?:
static if is a total abomination
• Unstructured, can do everything (just like goto)
• Complicates static analysis (AST-based tools get hard to
write)
• Blocks the path for concepts
• Specifies how things are done (implementation)
• Is three slightly different “ifs” using a common syntax
• Redefines the meaning of common notation (such as { ... })
The lack of « something like static if » in C++ and his
opposition to it (which dates back from many years ago) is what
made me search for better languages and discover D.
C++ has only half-assed metaprogramming limited to types, and the
lack of static if has forced me so many times to rewrite very
similar code from one function to another.
With D I can have a « function skeleton » and avoid all
redundancies with static if. Plus mixins expand enormously on the
C preprocessor (although AST macros would be even better).
IMHO it's all good for D, full-featured metaprogramming is a
killer feature and can save a great amount of time and headaches.
The more backwards C++ chooses to remain the faster alternatives
will grow.
