## digitalmars.D.announce - Calypso: Direct and full interfacing to C++

• Elie Morisse (73/78) Dec 22 2014 Hi everyone,
• Rikki Cattermole (5/77) Dec 22 2014 That really should be a pragma.
• Elie Morisse (10/12) Dec 22 2014 The ultimate goal is upstream, but first I need to agree with the
• Dicebot (15/22) Dec 22 2014 Well, technically speaking you DO include fully functional C++
• Jacob Carlborg (11/15) Dec 23 2014 This is pretty cool, but I'm not so sure if this will be accepted in
• Kagamin (8/11) Dec 23 2014 This should be written
• Elie Morisse (11/22) Dec 23 2014 At the moment Calypso maps C++ POD records to D structs, and
• Elie Morisse (8/19) Dec 23 2014 Ah and you're right that this might confuse the user since he has
• Kagamin (8/8) Dec 24 2014 Or it can switch depending on preprocessor definitions:
• Suliman (5/5) Jan 21 2015 "First you need a LLVM + Clang 3.5 source tree, built libraries
• Suliman (3/3) Jan 22 2015 I can't build clang. I am getting strange error:
• "Ulrich =?UTF-8?B?S8O8dHRsZXIi?= <kuettler gmail.com> (4/7) Dec 23 2014 This is nothing short of amazing. I do not know much about
• Suliman (2/2) Jan 21 2015 Could you explain how to build it's on Windows. I read readme,
• Elie Morisse (24/36) Jan 21 2015 You should follow the guides for LDC only you need to build Clang
• Walter Bright (3/7) Jan 21 2015 Just making STL work would be an achievement!
• Elie Morisse (26/28) Jan 22 2015 The only outputs specific to Calypso are ligthweight object files
• Kiith-Sa (2/2) Jan 22 2015 Just in case you don't follow digitalmars.D:
• Kelly (28/28) Jan 23 2015 Hello Elie,
• Elie Morisse (16/46) Jan 23 2015 Thanks for the feedback Kelly, you're probably the first person
• Kelly (18/35) Jan 23 2015 Hello Elie,
• Kelly (10/10) Jan 23 2015 Hello Elie,
• Elie Morisse (3/7) Jan 23 2015 Weird, assistbuilder.cpp compiled fine here with up-to-date Clang
• Elie Morisse (2/2) Jan 23 2015 Nevermind it's just that CodeGen is ambiguous with clang::CodeGen
• Laeeth Isharc (15/17) Jan 29 2015 Hi Elie.
• Elie Morisse (9/10) Jan 29 2015 Hi Laeeth,
• Elie Morisse (6/6) Feb 08 2015 Small update: std::vector is now working.
• Syro (2/5) Feb 08 2015 That is really cool.
• Elie Morisse (4/5) Feb 08 2015 Thanks, just got that tangled mess of templates that is
• Elvis Zhou (2/7) Feb 08 2015 Congrats! This is definitely an exciting news!!
• Kelly (71/79) Feb 08 2015 Hey Elie, this is great stuff, as usual. I have written a test
• Kelly (3/3) Feb 08 2015 Ugh, this forum needs a preview button!!
• Suliman (1/1) Feb 08 2015 If somebody have working Windows build, could you please share it?
• Elie Morisse (7/13) Feb 09 2015 It would be nice to know if someone even managed to build Calypso
• Kelly (59/64) Feb 11 2015 Hello Elie,
• Kelly (19/24) Feb 12 2015 Hello Elie,
• Kelly (13/18) Feb 13 2015 Hello Elie,
• Elie Morisse (12/24) Feb 13 2015 Awesome news Kelly. Did you use rebase to merge? You've probably
• Elie Morisse (3/3) Feb 13 2015 Anyway I'm probably fixing the last issue right now preventing
• Kelly (12/15) Feb 13 2015 Hello Elie,
• Kelly (24/24) Feb 14 2015 Ok, I have pushed my changes to Calypso on github. I did this
• Kelly (26/26) Feb 15 2015 Alirighty, Calypso builds and runs on both Linux and Win64 with
• Elie Morisse (13/20) Feb 15 2015 It's from Calypso actually, the assert is in gen/dcxxclasses.cpp
• Kelly (16/29) Feb 15 2015 Ah, sorry I see it now...there is the assert and then a backtrace
• Kagamin (2/2) Feb 16 2015 http://forum.dlang.org/post/mbqt88$a6n$1@digitalmars.com looks
• Kelly (42/42) Feb 16 2015 Hello Elie,
• Elie Morisse (10/10) Feb 16 2015 Hi Kelly,
• Kelly (14/24) Feb 16 2015 Alright, cool. I pulled it here and things build fine on Linux.
• Kelly (17/17) Feb 18 2015 Hello Elie,
• Elie Morisse (17/28) Feb 18 2015 Are these errors occurring when Clang generates the PCH or later
• Kelly (23/32) Feb 24 2015 Just so others know, coding of Calypso continues and more of the
• Kagamin (4/5) Feb 24 2015 What about using that trick: recognize C++ classes and represent
• Elie Morisse (9/14) Feb 24 2015 What about inheritance, polymorphism and virtual methods that
• Elie Morisse (14/14) Apr 15 2015 Sorry for the lack of updates, progress was a bit boring for the
• lobo (7/21) Apr 15 2015 Wow, this is great stuff!
• Kelly (6/20) Apr 15 2015 Amazing stuff Elie!! It has been a pleasure watching this come
• deadalnix (2/16) Apr 15 2015 Why do all compiler devs are french ?
• Suliman (3/3) Apr 15 2015 Could anybody wrote very simple tutorial, that show how to use
• Elie Morisse (7/11) Apr 16 2015 Suliman sorry for keeping you waiting :)
• Laeeth Isharc (9/21) Apr 16 2015 Thanks for doing all of this - an impressive effort by a single
• Kelly (33/45) Apr 17 2015 Hello Elie,
• Elie Morisse (13/13) Apr 18 2015 I should have given the same warning, there's a chance that
• Elie Morisse (21/25) Apr 21 2015 Sorry for the wait.
• Kagamin (2/7) Apr 22 2015 What about Qt? I don't remember it being heavily templated.
• Kelly (44/45) Apr 23 2015 Hello Kagamin,
• Kagamin (2/4) Apr 29 2015 Aren't there precompiled versions?
• Kelly (12/16) Apr 29 2015 Kagamin,
• Kelly (24/24) Apr 29 2015 A small update may be appropriate. We have run into a couple
• Elie Morisse (15/20) Apr 29 2015 Thanks for the hint, it's definitely true for most of the code of
• Kelly (23/23) May 12 2015 Well the first fully working example of a large library is
• Abdulhaq (2/13) May 13 2015 This really is a huge leap, congratulations!
• John Colvin (6/30) May 13 2015 That's great! I'm looking forward to being able to easily make
• Kagamin (3/6) May 14 2015 As I understand, the major remaining issue is value type classes
• Elie Morisse (30/35) May 14 2015 There are a few:
• Laeeth Isharc (17/17) May 14 2015 Elie,
• Elie Morisse (25/41) May 14 2015 Thanks Laeeth,
• Suliman (1/1) May 17 2015 Where set where Calypso should look header files?
• Suliman (11/11) May 17 2015 Could you show how translate this example to get it's compile
• Kelly (7/8) May 18 2015 Suliman,
• Elie Morisse (8/9) May 19 2015 It works the same as in C++, there are the standard header paths:
• Kagamin (7/15) May 18 2015 BTW how does it rely on having everything on the D side? Maybe
• Suliman (20/20) May 19 2015 I can't understand how to use Calypso. I did:
• Elie Morisse (11/17) May 19 2015 This is true and it may not even be rare: turning C++11 on or off
• Kagamin (8/12) May 20 2015 I mean a workaround for current D frontend ability to work with
• Suliman (6/6) May 19 2015 Oh, I forgot to fix path at:
• Suliman (12/12) May 19 2015 modmap (C++) "";
• CraigDillabaugh (3/15) May 19 2015 Perhaps you also need to include the GDAL headers, as I suspect
• Kelly (15/34) May 19 2015 Hi Craig,
• CraigDillabaugh (5/40) May 19 2015 Kelly,
• Suliman (9/16) May 19 2015 GDALWarpOptions* is type?
• Kelly (40/56) May 19 2015 These aren't files being imported, they are
• Elie Morisse (23/29) May 19 2015 modmap is only telling Clang which headers to parse. Then all
• Elie Morisse (4/8) May 19 2015 So to give a more straight answer, modmap "is" an #include
• Kelly (26/38) May 19 2015 Hello Suliman,
• Kelly (14/26) May 30 2015 Ok, this example for GDAL should work out-of-the-box with Calypso
• suliman (3/14) May 31 2015 I would wait next new binary build, becouse building process
• Elie Morisse (12/18) May 19 2015 The Unix path for C:\Program Files
• Kagamin (8/8) Jul 19 2016 Aren't objects rarely passed by value? What's more interesting is
• Elvis Zhou (1/1) May 22 2017 Seems this is abandoned? And why?
• Kagamin (2/5) Feb 09 2015 http://pastebin.com/
• Elie Morisse (21/27) Feb 09 2015 Hi Kelly,
• Kelly (9/30) Feb 09 2015 Hello Elie,
• Andrei Alexandrescu (4/9) Feb 09 2015 You may want to put this on reddit too (unless you're the one who did):
• Suliman (7/11) Jan 21 2015 Could you explain can I call function from C++ dll directly? I am
• Elie Morisse (18/36) Jan 22 2015 Usually Clang is built with LLVM, i.e running make inside the
• Walter Bright (8/12) Jan 21 2015 I think this is an exciting development!
• Jacob Carlborg (6/11) Jan 23 2015 Could this work for Objective-C as well. I'm working on adding support
• Elie Morisse (5/8) Jan 23 2015 It's planned to add Objective-C to Calypso, although I never used
• Jacob Carlborg (5/9) Jan 23 2015 For the time being I think I need to focus on getting the Objective-C
"Elie Morisse" <syniurge gmail.com> writes:
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

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

to generate with the help of Clang libraries a "virtual" tree of
C++ modules. Then after making Clang generate a PCH for all the
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
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
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.

Dec 22 2014
Rikki Cattermole <alphaglosined gmail.com> writes:
On 23/12/2014 12:14 p.m., Elie Morisse wrote:
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:

That really should be a pragma.
Since pragma's are the way to instruct the compiler to do something.

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.

Will you be upstreaming this? Or maintaining this completely yourself?

Dec 22 2014
"Elie Morisse" <syniurge gmail.com> writes:
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.

Dec 22 2014
"Dicebot" <public dicebot.lv> writes:
On Monday, 22 December 2014 at 23:14:44 UTC, Elie Morisse wrote:
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

Well, technically speaking you DO include fully functional C++
compiler front end with much more than 10 man-years of time
invested - it just happens that it is already available and
called clang :)

Project itself is very cool but I am in doubts about possibility
of merging this upstream. Doing so would make full D
implementation effectively impossible without some C++ compiler
already available as a library on same platform - quite a
restriction!

I think it is better suited as LDC extension and would discourage
its usage in public open-source projects sticking to old way of C
binding generation instead. For more in-house projects it looks
like an absolute killer and exactly the thing Facebook guys
wanted :)

Dec 22 2014
"Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Tuesday, 23 December 2014 at 07:18:01 UTC, Dicebot wrote:
Project itself is very cool but I am in doubts about
possibility of merging this upstream. Doing so would make full
D implementation effectively impossible without some C++
compiler already available as a library on same platform -
quite a restriction!

Just to be clear, you're talking about needing the C++
compiler-as-library on the platform where the compiler is being
run, right?

I don't see how that prevents upstreaming, so long as it's made
clear that it's platform-dependent. Are there any particular

I think it is better suited as LDC extension and would
discourage its usage in public open-source projects sticking to
old way of C binding generation instead. For more in-house
projects it looks like an absolute killer and exactly the thing

Agree that it's best suited as an extension, but that doesn't
prevent it being an official part of the LDC codebase. The most
problematic aspect is that it divides the compilers in terms of
features supported. As you suggest, for public  projects, it's
not nice to bind people to a single compiler.

Dec 23 2014
"Dicebot" <public dicebot.lv> writes:
On Tuesday, 23 December 2014 at 10:52:58 UTC, Joseph Rushton
Wakeling wrote:
On Tuesday, 23 December 2014 at 07:18:01 UTC, Dicebot wrote:
Just to be clear, you're talking about needing the C++
compiler-as-library on the platform where the compiler is being
run, right?

I don't see how that prevents upstreaming, so long as it's made
clear that it's platform-dependent. Are there any particular

Consider both things like embedded/MIPS and Windows64 - LLVM
tooling is not as strong on those right now, GCC does not provide
such easy way to reuse C++ frontend and with DMD/MSVC it is
simply beyond feasibility.

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.

Dec 23 2014
"Elie Morisse" <syniurge gmail.com> writes:
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.

Dec 23 2014
"CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Tuesday, 23 December 2014 at 11:53:38 UTC, Dicebot wrote:
On Tuesday, 23 December 2014 at 10:52:58 UTC, Joseph Rushton
Wakeling wrote:
clip

Consider both things like embedded/MIPS and Windows64 - LLVM
tooling is not as strong on those right now, GCC does not
provide such easy way to reuse C++ frontend and with DMD/MSVC
it is simply beyond feasibility.

clip

Regarding GCC C++ frontend, will this be of help (also recently
posted on this list):


Dec 23 2014
Iain Buclaw via Digitalmars-d-announce writes:
On 23 Dec 2014 13:30, "CraigDillabaugh via Digitalmars-d-announce" <
digitalmars-d-announce puremagic.com> wrote:
On Tuesday, 23 December 2014 at 11:53:38 UTC, Dicebot wrote:
On Tuesday, 23 December 2014 at 10:52:58 UTC, Joseph Rushton Wakeling

wrote:
clip

Consider both things like embedded/MIPS and Windows64 - LLVM tooling is

not as strong on those right now, GCC does not provide such easy way to
reuse C++ frontend and with DMD/MSVC it is simply beyond feasibility.
clip

Regarding GCC C++ frontend, will this be of help (also recently posted on

this list):

I would say no.  The interface exposed by the jit frontend only supports a
small subset of C-like code at this point in time.  And doesn't allow you
to access other frontends.

Iain.

Dec 27 2014
"Kagamin" <spam here.lot> writes:
On Tuesday, 23 December 2014 at 07:18:01 UTC, Dicebot wrote:
Project itself is very cool but I am in doubts about
possibility of merging this upstream. Doing so would make full
D implementation effectively impossible without some C++
compiler already available as a library on same platform -
quite a restriction!

Why C++? Any language can be plugged in.

On Tuesday, 23 December 2014 at 11:53:38 UTC, Dicebot wrote:
Consider both things like embedded/MIPS and Windows64 - LLVM
tooling is not as strong on those right now

Win64 is nearing completion. LDC can compile and run code for

provide such easy way to reuse C++ frontend and with DMD/MSVC
it is simply beyond feasibility.

AFAIK, clang features MSVC compatibility.

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.

Another reason is to ease integration with C++. Language plugin
is an obvious solution.

Dec 23 2014
Jacob Carlborg <doob me.com> writes:
On 2014-12-23 00:14, Elie Morisse wrote:
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:

This is pretty cool, but I'm not so sure if this will be accepted in
upstream.

I did something similar myself [1] with the help of DStep [2]. I
basically linked DStep with DMD which called DStep to generate a
temporary D file with the bindings. DMD would then read the temporary
file as if it was there before starting the compilation.

[1] http://forum.dlang.org/thread/ks3kir$1ubq$1 digitalmars.com
[2] https://github.com/jacob-carlborg/dstep

--
/Jacob Carlborg

Dec 23 2014
"Kagamin" <spam here.lot> writes:
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++.

Dec 23 2014
"Elie Morisse" <syniurge gmail.com> writes:
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.

Dec 23 2014
"Elie Morisse" <syniurge gmail.com> writes:
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.

Dec 23 2014
"Kagamin" <spam here.lot> writes:
Or it can switch depending on preprocessor definitions:
---
class WXDLLIMPEXP_BASE wxString
#ifdef wxNEEDS_WXSTRING_PRINTF_MIXIN
: public wxStringPrintfMixin
#endif
{
---

Dec 24 2014
"Suliman" <evermind live.ru> writes:
"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?

Jan 21 2015
"Suliman" <evermind live.ru> writes:
I can't build clang. I am getting strange error:
D:\llvm\cfe-3.5.0.src\cfe-3.5.0.src>make
Error on line 23: expecting target : dependencies

Jan 22 2015
"Ulrich =?UTF-8?B?S8O8dHRsZXIi?= <kuettler gmail.com> writes:
 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:

This is nothing short of amazing. I do not know much about
streams, up and down. But getting the fantastic toy language that
is D to seamlessly integrate C++ puts the whole thing to a new
level. There is nothing that can compare.

Dec 23 2014
"Suliman" <evermind live.ru> writes:
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?

Jan 21 2015
"Elie Morisse" <syniurge gmail.com> writes:
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 :)

Jan 21 2015
Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2015 3:21 PM, Elie Morisse wrote:
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 :)

Just making STL work would be an achievement!

Is the output of Calypso a file that can be imported?

Jan 21 2015
"Elie Morisse" <syniurge gmail.com> writes:
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).

Jan 22 2015
"Kiith-Sa" <kiithsacmp gmail.com> writes:
Just in case you don't follow digitalmars.D:

http://forum.dlang.org/thread/m9s4cd$2s1v$1 digitalmars.com#post-m9s4cd:242s1v:241:40digitalmars.com

Jan 22 2015
"Kelly" <wilsonk cpsc.ucalgary.ca> writes:
Hello Elie,

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)

Jan 23 2015
"Elie Morisse" <syniurge gmail.com> writes:
On Friday, 23 January 2015 at 12:29:56 UTC, Kelly wrote:
Hello Elie,

This project looks great, thanks for the hard work. I
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

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.

Jan 23 2015
"Kelly" <wilsonk cpsc.ucalgary.ca> writes:
Hello Elie,

Just a little build script until cmake can be used properly:

#!/bin/bash
set -x

clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o
ar rcs libshowcase.a showcase.cpp.o
/bin/rm calypso_cache*
ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ showcase.d

I remove the the calypso_cache otherwise there will be an error
if a previous build failed and the C++ files get modified.

It looks like the 'undefined identifier size_t;' error is just
from testStruct. If I comment out all refs/uses to testStruct
then things compile and run fine. Good stuff.

Thanks,
Kelly

P.S. If I find a little time, I'll try to get up to speed on the
code base :)

On Friday, 23 January 2015 at 17:18:22 UTC, Elie Morisse wrote:
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

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.


Jan 23 2015
"Kelly" <wilsonk cpsc.ucalgary.ca> writes:
Hello Elie,

The small patch for defining size_t works here. Thanks.

I just wanted to let people know that showcase.d should build
fine (one deprecation warning, but not a big deal).

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.

Thanks,
Kelly

Jan 23 2015
"Elie Morisse" <syniurge gmail.com> writes:
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?

Jan 23 2015
"Elie Morisse" <syniurge gmail.com> writes:
Nevermind it's just that CodeGen is ambiguous with clang::CodeGen
although my compiler doesn't complain. Fixed.

Jan 23 2015
"Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
On Saturday, 24 January 2015 at 00:51:49 UTC, Elie Morisse wrote:
Nevermind it's just that CodeGen is ambiguous with
clang::CodeGen although my compiler doesn't complain. Fixed.

Hi Elie.

We are really excited about your project, as it really opens up
new possibilities and will certainly save many months of time.

I have struggled with building Calypso and tried various
different recent release versions of clang to no avail.
(LDC/LLVM/clang build without problem).  I will post build errors
shortly

Would there be any chance you could fork a version of clang that
works with Calypso, and then link to it in the instructions?

Later it might also be worth using the D port of the dlang
update.sh tool that I wrote so one can automate the process of
moving parts that it is easy for something to break.

Laeeth.

Jan 29 2015
"Elie Morisse" <syniurge gmail.com> writes:
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

Jan 29 2015
"Elie Morisse" <syniurge gmail.com> writes:
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.

Feb 08 2015
"Syro" <sryobee gmail.com> writes:
On Sunday, 8 February 2015 at 16:49:44 UTC, Elie Morisse wrote:
Small update: std::vector is now working.

https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/vector.d

That is really cool.

Feb 08 2015
"Elie Morisse" <syniurge gmail.com> writes:
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

Feb 08 2015
"Elvis Zhou" <elvis.x.zhou gmail.com> writes:
On Sunday, 8 February 2015 at 22:45:14 UTC, Elie Morisse wrote:
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

Congrats! This is definitely an exciting news!!

Feb 08 2015
"Kelly" <wilsonk cpsc.ucalgary.ca> writes:
On Sunday, 8 February 2015 at 22:45:14 UTC, Elie Morisse wrote:
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:

On Sunday, 8 February 2015 at 22:45:14 UTC, Elie Morisse wrote:
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:

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).

/**
* std::bitset example.
*
* Build with:
*   ldc2 -L-lstdc++ bitset.d */ modmap (C++) "bitset"; import std.stdio; import (C++) std.bitset; void main() { enum : ulong { A=0, B, C, D, E, F, G, H, numColors }; auto usedColors = new bitset!(numColors); usedColors.set(A, true); usedColors.set(C, true); writeln("usedColors.len=\t", numColors); // '8' as it should be write("usedColors = \t"); if (usedColors.any()) // any() works { for(int i=0; i<usedColors.size; i++) // size seems to work if (usedColors.test(i)) // works write('1'); else write('0'); write('\n'); // prints 10100000 for usedColors } // seems backwards also see 'b' below // is this right? writeln("C bit = \t", usedColors.test(C)); // true as it should be writeln("count = \t", usedColors.count()); // seems like count is // working...returns 2 writeln("as ulong = \t", usedColors.to_ulong); // '5' is correct writeln("all = \t\t", usedColors.all); writeln("none = \t\t", usedColors.none); // these work writeln("any = \t\t", usedColors.any); usedColors.flip(C); writeln("C flipped = \t", usedColors.test(C)); // false as appropriate write("b = \t\t"); auto a = new bitset!(4u)(0b0110); auto b = new bitset!(4u)(0b1101); for(int i=0; i<b.size; i++) // size seems to work { if (b.test(i)) write('1'); // prints out 1011 for 'b' else write('0'); } write('\n'); writeln("b as ulong = \t", b.to_ulong); // '13' is correct // FAILURE in phobos format.d // writeln(b); // FAILURE because the [] operator isn't recognised // writeln(usedColors[C]); // FAILURE on operators again // auto d = a&b; } Thanks, Kelly  Feb 08 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: Ugh, this forum needs a preview button!! Sorry about the poor formatting, Kelly  Feb 08 2015 "Suliman" <evermind live.ru> writes: If somebody have working Windows build, could you please share it?  Feb 08 2015 "Elie Morisse" <syniurge gmail.com> writes: 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.  Feb 09 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: On Monday, 9 February 2015 at 22:38:51 UTC, Elie Morisse wrote: 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 :) Hello Elie, I did manage to build Calypso on Win7, and the resulting binary works to produce an obj file, but linking of a full executable fails :( I am getting "file contains invalid .pdata contributions" when trying to link. Trass3r over on ldc's github page was getting this error at one point also, but I don't know what the solution was. It seems like this was back in Aug 2014 so I would have thought any changes needed were picked up by Calypso when you forked in Oct. I would post an issue with ldc but Calypso isn't up to date, so it might not be really fair as the fix may be in the newest ldc. I can't see anything standing out in the commits for an issue like this, but I might just be missing it. Thanks, Kelly P.S. There is a small patch needed to compile on windows with VS2013. Things should still build fine on Linux with the patch. Here it is: diff --git a/dmd2/cpp/cppimport.cpp b/dmd2/cpp/cppimport.cpp index 709f324..2dec2ae 100644 --- a/dmd2/cpp/cppimport.cpp +++ b/dmd2/cpp/cppimport.cpp -6,7 +6,10 #include "cpp/calypso.h" #include "expression.h" +#ifndef _MSC_VER #include <unistd.h> +#endif + #include <stdlib.h> #include <stdio.h> diff --git a/dmd2/cpp/cppmodule.cpp b/dmd2/cpp/cppmodule.cpp index 114f3f0..385cb79 100644 --- a/dmd2/cpp/cppmodule.cpp +++ b/dmd2/cpp/cppmodule.cpp -21,7 +21,10 #include "cppexpression.h" #include "cpptemplate.h" +#ifndef _MSC_VER #include <unistd.h> +#endif + #include <stdio.h> #include <stdlib.h> diff --git a/dmd2/mars.h b/dmd2/mars.h index b22dc5b..fc8f798 100644 --- a/dmd2/mars.h +++ b/dmd2/mars.h -270,8 +270,8 struct Compiler const char *vendor; // Compiler backend name }; -struct LangPlugin; -typedef Array<struct LangPlugin *> LangPlugins; +class LangPlugin; +typedef Array<class LangPlugin *> LangPlugins; typedef unsigned structalign_t; #define STRUCTALIGN_DEFAULT ((structalign_t) ~0)  Feb 11 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: On Monday, 9 February 2015 at 22:38:51 UTC, Elie Morisse wrote: 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 :) Hello Elie, I have tried to build and use a few versions of Calypso/ldc with vs2013 and only the newest combination of LLVM and ldc from git work. llvm-3.6 with the corresponding ldc doesn't compile cleanly and neither does llvm-3.5 with ldc or Calypso with vs2013. Lastly Calypso with llvm3.7git doesn't compile, which is to be expected because of the many win64 patches that have been pushed to ldc the last couple months. Anyways, I just thought I would let you, and any interested others, know that Calypso won't build and run properly (or at least I couldn't get it to build/run) on Win7 with vs2013 today. Maybe things would work with llvm-3.5 and mingw with clang? I don't think so, though. I'll take a look at merging together Calypso and ldc since the split, if you like...hopefully not many conflicts. Not sure what all changed in llvm between 3.5 and 3.7, though. Thanks, Kelly  Feb 12 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: On Monday, 9 February 2015 at 22:38:51 UTC, Elie Morisse wrote: 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 :) 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  Feb 13 2015 "Elie Morisse" <syniurge gmail.com> writes: 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.  Feb 13 2015 "Elie Morisse" <syniurge gmail.com> writes: 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.  Feb 13 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: On Friday, 13 February 2015 at 17:54:25 UTC, Elie Morisse wrote: 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. Hello Elie, You can push to master, if you like, because we'll just have to go through and update everything either way. Hopefully not too many collisions or changes for llvm-3.7. Most of the changes I made are just slight modifications without new code, so there really shouldn't be too many collisions. Just going to start working on this ASTReader assert. Once it works, I will push to my fork, or I might just pull in your changes and see what happens. Thanks, Kelly  Feb 13 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: Ok, I have pushed my changes to Calypso on github. I did this mostly for testing because I wanted to make sure things still compiled on linux. Unfortunately, we need specific versions of llvm and clang to get things compiled as ldc2 hasn't been updated to the bleeding edge as of today. The versions I used on Win64 and Linux (didn't test OS X, but I can if needed) are: llvm: 77b557430c1315ef50c3256cdc5e73ac54d0154e Clang: baa701f47b7856f848080b51bc4fbcf984d29faa So, it took me a while to figure out that some problems weren't ours, but rather with compiling calypso (or ldc) with llvm from git today. Things build and will compile D programs as is, but fail on Win64 and Linux today for calypso specific code. Elie, perhaps you can see what is wrong just looking at my revisions? I would suspect the problem is in astunit.cpp because ASTReader is where the error is coming from. Anyways, take a look if you like. I would like to get this problem figured out before importing the last couple days worth of Calypso changes. I'll work on it some more in a few hours since I have a usable linux install again...WIN64 is just painful to work on for me, so I'll get things working and merged on Linux first and then move back to WIN64 :) Thanks, Kelly  Feb 14 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: 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! :( Well...that is a stopper on Win64, period. I imagine this will be addressed fairly quickly because LLVM is moving extremely fast on Win64...at least I hope that will be the case!! So that leaves us with Calypso up to the last commit on February 8th, LDC from yesterday (Feb 14th) and with LLVM-3.7/Clang using the revision hashes above. I will make sure all this builds and works on OS X now...wish me luck :) I will also try to pull in the latest Calypso commits from the last couple days, and merge it with LDC so that we are all up to date and synced with LDC from yesterday. Unfortunately we are stuck with bleeding edge on all this stuff, (even when LLVM-3.6 stable comes out next week) because most of the Win64 code in LLVM and LDC has been added in just the last few weeks. Anyways, hopefully you can just spend time on the internal Calypso stuff this way Elie, and not waste time poking around with the Win64 build right now. Thanks, Kelly  Feb 15 2015 "Elie Morisse" <syniurge gmail.com> writes: 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?  Feb 15 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: On Sunday, 15 February 2015 at 14:03:22 UTC, Elie Morisse wrote: 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. Ah, sorry I see it now...there is the assert and then a backtrace that indicates that an llvm file had the assert, but the actual error does print from within dxxclasses.cpp before the assert code backtrace. 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 :) Ok, cool. Hopefully that is the only difficulty left. 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? Actually, I am not totally sure whether the current LDC will build with 3.6 on Win64. I didn't want to try it until 3.6 is finalized because building takes forever on Windoze!!!!!!! Probably 10 times slower than Linux/OSX...and my Win7 machine is a dual quad-core i7 with 12GB RAM!! A much better machine than my Linux machines. Anyways, once 3.6 final comes out we'll have to see if it works, I guess. Thanks, Kelly  Feb 15 2015 "Kagamin" <spam here.lot> writes: http://forum.dlang.org/post/mbqt88a6n$1 digitalmars.com looks like C++ class support is shifting to value types.  Feb 16 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: Hello Elie, Ok, I tried to build on OS X with the LLVM/Clang revisions from above and the Calypso/LDC code from my github fork, but it is a no go. Calypso compiles pretty easily, but there are issues with "vector" not being found, so then I install libc++ so that clang easily picks up the correct include directories. Then "unistd.h" isn't found...ok it turns out XCode Command Line Tools needs to be installed to get some gcc specific files, but the internal Calypso call to clang needs to be modified. Change Calypso to call 'xcrun --show-sdk-path, because this seems to work from the command line. Needs to be run from a shell...ugh. Etc, etc. Run into problems with libc++ and libstdc++ colliding. Remove libc++. Ugh. I finally just compile things by hand and get through to Calypso running and producing a bunch of object files, but then gcc won't link in some allocator code from stdc++?? Sheesh, not sure what is going on...I have tried several different ways to fix this, to no avail. Anyways, I am tired so I will just have to mess with this some more tomorrow or the next day. Hopefully I can figure out what is going on as it seems close to working. There might be real issues with someone having libc++ and libstdc++ alongside XCode tools like I had. Thanks, Kelly P.S. I try out Calypso from your github repo most days and the vector/bitset/showcase examples weren't working with todays code --> "Do not call _d_invariant on C++ class objects". Just to make sure you are aware of it.  Feb 16 2015 "Elie Morisse" <syniurge gmail.com> writes: 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.  Feb 16 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: On Tuesday, 17 February 2015 at 01:53:22 UTC, Elie Morisse wrote: Hi Kelly, It's done, I've merged latest LDC upstream + your build fixes into Calypso. Alright, cool. I pulled it here and things build fine on Linux. Showcase and string examples work nicely. 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. Ok, developing on Win is not the nicest right now. I use Qt and it seems like the best option (change to msvc when needed...like to change the Debug/Release build types because the command line and Qt don't seem persistent). It's just those « D-C++ classes » though, the rest has a better chance to work now. Ok, I might try to build again here and see how it goes. Thanks, Kelly P.S. I HATE THIS FORUM EDITOR----please add a preview button, whoever takes care of this!?!? I take notes in a different editor and then paste here and it looks fine, only to end up mangled when actually submitted...ugh!!!! :)  Feb 16 2015 Ben Boeckel via Digitalmars-d-announce writes: On Tue, Feb 17, 2015 at 02:16:57 +0000, Kelly via Digitalmars-d-announce wrote: P.S. I HATE THIS FORUM EDITOR----please add a preview button, whoever takes care of this!?!? I take notes in a different editor and then paste here and it looks fine, only to end up mangled when actually submitted...ugh!!!! :) You can subscribe via email. --Ben  Feb 16 2015 "Kagamin" <spam here.lot> writes: On Tuesday, 17 February 2015 at 02:16:58 UTC, Kelly wrote: P.S. I HATE THIS FORUM EDITOR----please add a preview button, whoever takes care of this!?!? I take notes in a different editor and then paste here and it looks fine, only to end up mangled when actually submitted...ugh!!!! :) You mean wrapping? Don't wrap the text manually, server does on its own.  Feb 16 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: 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. 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. Do you have an email address I can get in touch with you at? Jump on to #ldc on IRC and pm me if you don't want to post here. I didn't look at the build errors on OS X again yet...got tired of build errors for a bit :) Thanks, Kelly  Feb 18 2015 "Elie Morisse" <syniurge gmail.com> writes: 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.  Feb 18 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: On Wednesday, 18 February 2015 at 16:18:10 UTC, Elie Morisse wrote: 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. Just so others know, coding of Calypso continues and more of the STL is working now. Currently these C++ files can be mapped and used from a D program with Calypso: bitset deque foreach list map set stack string vector vstring <-- just a vector of strings, but at least using classes in combination is working. Not all functions in these files work, but a significant portion do in most cases above. Iterators are still not working due to class value support being incomplete, but hopefully it will be working soon. Thanks to Elie for moving forward with this. Coding continues :) Thanks, Kelly  Feb 24 2015 "Kagamin" <spam here.lot> writes: 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.  Feb 24 2015 "Elie Morisse" <syniurge gmail.com> writes: 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.  Feb 24 2015 "Elie Morisse" <syniurge gmail.com> writes: 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.  Apr 15 2015 "lobo" <swamplobo gmail.com> writes: On Thursday, 16 April 2015 at 00:47:31 UTC, Elie Morisse wrote: 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. Wow, this is great stuff! I'd love to get this working with VTK! I currently have half-baked bindings that still have a bunch of bugs. This looks like a much more interesting approach. bye, lobo  Apr 15 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: Amazing stuff Elie!! It has been a pleasure watching this come together. Looking forward to testing and using Calypso. A huge and impressive milestone :) Thanks, Kelly On Thursday, 16 April 2015 at 00:47:31 UTC, Elie Morisse wrote: 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.  Apr 15 2015 "deadalnix" <deadalnix gmail.com> writes: On Thursday, 16 April 2015 at 00:47:31 UTC, Elie Morisse wrote: 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. Why do all compiler devs are french ?  Apr 15 2015 "Suliman" <evermind live.ru> writes: 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.  Apr 15 2015 "Elie Morisse" <syniurge gmail.com> writes: 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.  Apr 16 2015 "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes: On Thursday, 16 April 2015 at 16:42:42 UTC, Elie Morisse wrote: 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. Thanks for doing all of this - an impressive effort by a single person. Is it worth writing a quick D build script to automate downloading and building the whole thing? There are lots of different little bits to get right that become invisible with experience. "Everything's easy when you know how to do it". I got stuck at various points previously, but I will have another go, and if I get there this time will turn into a quick script.  Apr 16 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: Hello Elie, Elie...I added some more examples for some of the tests in libstdc++ to a new PR. The main reason for this is that iterators for lists and vectors work now (for those that were keeping track, they didn't work last month or thereabouts). This makes things work quite well for several of the STL files now. I thought I would also point out, to those that are following this thread, that I have tried at least a half dozen libraries (like zeromq, vecmathlib, dlib, etc.) and I haven't been able to get any of them to work for anything really meaningful. There is still one fairly major compilation error in the ScopeChecker that keeps popping up for all of these libs and a few STL files. I just wanted to point this out, as it seems from a couple comments, that people might be expecting to be able to just use C++ libs with Calypso straight away, and that isn't quite the case today. Some impressive stuff does work though...check out the libstdc++ examples. So, my point is that while some impressive things compile (like CImg, which is a 50,000 line header file!! ... actually you need to comment out 3 lines of preprocessor code but close enough) and you might be able to instantiate a few classes and/or templates, I don't think any significant lib will actually work out-of-the-box with Calypso right now...but it is very close, I think. I just wanted to be clear about this so that there isn't too much of a shock for anyone trying to use Calypso right away :) Any automatic build script would be nice to have Laeeth :) Once useful portions of a 'popular' (or requested) C++ lib work with Calypso, I will be happy to write up a step by step tutorial, but I don't think it is quite at that point yet. Thanks, Kelly On Thursday, 16 April 2015 at 16:42:42 UTC, Elie Morisse wrote: 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.  Apr 17 2015 "Elie Morisse" <syniurge gmail.com> writes: 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.  Apr 18 2015 "Elie Morisse" <syniurge gmail.com> writes: 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/  Apr 21 2015 "Kagamin" <spam here.lot> writes: On Tuesday, 21 April 2015 at 15:21:20 UTC, Elie Morisse wrote: 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. What about Qt? I don't remember it being heavily templated.  Apr 22 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: On Wednesday, 22 April 2015 at 14:57:43 UTC, Kagamin wrote: What about Qt? I don't remember it being heavily templated. Hello Kagamin, I haven't tried Qt yet because it needs to be hand-compiled with a user supplied namespace, otherwise there isn't a namespace to import with Calypso. I have also looked at it a bit and it uses some of the STL files that still don't compile with Calypso, like <iterator>, etc. so it is probably a no-go at this point. On a brighter note things are looking extremely close for some other libs (and one lib finally works...see below :) ). Here is a small sample of some I have tried: Libzmq should compile with one other change to Calypso. The change will need to allow multiple C header files to be modulemap'ed. The separate parts of this lib compile on their own so once we can use multiple PCH files, this should work. Fastflow actually DOES compile for all the C++ header files I have tried (YAY!!), but I just can't instantiate a worker thread (really the most basic need for this lib) because of one error I will discuss with Elie. Hopefully it will be pretty easy to fix, as the other minor parts of this lib that I have tried are working at this point. Irrlicht has some portions that compile and can be called like CWriteFile, CLogger, CImage and some os.h functionality. I ran into a couple errors so I stopped testing after that, but it is coming along. Now the best news...it looks like the LEMON C++ Library works!!! WooHoo!! (Library for Efficient Modeling and Optimization in Networks - http://lemon.cs.elte.hu/trac/lemon). I haven't tested everything, but I have imported all the headers and compiled them without errors (I think I got them all). I have also instantiated things like: dim2.Point, Tolerance, DHeaps, Graphs, Digraphs and Arg_Parsers. These all instantiate fine, and I have used a few function calls with the instances, so things are looking exceptionally good for LEMON. We can also cast between Digraphs and Graphs (the C++ classes) in D, so that is looking good :) I will try to do some more complete testing and get at least one decent example working to show off this library. I will also write up a tutorial on how to get Calypso up and running with this lib (Linux only at this point as I haven't even tried the Win build from Elie yet...and I don't believe OSX Calypso will work yet). Thanks, Kelly  Apr 23 2015 "Kagamin" <spam here.lot> writes: On Thursday, 23 April 2015 at 08:04:46 UTC, Kelly wrote: I haven't tried Qt yet because it needs to be hand-compiled with a user supplied namespace Aren't there precompiled versions?  Apr 29 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: On Wednesday, 29 April 2015 at 14:45:42 UTC, Kagamin wrote: On Thursday, 23 April 2015 at 08:04:46 UTC, Kelly wrote: I haven't tried Qt yet because it needs to be hand-compiled with a user supplied namespace Aren't there precompiled versions? Kagamin, Yes, the precompiled version was the problem. They didn't use the 'QT_NAMESPACE' option when compiling the precompiled versions of Qt, so there was no namespace to import with Calypso. 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). I think it might be possible to use parts of Qt now, but Elie is looking into that so I'll let him reveal how much works. Thanks, Kelly  Apr 29 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: A small update may be appropriate. We have run into a couple snags this past week when Elie improved the modulemap'ing for C files. Calypso now autodetects modulemap files for libc and POSIX standard headers in the /usr/include directory and /usr/include/x86_64-linux-gnu/sys. This change took a few days and many libraries broke in the meantime, but now things are back to approximately where they were last week (although one improvement is that <iterator> now compiles). There was also a backport from D2.068 to allow MSVC library usage which should move things along on Win platforms. Upon further testing of the LEMON library, I discovered that many things worked, but there is still one or two errors that make it not quite work for everything, so rewriting a nice example in D didn't quite work out. Efforts continue and hopefully we can get at least one library completely working soon, so that a proper example of Calypso's use can be written. I think things are quite close now because I was able to use every class, struct, function, etc. (that I tried randomly) in scintilla with just a couple hand written fixes to two scintilla header files. I think scintilla, LEMON and libzmq are the closest to working at this point. Thanks for your patience, Kelly  Apr 29 2015 "Elie Morisse" <syniurge gmail.com> writes: 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).  Apr 29 2015 "Kelly" <wilsonk cpsc.ucalgary.ca> writes: Well the first fully working example of a large library is finally working with Calypso. Elie has managed to get a Qt5 demo program to compile and run!! The demo is a D version of the Qt5 Widgets demo. This is a simple window with a pseudo address book app. The demo uses a D class inheriting from QWidget, calls 'super(parent)' from D code and uses the QStrings, QLabel, QLineEdit, QLayout, QGridLayout classes, among other things. You can see the code here: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d The demo is confirmed to work with Qt5.4 and Qt5.2.1. While this might not seem like a really big deal, please keep in mind that while compiling this demo, Calypso effectively parses and produces 692 object files, including large swathes of the C++ STL and most of the Qt library! The latest push last night also cut down on compile times quite a lot. Doing the initial compile of the example takes about 28 seconds on my mid-level Intel i5 machine, versus around 2 seconds for just the C++ version. After generating a cache file with last nights commits you can recompile the project in just 7.5 seconds...which I think is quite good for just getting things up and running :) Thanks, Kelly  May 12 2015 "Abdulhaq" <alynch4047 gmail.com> writes: On Tuesday, 12 May 2015 at 21:44:04 UTC, Kelly wrote: Well the first fully working example of a large library is finally working with Calypso. Elie has managed to get a Qt5 demo program to compile and run!! The demo is a D version of the Qt5 Widgets demo. This is a simple window with a pseudo address book app. The demo uses a D class inheriting from QWidget, calls 'super(parent)' from D code and uses the QStrings, QLabel, QLineEdit, QLayout, QGridLayout classes, among other things. You can see the code here: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d The demo is confirmed to work with Qt5.4 and Qt5.2.1. This really is a huge leap, congratulations!  May 13 2015 "John Colvin" <john.loughran.colvin gmail.com> writes: On Tuesday, 12 May 2015 at 21:44:04 UTC, Kelly wrote: Well the first fully working example of a large library is finally working with Calypso. Elie has managed to get a Qt5 demo program to compile and run!! The demo is a D version of the Qt5 Widgets demo. This is a simple window with a pseudo address book app. The demo uses a D class inheriting from QWidget, calls 'super(parent)' from D code and uses the QStrings, QLabel, QLineEdit, QLayout, QGridLayout classes, among other things. You can see the code here: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d The demo is confirmed to work with Qt5.4 and Qt5.2.1. While this might not seem like a really big deal, please keep in mind that while compiling this demo, Calypso effectively parses and produces 692 object files, including large swathes of the C++ STL and most of the Qt library! The latest push last night also cut down on compile times quite a lot. Doing the initial compile of the example takes about 28 seconds on my mid-level Intel i5 machine, versus around 2 seconds for just the C++ version. After generating a cache file with last nights commits you can recompile the project in just 7.5 seconds...which I think is quite good for just getting things up and running :) Thanks, Kelly 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.  May 13 2015 "Kagamin" <spam here.lot> writes: On Wednesday, 13 May 2015 at 15:54:47 UTC, John Colvin wrote: 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. As I understand, the major remaining issue is value type classes like QString and memory management done with it :(  May 14 2015 "Elie Morisse" <syniurge gmail.com> writes: 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 QFlags<AlignmentFlag> (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).  May 14 2015 "Laeeth Isharc" <laeeth nospamlaeeth.com> writes: 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 ? 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. Which commit of Calypso should I use, and which versions of clang and llvm? I am using arch linux. Laeeth.  May 14 2015 "Elie Morisse" <syniurge gmail.com> writes: 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

May 14 2015
"Suliman" <evermind live.ru> writes:
Where set where Calypso should look header files?

May 17 2015
"Suliman" <evermind live.ru> writes:
Could you show how translate this example to get it's compile
with Calypso?
http://www.gdal.org/warptut.html

I do not have knowlages of C/C++ and can't understand how to
convert next strings like:
GDALWarpOptions *psWarpOptions = GDALCreateWarpOptions();

psWarpOptions->hSrcDS = hSrcDS;
psWarpOptions->hDstDS = hDstDS;

psWarpOptions->panSrcBands =  (int *) CPLMalloc(sizeof(int) *
psWarpOptions->nBandCount );

....

May 17 2015
"Kelly" <wilsonk cpsc.ucalgary.ca> writes:
On Sunday, 17 May 2015 at 13:37:45 UTC, Suliman wrote:
Where set where Calypso should look header files?

Suliman,

You can just use '-cpp-args -I/path/to/header/file' to pass along
the include directory for C++ files.

So for example:

ldc2 -L-lstdc++ -cpp-args -I/usr/local/qt5/QtCore test.d
-L-lQt5Core

May 18 2015
"Elie Morisse" <syniurge gmail.com> writes:
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.

May 19 2015
"Kagamin" <spam here.lot> writes:
On Thursday, 14 May 2015 at 15:19:59 UTC, Elie Morisse wrote:
- Many simple non-POD C++ classes are being mapped to D classes
instead of structs, for example QFlags<AlignmentFlag>
(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.

BTW how does it rely on having everything on the D side? Maybe
it's enough to have just instance size and method symbols? 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.

May 18 2015
"Suliman" <evermind live.ru> writes:
I can't understand how to use Calypso. I did:

modmap (C++) "<gdalwarper>";

import std.stdio;

void main()
{
writeln("hello");
}

then run build command:
ldc2 -L-lstdc++ -cpp-args -ID:\Project\2015\gdal1112\alg app.d

assume gdalwarper.h is located at alg folder

and I am getting error:

Error: cannot find source code for runtime library file 'object.d'
ldc2 might not be correctly installed.
Installation instructions can be found at
http://wiki.dlang.org/LDC.
import path[0] = C:/Program Files (x86)/ldc/include/d/ldc
import path[1] = C:/Program Files (x86)/ldc/include/d

Do I need to set -L-lstdc++ option? I do not have C++ experience
:(

May 19 2015
"Elie Morisse" <syniurge gmail.com> writes:
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.

May 19 2015
"Kagamin" <spam here.lot> writes:
On Wednesday, 20 May 2015 at 00:20:46 UTC, Elie Morisse wrote:
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.

I mean a workaround for current D frontend ability to work with
value types: you can represent it as a struct with members of
from C++ side and when they are used on the D side you call into
C++ side to figure out what code to generate: D side needs not to
know they are inherited.
If you plan to make all C++ types proper value types, that's the
right way to go, I believe.

May 20 2015
"Suliman" <evermind live.ru> writes:
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

May 19 2015
"Suliman" <evermind live.ru> writes:
modmap (C++) "<gdalwarper>";

import std.stdio;

void main()
{
GDALDatasetH  hSrcDS, hDstDS;
GDALAllRegister();
writeln("hello");
}

error:
app.d(7): Error: undefined identifier GDALDatasetH
app.d(7): Error: undefined identifier GDALDatasetH
app.d(8): Error: undefined identifier GDALAllRegister

May 19 2015
"CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Tuesday, 19 May 2015 at 08:09:33 UTC, Suliman wrote:
modmap (C++) "<gdalwarper>";

import std.stdio;

void main()
{
GDALDatasetH  hSrcDS, hDstDS;
GDALAllRegister();
writeln("hello");
}

error:
app.d(7): Error: undefined identifier GDALDatasetH
app.d(7): Error: undefined identifier GDALDatasetH
app.d(8): Error: undefined identifier GDALAllRegister

Perhaps you also need to include the GDAL headers, as I suspect
gdalwarper doesn't define GDALDatasetH.

May 19 2015
"Kelly" <wilsonk cpsc.ucalgary.ca> writes:
On Tuesday, 19 May 2015 at 16:33:00 UTC, CraigDillabaugh wrote:
On Tuesday, 19 May 2015 at 08:09:33 UTC, Suliman wrote:
modmap (C++) "<gdalwarper>";

import std.stdio;

void main()
{
GDALDatasetH  hSrcDS, hDstDS;
GDALAllRegister();
writeln("hello");
}

error:
app.d(7): Error: undefined identifier GDALDatasetH
app.d(7): Error: undefined identifier GDALDatasetH
app.d(8): Error: undefined identifier GDALAllRegister

Perhaps you also need to include the GDAL headers, as I suspect
gdalwarper doesn't define GDALDatasetH.

Hi Craig,

The method here is to actually 'import (C++) _;' since that '_'
will make Calypso import all the global
functions/variables/typedefs in gdalwarper.

This works for namespaces also, so if you have a namespace in a
different example called MySpace, then calling 'import (C++)
MySpace._;' will import all the functions/variables/typedefs in
the namespace and make them accessible in your D file.

If you just have a single class in the MySpace namespace called
'myclass', and you would like to use it in your D program, then
use 'import (C++) MySpace.myclass;' to import it. Then
instantiate the class in D and use it from there.

Thanks,
Kelly

May 19 2015
"CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Tuesday, 19 May 2015 at 17:31:07 UTC, Kelly wrote:
On Tuesday, 19 May 2015 at 16:33:00 UTC, CraigDillabaugh wrote:
On Tuesday, 19 May 2015 at 08:09:33 UTC, Suliman wrote:
modmap (C++) "<gdalwarper>";

import std.stdio;

void main()
{
GDALDatasetH  hSrcDS, hDstDS;
GDALAllRegister();
writeln("hello");
}

error:
app.d(7): Error: undefined identifier GDALDatasetH
app.d(7): Error: undefined identifier GDALDatasetH
app.d(8): Error: undefined identifier GDALAllRegister

Perhaps you also need to include the GDAL headers, as I
suspect gdalwarper doesn't define GDALDatasetH.

Hi Craig,

The method here is to actually 'import (C++) _;' since that '_'
will make Calypso import all the global
functions/variables/typedefs in gdalwarper.

This works for namespaces also, so if you have a namespace in a
different example called MySpace, then calling 'import (C++)
MySpace._;' will import all the functions/variables/typedefs in
the namespace and make them accessible in your D file.

If you just have a single class in the MySpace namespace called
'myclass', and you would like to use it in your D program, then
use 'import (C++) MySpace.myclass;' to import it. Then
instantiate the class in D and use it from there.

Thanks,
Kelly

Kelly,

Just to clarify then.  If gdalwarper.h includes gdal.h and
GDALDatasetH is declared in gdal.h, then gdal.h gets imported too?

Craig

May 19 2015
"Suliman" <evermind live.ru> writes:
import (C++) GDALWarpOperation;
import (C++) GDALAccess;
import (C++) GDALWarpOptions;

How do you understand which files should be imported?

GDALWarpOptions* psWarpOptions = GDALCreateWarpOptions();

GDALWarpOptions* is type?
would:
auto psWarpOptions = GDALCreateWarpOptions();
work?

Windows

I hope to be able to test it in nearest time. As I wrote before I
have not enough knowlages to build it's by myself, so I will wait
bin builds.

If gdalwarper.h includes gdal.h and GDALDatasetH is declared
in gdal.h, then gdal.h gets imported too?

+1 for question!

May 19 2015
"Kelly" <wilsonk cpsc.ucalgary.ca> writes:
On Tuesday, 19 May 2015 at 19:57:45 UTC, Suliman wrote:
import (C++) GDALWarpOperation;
import (C++) GDALAccess;
import (C++) GDALWarpOptions;

How do you understand which files should be imported?

These aren't files being imported, they are
classes/structs/templates being imported for use. Files are
'modmap'ed not imported in Calypso.

It can be tricky to know which classes/structs/templates need to
be imported if you aren't writing a program from scratch AND know
the library fairly well. What you can do is run Calypso and if it
complains that there is an 'undefined identifier', then check to
see if that identifier is a class/struct/template and try to
import it to see if the problem is fixed. Not an ideal
programming philosophy, of course, but it can help at the
beginning to let Calypso do some work for you.

There are also clues in the source code...if you have to 'new'
anything then it will need probably to be imported.

GDALWarpOptions* psWarpOptions = GDALCreateWarpOptions();

GDALWarpOptions* is type?
would:
auto psWarpOptions = GDALCreateWarpOptions();
work?

This actually ties in with the question above...and yes, 'auto'
will work. 'Auto' is definitely your friend with Calypso, as
sometimes it isn't clear what the C++ type would translate into.
Now the big thing with 'auto', in this case, is that if you use
'auto' then you don't even need the 'import (C++)
GDALWarpOptions'!!!! Calypso will figure it out and do it for you.

This is a bit of a double edge sword though, because sometimes
you will really want/need to know the type you are dealing with
and what it translates into. Hopefully this doesn't happen too
often.

Windows

I hope to be able to test it in nearest time. As I wrote before
I have not enough knowlages to build it's by myself, so I will
wait bin builds.

If gdalwarper.h includes gdal.h and GDALDatasetH is declared
in gdal.h, then gdal.h gets imported too?

+1 for question!

Since everything in the headers on the C++ side is sort of mashed
together into the PCH (pre-compiled header) file, and you import
every global variable/typedef/function/namespace using the
special "_", then you can get access to all of these globals via
the one modmap of gdalwarper.h.

Some more well-behaved libraries that have multiple namespaces
can be easier to deal with because you can be quite specific with
what you want to import, instead of just importing 'EVERYTHING'
and then only using a small portion of it.

This is an "As far as I understand it!!!" type of answer designed
to be a little less technical. Please see Elie's answers to these
questions for a more technical and in depth explanation (and the
CORRECT explanation, as I may be somewhat off in my
interpretation here :) !! )

Thanks,
Kelly

May 19 2015
"Elie Morisse" <syniurge gmail.com> writes:
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.

May 19 2015
"Elie Morisse" <syniurge gmail.com> writes:
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.

May 19 2015
"Kelly" <wilsonk cpsc.ucalgary.ca> writes:
On Tuesday, 19 May 2015 at 08:09:33 UTC, Suliman wrote:
modmap (C++) "<gdalwarper>";

import std.stdio;

void main()
{
GDALDatasetH  hSrcDS, hDstDS;
GDALAllRegister();
writeln("hello");
}

error:
app.d(7): Error: undefined identifier GDALDatasetH
app.d(7): Error: undefined identifier GDALDatasetH
app.d(8): Error: undefined identifier GDALAllRegister

Hello Suliman,

I have translated the GDAL example (
http://www.gdal.org/warptut.html ) and got it to run...woohoo!! I
needed to apply the fix from Elie last night (and the pull
request from me that hasn't been accepted yet), so this won't
work for you yet, unfortunately...soon hopefully.

For comparison I have posted the translation here (
http://pastebin.com/VwrVeBJ3 ), but it may be a day or two yet
before Calypso can compile it out-of-the-box, even if my pull
requrest is accepted today. There is still one outstanding error
that I couldn't fix. I had to cheat and modify a system file (not
a good thing to ask others to do, obviously)!!

As you can see the differences between the two examples are
pretty minimal. Things like using '.' instead of '->'. Having to
'new' the GDALWarpOperation, and another slightly subtle change
-- we need to use an ampersand for the function pointer
assignment of GDALTermProgress/GDALAGenImgProjTransform.

Also notice that we needed to explicitly modmap cpl_conv.h to get
which structs/classes to 'import'.

I have not tested this on Windows! I haven't even built Calypso
on Windows yet...so I may not be able to help much with Windows
errors. Just so you know.

Thanks,
Kelly

May 19 2015
"Kelly" <wilsonk cpsc.ucalgary.ca> writes:
On Tuesday, 19 May 2015 at 17:15:49 UTC, Kelly wrote:
Hello Suliman,

I have translated the GDAL example (
http://www.gdal.org/warptut.html ) and got it to run...woohoo!!
I needed to apply the fix from Elie last night (and the pull
request from me that hasn't been accepted yet), so this won't
work for you yet, unfortunately...soon hopefully.

For comparison I have posted the translation here (
http://pastebin.com/VwrVeBJ3 ), but it may be a day or two yet
before Calypso can compile it out-of-the-box, even if my pull
requrest is accepted today. There is still one outstanding
error that I couldn't fix. I had to cheat and modify a system
file (not a good thing to ask others to do, obviously)!!

Ok, this example for GDAL should work out-of-the-box with Calypso
now (new git HEAD from last night).

This took a while to get running because of a major rewrite that
Elie was working on the last couple weeks. Things work quite a
bit better now, with the new changes, so hopefully we can get
some more examples working soon. Elie may chime in with more
specifics on the need for the rewrite.

I still haven't built this GDAL example on Windows, but if you
can let me know if you try this Suliman, that would be great. Let
me know if something doesn't work for you and we'll try to help
out.

Thanks,
Kelly

May 30 2015
"suliman" <Evermind live.ru> writes:
On Sunday, 31 May 2015 at 01:16:14 UTC, Kelly wrote:

Ok, this example for GDAL should work out-of-the-box with
Calypso now (new git HEAD from last night).

This took a while to get running because of a major rewrite
that Elie was working on the last couple weeks. Things work
quite a bit better now, with the new changes, so hopefully we
can get some more examples working soon. Elie may chime in with
more specifics on the need for the rewrite.

I still haven't built this GDAL example on Windows, but if you
can let me know if you try this Suliman, that would be great.
Let me know if something doesn't work for you and we'll try to
help out.

I would wait next new binary build, becouse building process
still hard for me...

May 31 2015
Elvis Zhou <elvis.x.zhou gmail.com> writes:
Any update ?
Hope things are going well!

Jul 19 2016
"Elie Morisse" <syniurge gmail.com> writes:
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.

May 19 2015
Kagamin <spam here.lot> writes:
Aren't objects rarely passed by value? What's more interesting is
how return by value is supported as it happens often:
1. return by value from D callee
2. receive an object returned by value and assign to a new
variable
3. receive an object returned by value an assign it to an
existing variable
Is ABI for these implemented?

Jul 19 2016
Elvis Zhou <elvis.x.zhou gmail.com> writes:
Seems this is abandoned? And why?

May 22 2017
"Kagamin" <spam here.lot> writes:
On Monday, 9 February 2015 at 04:33:04 UTC, Kelly wrote:
Ugh, this forum needs a preview button!!

Kelly

http://pastebin.com/

Feb 09 2015
"Elie Morisse" <syniurge gmail.com> writes:
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

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"

Feb 09 2015
"Kelly" <wilsonk cpsc.ucalgary.ca> writes:
On Monday, 9 February 2015 at 22:24:49 UTC, Elie Morisse wrote:
Hi Kelly,

Good to see bitset instantiating and basically working too! Can

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
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"

Hello Elie,

Yes, you can use the code above for bitsets (modify as you see
fit, it is public domain as far as I am concerned), thanks for

I have set up test files for most other STL headers...some seem
quite close to working. Hopefully soon :)

Thanks,
Kelly

Feb 09 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/8/15 2:45 PM, Elie Morisse wrote:
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

You may want to put this on reddit too (unless you're the one who did):

Andrei

Feb 09 2015
"Suliman" <evermind live.ru> writes:
 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?

Jan 21 2015
"Elie Morisse" <syniurge gmail.com> writes:
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

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.

ldc -L="yourDLL.lib" (...)

Jan 22 2015
Walter Bright <newshound2 digitalmars.com> writes:
On 12/22/2014 3:14 PM, Elie Morisse wrote:
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

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.

Jan 21 2015
Jacob Carlborg <doob me.com> writes:
On 2014-12-23 00:14, Elie Morisse wrote:
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

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

--
/Jacob Carlborg

Jan 23 2015
"Elie Morisse" <syniurge gmail.com> writes:
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 :-)

Jan 23 2015
Jacob Carlborg <doob me.com> writes:
On 2015-01-23 18:56, Elie Morisse wrote:

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

For the time being I think I need to focus on getting the Objective-C
support implemented in DMD. But after that, we'll see.

--
/Jacob Carlborg
`
Jan 23 2015