www.digitalmars.com         C & C++   DMDScript  

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

reply "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 
already:

  • Global variables
  • Functions
  • Structs
  • Unions (symbol only)
  • Enums
  • Typedefs
  • C++ class creation with the correct calls to ctors 
(destruction is disabled for now)
  • Virtual function calls
  • Static casts between C++ base and derived classes (incl. 
multiple inheritance offsets)
  • Mapping template implicit and explicit specializations already 
in the PCH to DMD ones, no new specialization on the D side yet
  • D classes inheriting from C++ ones, including the correct 
vtable generation for the C++ part of the class

So what is this sorcery? Let's remind ourselves that this isn't 
supposed to be feasible:


Being 100% compatible with C++ means more or less adding a fully 
functional C++ compiler front end to D. Anecdotal evidence 
suggests that writing such is a minimum of a 10 man-year 
project, essentially making a D compiler with such capability 
unimplementable.


http://dlang.org/cpp_interface.html

Well.. it is :D
Calypso introduces the modmap keyword, as in:

   modmap (C++) "cppheader.h";

to generate with the help of Clang libraries a "virtual" tree of 
C++ modules. Then after making Clang generate a PCH for all the 
headers, the PCH is loaded and classes, structs, enums are placed 
inside modules named after them, while global variables and 
functions are in a special module named "_". For example:

   import (C++) Namespace.SomeClass;  // imports 
Namespace::SomeClass
   import (C++) Namespace._;  // imports all the global variables 
and functions in Namespace
   import (C++) _ : myCfunc, myGlobalVar;  // importing the global 
namespace = bad idea, but selective imports work

Being a prototype, I didn't really pay attention to code 
conventions or elegance and instead focused on getting things 
working.
And being tied to LDC and Clang (I have no idea how feasible a 
GCC version would be), it's going to stay like this for some time 
until I get feedback from the contributors on how this all should 
really be implemented,. For example Calypso introduces "language 
plugins", to minimize the amount of code specific to C++ and to 
make support of foreign languages cleaner and less intrusive, 
although it of course needs numerous hooks here and there in DMD 
and LDC.

Calypso is still WIP, but it's in pretty good shape and already 
works in a lot of test cases (see tests/calypso/), and is almost 
ready to use for C++ libraries at least. Since C libraries are in 
the global namespace, it's not a convenient replacement yet for 
bindings until I implement the Clang module map format. More info 
this blog post detailing some of the history behind Calypso:

http://syniurge.blogspot.com/2013/08/calypso-to-mars-first-contact.html

So.. Merry Christmas dear D community? :)


My take on the current talks of "feature freezing" D: the 
strength of D is its sophistication. The core reason why D fails 
to attract more users isn't the frequent compiler bugs or 
regressions, but the huge amount of time needed to get something 
done because neither equivalent nor bindings exist for most big 
and widespread C++ libraries like Qt. All these talks about 
making D a more minimalist language won't solve much and will 
only result in holding back D, which has the potential to become 
a superset of all the good in other system languages, as well as 
bringing its own powerful unique features such as metaprogramming 
done right.
By removing the main reason why D wasn't a practical choice, this 
will hopefully unlock the situation and make D gain momentum as 
well as attract more contributors to the compilers to fix bugs 
and regressions before releases.
Dec 22 2014
next sibling parent reply 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:

    modmap (C++) "cppheader.h";


That really should be a pragma.
pragma(modmap, C++, "cppheader.h");
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
parent "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
prev sibling next sibling parent reply "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
parent reply "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 
platforms you are concerned about?


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


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
parent reply "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 
 platforms you are concerned about?


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
next sibling parent "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
prev sibling next sibling parent reply "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):

http://forum.dlang.org/thread/weodkqwxrqetvolhbghb forum.dlang.org
Dec 23 2014
parent 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):

 http://forum.dlang.org/thread/weodkqwxrqetvolhbghb forum.dlang.org


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
prev sibling parent "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 
quite some time already.


 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
prev sibling next sibling parent 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
prev sibling next sibling parent reply "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
next sibling parent "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
prev sibling next sibling parent reply "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
parent "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
prev sibling parent reply "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
parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent reply "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
parent reply "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
next sibling parent reply 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
parent reply "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
next sibling parent "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
prev sibling parent reply "Kelly" <wilsonk cpsc.ucalgary.ca> writes:
Hello Elie,

This project looks great, thanks for the hard work. I downloaded 
Calypso and ldc2 about 6 hours ago to try your project out.

I can get Calypso to compile with a couple small changes to 
assistbuilder.cpp (just adding a namespace qualifier for two 
class instantiations of CodeGen). That is with clang-3.5 from 
todays svn. Maybe a recent clang commit has changed things?

Once I had a working Calypso ldc2 build, I unfortunately couldn't 
get the showcase example to build. I just use the build line from 
your git page to try to build, but I get an 'undefined identifier 
size_t' error. The pch file is produced properly but then this 
error comes up...it seems like while compiling druntime from the 
'-v' output?? Maybe something changed in the druntime submodule 
in the last few days...but I didn't really look into it yet.

I hacked a couple things to just get around this error and then 
things fail because libshowcase.a isn't available. I assume that 
is a remnant from an earlier compilation technique, because it 
appears everything is self contained in the .o files being 
produced and then linked on the command line...so I just thought 
I would let you know this part doesn't work.

If you could give me a hint on the 'undefined identifier size_t' 
error, I can look into it a bit further here...I am just getting 
tired and probably not seeing what is going on there. If you are 
on #ldc I will be on there later today. Not sure what your 
username is in #ldc. At least one other person has been by asking 
if you were there also :)


Thanks,
Kelly (wilsonk-laptop)
Jan 23 2015
parent reply "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 
 downloaded Calypso and ldc2 about 6 hours ago to try your 
 project out.

 I can get Calypso to compile with a couple small changes to 
 assistbuilder.cpp (just adding a namespace qualifier for two 
 class instantiations of CodeGen). That is with clang-3.5 from 
 todays svn. Maybe a recent clang commit has changed things?

 Once I had a working Calypso ldc2 build, I unfortunately 
 couldn't get the showcase example to build. I just use the 
 build line from your git page to try to build, but I get an 
 'undefined identifier size_t' error. The pch file is produced 
 properly but then this error comes up...it seems like while 
 compiling druntime from the '-v' output?? Maybe something 
 changed in the druntime submodule in the last few days...but I 
 didn't really look into it yet.

 I hacked a couple things to just get around this error and then 
 things fail because libshowcase.a isn't available. I assume 
 that is a remnant from an earlier compilation technique, 
 because it appears everything is self contained in the .o files 
 being produced and then linked on the command line...so I just 
 thought I would let you know this part doesn't work.

 If you could give me a hint on the 'undefined identifier 
 size_t' error, I can look into it a bit further here...I am 
 just getting tired and probably not seeing what is going on 
 there. If you are on #ldc I will be on there later today. Not 
 sure what your username is in #ldc. At least one other person 
 has been by asking if you were there also :)


 Thanks,
 Kelly (wilsonk-laptop)


Thanks for the feedback Kelly, you're probably the first person 
to give it a serious try, sorry for the bumpy ride :)

Since I was focused on getting Ogre working and neither rebuilt 
druntime/phobos nor tested the showcase example against the 
latest commits they might have broken something.
Also the README forgets to say how libshowcase.a should be built:

   clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o
   ar rcs libshowcase.a showcase.cpp.o

   ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ showcase.d

Adding this now.

I'm going to fix the rest this afternoon (finally some free 
time), and also figure out why assistbuilder.cpp failed to 
compile against the latest Clang 3.5.

Also going to setup a testing script to ensure not everything 
gets broken again by a commit.
Jan 23 2015
next sibling parent "Kelly" <wilsonk cpsc.ucalgary.ca> writes:
Hello Elie,

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


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

 Adding this now.

 I'm going to fix the rest this afternoon (finally some free 
 time), and also figure out why assistbuilder.cpp failed to 
 compile against the latest Clang 3.5.

 Also going to setup a testing script to ensure not everything 
 gets broken again by a commit.
Jan 23 2015
prev sibling parent reply "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
next sibling parent "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
prev sibling parent reply "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
parent reply "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 
downloading and building the various different pieces.  So many 
moving parts that it is easy for something to break.



Laeeth.
Jan 29 2015
parent reply "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
parent reply "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
parent reply "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
parent reply "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
next sibling parent "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
prev sibling next sibling parent reply "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
next sibling parent reply "Kelly" <wilsonk cpsc.ucalgary.ca> writes:
Ugh, this forum needs a preview button!!

Sorry about the poor formatting,
Kelly
Feb 08 2015
next sibling parent reply "Suliman" <evermind live.ru> writes:
If somebody have working Windows build, could you please share it?
Feb 08 2015
parent reply "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
next sibling parent "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
prev sibling next sibling parent "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
prev sibling parent reply "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
parent reply "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
parent reply "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
next sibling parent "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
prev sibling parent reply "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
parent reply "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
parent reply "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
next sibling parent reply "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
parent "Kagamin" <spam here.lot> writes:
http://forum.dlang.org/post/mbqt88$a6n$1 digitalmars.com looks 
like C++ class support is shifting to value types.
Feb 16 2015
prev sibling parent reply "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
parent reply "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
next sibling parent reply "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
next sibling parent 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
prev sibling parent "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
prev sibling parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling parent reply "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
next sibling parent reply "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
next sibling parent "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
prev sibling parent reply "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
parent "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
prev sibling parent reply "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
next sibling parent reply "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
next sibling parent reply "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
parent reply "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
parent "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
prev sibling next sibling parent "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
prev sibling parent reply "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
parent reply "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
next sibling parent "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
prev sibling parent reply "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
next sibling parent "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
prev sibling parent reply "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
next sibling parent reply "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
parent reply "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 
or incomplete please tell me.
May 14 2015
parent reply "Suliman" <evermind live.ru> writes:
Where set where Calypso should look header files?
May 17 2015
next sibling parent "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
prev sibling next sibling parent "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
prev sibling parent "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
prev sibling parent reply "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
next sibling parent "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.
        Please check your ldc2.conf configuration file.
        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
prev sibling parent reply "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
parent "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
prev sibling parent reply "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
next sibling parent reply "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
next sibling parent reply "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
parent reply "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
parent reply "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
next sibling parent reply "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
parent "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
prev sibling parent reply "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
parent "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
prev sibling parent reply "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 
access to CPLMalloc. In addition, we have to be explicit about 
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
parent reply "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
parent reply "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
parent Elvis Zhou <elvis.x.zhou gmail.com> writes:
Any update ?
Hope things are going well!
Jul 19 2016
prev sibling parent reply "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
next sibling parent 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
prev sibling parent Elvis Zhou <elvis.x.zhou gmail.com> writes:
Seems this is abandoned? And why?
May 22 2017
prev sibling parent "Kagamin" <spam here.lot> writes:
On Monday, 9 February 2015 at 04:33:04 UTC, Kelly wrote:

 Ugh, this forum needs a preview button!!

 Sorry about the poor formatting,
 Kelly


http://pastebin.com/
Feb 09 2015
prev sibling parent reply "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 
add your code to the tests?

So yes to clear things up a bit, operators are still missing and 
so are many other features. Off the top of my head:

  - Function templates => the groundwork is here, they're already 
mapped and it
shouldn't be too difficult to get them instantiating from D
  - Operators => probably easy to add although there might be 
differences between C++ and D operators
  - Functions with class values parameters aren't even mapped yet, 
since I haven't made my mind on how to handle class values. 
Despite the "POD or not" issue it still feels more consistent to 
treat C++ classes like D classes, while adding C++ class value 
types to DMD's types like C++ reference types were with 
TypeReference (which makes C++ variables with reference types 
usable but which can't be assigned as the types of D variables)
  - C++ reference types are supported by DMD but not by LDC yet, 
they only work for function parameters and return types since 
Calypso replace them by "ref"
Feb 09 2015
parent "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 
 I add your code to the tests?

 So yes to clear things up a bit, operators are still missing 
 and so are many other features. Off the top of my head:

  - Function templates => the groundwork is here, they're 
 already mapped and it
 shouldn't be too difficult to get them instantiating from D
  - Operators => probably easy to add although there might be 
 differences between C++ and D operators
  - Functions with class values parameters aren't even mapped 
 yet, since I haven't made my mind on how to handle class 
 values. Despite the "POD or not" issue it still feels more 
 consistent to treat C++ classes like D classes, while adding 
 C++ class value types to DMD's types like C++ reference types 
 were with TypeReference (which makes C++ variables with 
 reference types usable but which can't be assigned as the types 
 of D variables)
  - C++ reference types are supported by DMD but not by LDC yet, 
 they only work for function parameters and return types since 
 Calypso replace them by "ref"



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

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

Thanks,
Kelly
Feb 09 2015
prev sibling parent 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): 
http://www.reddit.com/r/programming/comments/2vc0eg/calypso_dc_interface_using_stdvector_and/

Andrei
Feb 09 2015
prev sibling parent reply "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
parent "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 
precompiled header

   import (C++) Namespace1.Namespace2._; // If your functions are 
global functions inside Namespace1.Namespace2, _ is a special 
module (for now) that contains all the global funcs, vars and 
typedefs
   import (C++) Namespace1.Struct1; // If they are inside a struct 
named Struct1

The imports expose symbols that you can use like you'd use D 
structs and functions.

Finally you need to tell LDC to link to your library:

   ldc -L="yourDLL.lib" (...)
Jan 22 2015
prev sibling next sibling parent 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
prev sibling parent reply 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
parent reply "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
parent 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