Re: Calypso: Direct and full interfacing to C++
Seems this is abandoned? And why?
Re: Calypso: Direct and full interfacing to C++
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?
Re: Calypso: Direct and full interfacing to C++
Any update ? Hope things are going well!
Re: Calypso: Direct and full interfacing to C++
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...
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
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.
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
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
:(
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 17:44:38 UTC, CraigDillabaugh wrote: Just to clarify then. If gdalwarper.h includes gdal.h and GDALDatasetH is declared in gdal.h, then gdal.h gets imported too? Craig On Tuesday, 19 May 2015 at 19:57:45 UTC, Suliman wrote: How do you understand which files should be imported? +1 for question! modmap is only telling Clang which headers to parse. Then all those headers form a big monolithic AST that Calypso split into modules following a few rules: import (C++) namespace1.testStruct; // imports namespace1::testStruct import (C++) namespace2.testClass; // imports namespace2::testClass import (C++) test.anotherClass; // etc. each struct/class/enum template or not is placed in a module named after it import (C++) test.tempWithPartialSpecs; // imports the primary class template + all its partial and explicit specializations import (C++) test._; // « _ » is a special module that contains all the global variables, global functions and typedefs of a namespace (the ones which aren't nested inside a struct or a class, or another namespace). Why the header paths can't be used in imports is explained here: http://syniurge.blogspot.fr/2013/08/calypso-to-mars-first-contact.html#namingquestion Documentation is scarce at the moment, the examples (starting with showcase.d) try to give a quick overview of how to use Calypso but yep we really should write a tutorial of some sort, either I or Kelly will do it before DConf.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 17:44:38 UTC, CraigDillabaugh wrote: Just to clarify then. If gdalwarper.h includes gdal.h and GDALDatasetH is declared in gdal.h, then gdal.h gets imported too? Craig So to give a more straight answer, modmap is an #include directive so every header gdalwarper.h includes will be parsed too. But it doesn't import anything.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 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
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 08:02:47 UTC, Suliman wrote: Oh, I forgot to fix path at: /etc/ldc.conf Am I right understand that: C:/Program Files (x86)/ldc/lib = C:\Program Files (x86)\mingw-w64\i686-4.9.2-posix-dwarf-rt_v4-rev2\mingw32\lib ? Or I can't find more proper folder The Unix path for C:\Program Files (x86)\mingw-w64\i686-4.9.2-posix-dwarf-rt_v4-rev2\mingw32\lib is simply: /lib. ( The root the leftmost / refers to in every Unix path is C:\Program Files (x86)\mingw-w64\i686-4.9.2-posix-dwarf-rt_v4-rev2\mingw32 ) You're almost in uncharted territory, but thanks for helping with testing! I'll write clearer instructions for Windows too when I get the time. And BTW the MingW build is pretty old by now. I don't have much free time atm and I'm working on important fixes, but as soon as they're ready I'll update the MingW build.
Re: Calypso: Direct and full interfacing to C++
On Monday, 18 May 2015 at 12:27:35 UTC, Kagamin wrote: BTW how does it rely on having everything on the D side? Maybe it's enough to have just instance size and method symbols? I'm not sure what you mean. But then there's problem with this inference: what if the type is intended to be used as a reference type and you infer it to be POD, and it can also flicker between POD and non-POD depending on defines. This is true and it may not even be rare: turning C++11 on or off is doing it for some Qt classes. But there is another issue that will make me revisit their semantics anyway, it's that C++ structs and classes shouldn't be garbage collected because they weren't made with GC in mind and might have weak refs. So unless someone has a better solution C++ classes will go back to manual memory management, and the plan is while changing class and new's semantics to also make all C++ classes values.
Re: Calypso: Direct and full interfacing to C++
On Sunday, 17 May 2015 at 13:37:45 UTC, Suliman wrote: Where set where Calypso should look header files? It works the same as in C++, there are the standard header paths: /usr/include, /usr/include/c++/4.9, /usr/local/include And to add another header search path you can pass options to Clang with -cpp-args, i.e « ldc2 (...) -cpp-args -I/another/include/folder ». With the MingW version all those Unix paths refer to the MingW root directory.
Re: Calypso: Direct and full interfacing to C++
On 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
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
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.
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
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 );
Re: Calypso: Direct and full interfacing to C++
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 QFlagsAlignmentFlag (qt5demo.d uses its alias Qt::Alignment) which is a wrapper around a single int but contains an overloaded assignment operator so is considered non-POD in C++. Same story for QString. string, vector, almost all STL types are non-POD too because they have base classes. 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.
Re: Calypso: Direct and full interfacing to C++
On Sunday, 17 May 2015 at 13:37:45 UTC, Suliman wrote: Where set where Calypso should look header files? 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
Re: Calypso: Direct and full interfacing to C++
Where set where Calypso should look header files?
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 13 May 2015 at 15:54:47 UTC, John Colvin wrote: That's great! I'm looking forward to being able to easily make direct use of some of the great C++ code out there. Are there are performance pitfalls to watch out for that are unique to the way calypso interfaces between D and C++? E.g. sneaky copies, implicit callbacks to keep things synced etc. There are a few: - Many simple non-POD C++ classes are being mapped to D classes instead of structs, for example QFlagsAlignmentFlag (qt5demo.d uses its alias Qt::Alignment) which is a wrapper around a single int but contains an overloaded assignment operator so is considered non-POD in C++. Same story for QString. string, vector, almost all STL types are non-POD too because they have base classes. So this may be inconvenient when trying to avoid heap allocations.. For QFlags and QString we could do more than just checking if the class/struct is POD according to the C++ definition (i.e we could ignore overloaded operators, which are allowed in D structs), but STL types will most likely stay that way. - For the time being when calling a C++ function taking a class value argument with FunctionB(new ClassA(...)), the ClassA instance is 1/GC-allocated 2/ctor is called 3/copied to the stack-allocated memory for the call. Whereas in C++ FunctionB(ClassA(...)) the ClassA constructor is directly called over the stack-allocated memory. In D there's no way to avoid the copy yet, I think we could mimic the C++ way but that'd involve another small alteration to the language. That's about it, I can't think of anything else, what's cool is that almost all symbols Calypso exposes are the C++ symbols themselves with no wrapper layer in-between, with a few exceptions such as overloaded operators opBinary!+ etc. which dispatch the call to the C++ operator mapped to a non-templated function (because the C++ overloaded operator might be virtual, it can't be mapped directly to a template).
Re: Calypso: Direct and full interfacing to C++
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.
Re: Calypso: Direct and full interfacing to C++
On Thursday, 14 May 2015 at 20:23:47 UTC, Laeeth Isharc wrote: Elie, Congratulations on this very impressive work. Out of curiosity, how far away do you think it is from being at a beta stage that one can use to write non-critical work in ? Thanks Laeeth, It's not too far I think. When finally comes the time when I can test one or two new complex libraries without triggering new bugs it should be good enough. At the moment I'm focusing on libraries that depend on Boost and are one order of magnitude more sophisticated than Qt, once they work the way out to usable state with any library may be in sight. One open source library that might not be too tough but would have high value in the financial domain is Quantlib. (I don't think it is heavily templated, but I don't yet know the codebase well). https://github.com/lballabio/quantlib Also, I am embarrassed to confess that I still have trouble building calypso (although I can build LDC fine). Specifically some symbols not found during compilation. I can pull them out if helpful, but I have tried several times over the past months and it is different ones each time. Missing symbols might be caused by your LLVM source tree having a different version from Arch's LLVM libraries. The changes made to LDC's CMake file are very primitive and won't check if the selected LLVM include/ and libraries match the one in LLVM_SOURCE_PATH added by Calypso. If you built and installed LLVM + Clang 3.6 yourself to /usr/local and if there's a different version from Arch packages in /usr, check that cmake got the right LLVM_CONFIG path with: $ cmake -LA |grep LLVM If it didn't fix the value with $ cmake -DLLVM_CONFIG=/usr/local/bin/llvm-config ../Calypso Which commit of Calypso should I use, and which versions of clang and llvm? I am using arch linux. The versions are the ones in the README, i.e the 3.6 branch of LLVM, Clang and compiler-rt. I'll add a note about the not very smart detection of LLVM libs, and if some of the instructions in the README are still confusing or incomplete please tell me.
Re: Calypso: Direct and full interfacing to C++
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 :(
Re: Calypso: Direct and full interfacing to C++
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!
Re: Calypso: Direct and full interfacing to C++
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.
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 22 April 2015 at 14:57:43 UTC, Kagamin wrote: What about Qt? I don't remember it being heavily templated. Thanks for the hint, it's definitely true for most of the code of Qt although there are still a few areas like QtCore/qtypetraits.h or Q_STATIC_ASSERT in non-C++11 mode that are tormenting Calypso (and helped fix bugs). But overall it seems like a much shorter list of errors compared to other libs, so there may be something to show soon :) On Wednesday, 29 April 2015 at 15:33:38 UTC, Kelly wrote: This isn't a problem anymore because Calypso can import libraries without an explicit namespace now, as long as it has a modulemap (that was part of the updating effort over the last week). Actually it's not due to that directly but because there were a few Qt global functions and variables (e.g in QtCore/qnumeric.h) that some Qt classes depend upon and caused a large part of the C standard lib to be imported, which would fail because there are some variables and structs that share the same name. It works properly now that symbols from the C standard lib are split across several modules (so no more name conflicts).
Re: Calypso: Direct and full interfacing to C++
On 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
Re: Calypso: Direct and full interfacing to C++
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?
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 22 April 2015 at 14:57:43 UTC, Kagamin wrote: What about Qt? I don't remember it being heavily templated. 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
Re: Calypso: Direct and full interfacing to C++
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.
Re: Calypso: Direct and full interfacing to C++
On Thursday, 16 April 2015 at 06:43:25 UTC, Suliman wrote: Could anybody wrote very simple tutorial, that show how to use any popular C/C++ lib without binding? I mean step by step manual. Also it would be nice to get binary builds for Windows to test. Sorry for the wait. So Calypso still can't load the MSVC C++ standard lib. I thought Kelly managed to build some STL examples but actually it's not remotely possible yet. The main blocker is that template instances often depend on each other (but not in their entirety) which cause forward reference errors in DMD. However it works with MinGW-w64, but this wasn't remotely straightforward either, I had to modify Clang to make it detect correctly the MinGW paths (which are hardcoded in Clang and obsolete): - install mingw-w64, in the installer choose 4.9.2, DWARF exceptions and POSIX threads - download http://homo-nebulus.fr/dlang/Calypso_mingw-w64.7z - extract the archive over the MinGW root directory (where the bin/, etc/, etc. folders lie) - correct the paths in /etc/ldc.conf - add Z:\path\to\MingW\bin to your PATH environment variable in your System settings (e.g follow: http://geekswithblogs.net/renso/archive/2009/10/21/how-to-set-the-windows-path-in-windows-7.aspx) Then you can build the examples in tests/
Re: Calypso: Direct and full interfacing to C++
I should have given the same warning, there's a chance that Calypso may work with not too sophisticated C++ libraries but new bugs are around the corner if you try anything too big. Nevertheless Suliman, Laeeth and maybe others have been wanting to try it out in its current state, and it was useful because new errors seems to have appeared while compiling the STL examples by a MSVC build since Kelly's successful attempt two months ago (no idea whether it's because more of the MSVC runtime/standard lib gets mapped or because he used another standard lib?). So sorry for the wait but this is taking longer than expected, first I could only start building LLVM yesterday's evening because of slow download speeds, and today the MSVC build is triggering these new errors I'm investigating.
Re: Calypso: Direct and full interfacing to C++
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.
Re: Calypso: Direct and full interfacing to C++
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 ?
Re: Calypso: Direct and full interfacing to C++
On Thursday, 16 April 2015 at 06:43:25 UTC, Suliman wrote: Could anybody wrote very simple tutorial, that show how to use any popular C/C++ lib without binding? I mean step by step manual. Also it would be nice to get binary builds for Windows to test. Suliman sorry for keeping you waiting :) I'll be spending the evening installing MSVC and Qt Creator, and building Calypso for Windows users to play with and to help with testing. Expect binaries tomorrow. The usage should be clear just by looking at and building the examples in tests/calypso.
Re: Calypso: Direct and full interfacing to C++
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.
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
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.
Re: Calypso: Direct and full interfacing to C++
Sorry for the lack of updates, progress was a bit boring for the past 2 months and consisted mostly in crawling my way up a bottomless pit of errors generated by « import (C++) Ogre.Light; ». And then this happens: https://paste.kde.org/pse8pqzch :D The compilation speed could be improved, more bugs should get triggered by actual usage of Ogre, but close to everything gets mapped, semantic'd and codegen'd and this is the milestone I've been working towards for months. Last week also introduced was the Clang module map file support, which helps breaking namespaces into smaller pieces and thus makes probably most C libraries usable right now without having to maintain bindings, only a module map file which may also be generated by clang-modularize.
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
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.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 24 February 2015 at 08:44:25 UTC, Kagamin wrote: On Tuesday, 24 February 2015 at 08:39:39 UTC, Kelly wrote: due to class value support being incomplete What about using that trick: recognize C++ classes and represent them internally as structs with altered mangling - at least it frees you from messing with D classes. What about inheritance, polymorphism and virtual methods that aren't supported by D structs? I'm worried that it's going be a lot harder to reimplement everything in structs. Atm to quickly make functions that take or return class values work what's missing is implicit casts between the class value types I added recently (the hacky TypeValueof) and the normal class types, and support in codegen. So it's not too far away I think.
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 18 February 2015 at 08:52:33 UTC, Kelly wrote: Hello Elie, I just pushed a small pull request for fromTypeTemplateSpecialization. I forgot to mention in the request that the changes allow bitset.d to be compiled and run again. Thanks for looking into this, I'll check your PR. With those changes all the examples compile and run again. There are still two errors when compiling vector.d. Clang errors when making the pch file. LDC2 still runs and produces a working binary anyways. Not sure what you are working on, but I can look at those errors if you like. Are these errors occurring when Clang generates the PCH or later in the semantic pass? There might be errors during the instantiation of member functions of class templates because Calypso tries to instantiate everything (whereas Clang instantiates them lazily), but it's no big deal, later they'll be made silent. BTW I just pushed support for function template instantiation. So lately thanks to a bit of free time there has been quite a lot of new features implemented: overloaded operators, function templates, and groundwork for class value types (they were added to the AST as a new semi-hackish kind of type, they make mapping any C++ type possible but they can't be used directly from D code yet). Operators should make std::map usable, so I'm going to resume testing further STL types.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 17 February 2015 at 02:16:58 UTC, Kelly wrote: P.S. I HATE THIS FORUM EDITORplease 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.
Re: Calypso: Direct and full interfacing to C++
Hi Kelly, It's done, I've merged latest LDC upstream + your build fixes into Calypso. About Microsoft vtables they work much more differently from the Itanium ones than I thought, it's going to a lot trickier than just a few lines of code so I won't be able to make D classes inheriting from C++ ones work on MSVC until I setup a dev environment on Windows. It's just those « D-C++ classes » though, the rest has a better chance to work now.
Re: Calypso: Direct and full interfacing to C++
On 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 EDITORplease 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 :)
Re: Calypso: Direct and full interfacing to C++
On Tue, Feb 17, 2015 at 02:16:57 +, Kelly via Digitalmars-d-announce wrote: P.S. I HATE THIS FORUM EDITORplease 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
Re: Calypso: Direct and full interfacing to C++
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.
Re: Calypso: Direct and full interfacing to C++
http://forum.dlang.org/post/mbqt88$a6n$1...@digitalmars.com looks like C++ class support is shifting to value types.
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
On Sunday, 15 February 2015 at 11:48:50 UTC, Kelly wrote: Alirighty, Calypso builds and runs on both Linux and Win64 with that last change from today in my fork. Now when I say 'runs' on Linux, I mean it runs properly and fully (compiling and running all examples from Feb 8th)...but when I say 'runs' on Win64, I should say 'runs as far as it can' because there is an internal LLVM assert with getVTableContext Microsoft VTableContext not yet supported UGH! :( It's from Calypso actually, the assert is in gen/dcxxclasses.cpp and is only triggered by D classes inheriting from C++ classes with a vtable. If the rest works as usual on Linux you got the most important covered. I'll check your merge as soon as I'm done fixing a linking error with the std::string example the latest additions introduced, then I'll add the Microsoft VTableContext support so we could get those first working binaries for Windows users :) However LLVM and Clang 3.6 aren't even released yet (next week), IMHO it would be wiser to stick with 3.6 and get LDC/Calypso working with 3.6 until 3.7 is more stable. Did you mean that even LDC can't be built by MSVC with LLVM 3.6 atm?
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
Anyway I'm probably fixing the last issue right now preventing std::vector from instantiating so I'm going to push the commits to master in the hour.
Re: Calypso: Direct and full interfacing to C++
On Friday, 13 February 2015 at 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
Re: Calypso: Direct and full interfacing to C++
On Friday, 13 February 2015 at 09:49:51 UTC, Kelly wrote: Hello Elie, Ok, I have merged in the newest LDC with Calypso from github today and built it with vs2013 on Win7 :) There is a small diff involved in getting things to compile. The resulting ldc2 runs and builds a simple hello world program, but it fails when trying to use calypso. I guess I've made a mistake with my patch since I am getting an assert in ASTReader with input for calypso to compile. I will look at it tomorrow and once I can get calypso to work I will push to my github fork. Hoping for better news tomorrow, Kelly Awesome news Kelly. Did you use rebase to merge? You've probably saved me a lot of work which I was planning to do this week-end after seeing your post about Win64 support. There are a dozen of new commits in store since last week-end for operator support and groundwork for class values, but mapping operators trigger new bugs which prevent std::vector from instantiating so I haven't pushed them yet to master, but do you want me to push them into a new branch so you can merge with the latest? Let me know when you make your fork available so I can check your merge and then incorporate it into master.
Re: Calypso: Direct and full interfacing to C++
On Monday, 9 February 2015 at 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
Re: Calypso: Direct and full interfacing to C++
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 Arraystruct LangPlugin * LangPlugins; +class LangPlugin; +typedef Arrayclass LangPlugin * LangPlugins; typedef unsigned structalign_t; #define STRUCTALIGN_DEFAULT ((structalign_t) ~0)
Re: Calypso: Direct and full interfacing to C++
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/
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
On Monday, 9 February 2015 at 04:27:06 UTC, Kelly wrote: Thanks, just got that tangled mess of templates that is std::string working too: Hey Elie, this is great stuff, as usual. I have written a test file for bitset here also (including a couple failures I am sure you are aware of, but others might want to see what works and what doesn't). Hi Kelly, Good to see bitset instantiating and basically working too! Can I add your code to the tests? So yes to clear things up a bit, operators are still missing and so are many other features. Off the top of my head: - Function templates = the groundwork is here, they're already mapped and it shouldn't be too difficult to get them instantiating from D - Operators = probably easy to add although there might be differences between C++ and D operators - Functions with class values parameters aren't even mapped yet, since I haven't made my mind on how to handle class values. Despite the POD or not issue it still feels more consistent to treat C++ classes like D classes, while adding C++ class value types to DMD's types like C++ reference types were with TypeReference (which makes C++ variables with reference types usable but which can't be assigned as the types of D variables) - C++ reference types are supported by DMD but not by LDC yet, they only work for function parameters and return types since Calypso replace them by ref
Re: Calypso: Direct and full interfacing to C++
On Monday, 9 February 2015 at 07:10:56 UTC, Suliman wrote: If somebody have working Windows build, could you please share it? It would be nice to know if someone even managed to build Calypso on Windows yet :) On Monday, 9 February 2015 at 20:17:33 UTC, Andrei Alexandrescu wrote: You may want to put this on reddit too (unless you're the one who did): http://www.reddit.com/r/programming/comments/2vc0eg/calypso_dc_interface_using_stdvector_and/ Andrei Nice, I'll dust my antique barely used account if questions pop up.
Re: Calypso: Direct and full interfacing to C++
Small update: std::vector is now working. https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/vector.d I went back to simpler problems than getting Ogre to work and will focus on the C++ standard lib until the common class templates work.
Re: Calypso: Direct and full interfacing to C++
On Sunday, 8 February 2015 at 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.
Re: Calypso: Direct and full interfacing to C++
On Sunday, 8 February 2015 at 20:56:31 UTC, Syro wrote: That is really cool. Thanks, just got that tangled mess of templates that is std::string working too: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/string.d
Re: Calypso: Direct and full interfacing to C++
If somebody have working Windows build, could you please share it?
Re: Calypso: Direct and full interfacing to C++
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!!
Re: Calypso: Direct and full interfacing to C++
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; iusedColors.size; i++) // size seems to
work
if (usedColors.test(i))// works
write('1');
else
write('0');
write('\n'); // prints 1010 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; ib.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 = ab;
}
Thanks,
Kelly
Re: Calypso: Direct and full interfacing to C++
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.
Re: Calypso: Direct and full interfacing to C++
Hi Laeeth, Could you post the errors and which compiler you are using? If you managed to build both LDC and Clang you should be pretty close to get Calypso working. Would there be any chance you could fork a version of clang that works with Calypso, and then link to it in the instructions? As said in the README the 3.5 branch of LLVM/Clang should work, it's stable and there hasn't been a single commit since December 8: https://github.com/llvm-mirror/clang/commits/release_35
Re: Calypso: Direct and full interfacing to C++
On Friday, 23 January 2015 at 12:29:56 UTC, Kelly wrote: Hello Elie, This project looks great, thanks for the hard work. I downloaded Calypso and ldc2 about 6 hours ago to try your project out. I can get Calypso to compile with a couple small changes to assistbuilder.cpp (just adding a namespace qualifier for two class instantiations of CodeGen). That is with clang-3.5 from todays svn. Maybe a recent clang commit has changed things? Once I had a working Calypso ldc2 build, I unfortunately couldn't get the showcase example to build. I just use the build line from your git page to try to build, but I get an 'undefined identifier size_t' error. The pch file is produced properly but then this error comes up...it seems like while compiling druntime from the '-v' output?? Maybe something changed in the druntime submodule in the last few days...but I didn't really look into it yet. I hacked a couple things to just get around this error and then things fail because libshowcase.a isn't available. I assume that is a remnant from an earlier compilation technique, because it appears everything is self contained in the .o files being produced and then linked on the command line...so I just thought I would let you know this part doesn't work. If you could give me a hint on the 'undefined identifier size_t' error, I can look into it a bit further here...I am just getting tired and probably not seeing what is going on there. If you are on #ldc I will be on there later today. Not sure what your username is in #ldc. At least one other person has been by asking if you were there also :) Thanks, Kelly (wilsonk-laptop) Thanks for the feedback Kelly, you're probably the first person to give it a serious try, sorry for the bumpy ride :) Since I was focused on getting Ogre working and neither rebuilt druntime/phobos nor tested the showcase example against the latest commits they might have broken something. Also the README forgets to say how libshowcase.a should be built: clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o ar rcs libshowcase.a showcase.cpp.o ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ showcase.d Adding this now. I'm going to fix the rest this afternoon (finally some free time), and also figure out why assistbuilder.cpp failed to compile against the latest Clang 3.5. Also going to setup a testing script to ensure not everything gets broken again by a commit.
Re: Calypso: Direct and full interfacing to C++
On Friday, 23 January 2015 at 10:02:55 UTC, Jacob Carlborg wrote: Could this work for Objective-C as well. I'm working on adding support for Objective-C to DMD [1]. [1] https://github.com/D-Programming-Language/dmd/pull/4321 It's planned to add Objective-C to Calypso, although I never used it and know little about it. Would you be interested in implementing support for its different flavors in Calypso, Jacob? You'd be welcome to the team :-)
Re: Calypso: Direct and full interfacing to C++
Hello Elie, Just a little build script until cmake can be used properly: #!/bin/bash set -x clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o ar rcs libshowcase.a showcase.cpp.o /bin/rm calypso_cache* ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ showcase.d I remove the the calypso_cache otherwise there will be an error if a previous build failed and the C++ files get modified. It looks like the 'undefined identifier size_t;' error is just from testStruct. If I comment out all refs/uses to testStruct then things compile and run fine. Good stuff. Thanks, Kelly P.S. If I find a little time, I'll try to get up to speed on the code base :) On Friday, 23 January 2015 at 17:18:22 UTC, Elie Morisse wrote: Thanks for the feedback Kelly, you're probably the first person to give it a serious try, sorry for the bumpy ride :) Since I was focused on getting Ogre working and neither rebuilt druntime/phobos nor tested the showcase example against the latest commits they might have broken something. Also the README forgets to say how libshowcase.a should be built: clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o ar rcs libshowcase.a showcase.cpp.o ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ showcase.d Adding this now. I'm going to fix the rest this afternoon (finally some free time), and also figure out why assistbuilder.cpp failed to compile against the latest Clang 3.5. Also going to setup a testing script to ensure not everything gets broken again by a commit.
Re: Calypso: Direct and full interfacing to C++
On 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
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
Nevermind it's just that CodeGen is ambiguous with clang::CodeGen although my compiler doesn't complain. Fixed.
Re: Calypso: Direct and full interfacing to C++
On Friday, 23 January 2015 at 23:06:16 UTC, Kelly wrote: People might still need the small quick fixes for gen/cpp/assistbuilder.cpp, but just adding clang:: in a couple spots shouldn't be too arduous for anybody if they really want to compile and play with Calypso. Weird, assistbuilder.cpp compiled fine here with up-to-date Clang 3.5. Did you checkout the 3.5 branch?
Re: Calypso: Direct and full interfacing to C++
On 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
Re: Calypso: Direct and full interfacing to C++
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)
Re: Calypso: Direct and full interfacing to C++
I can't build clang. I am getting strange error: D:\llvm\cfe-3.5.0.src\cfe-3.5.0.srcmake Error on line 23: expecting target : dependencies
Re: Calypso: Direct and full interfacing to C++
On Thursday, 22 January 2015 at 07:27:03 UTC, Suliman wrote: First you need a LLVM + Clang 3.5 source tree, built libraries and the Clang binaries. Installing binary packages from your distribution isn't enough since the include/ files aren't exposing many symbols, so the source packages are needed as well Do I need to compile from source just Clang or both? Usually Clang is built with LLVM, i.e running make inside the LLVM build directory will build both LLVM and Clang. On Thursday, 22 January 2015 at 07:07:42 UTC, Suliman wrote: Currently making D classes derive from C++ classes with a virtual table only works with MinGW because only the Itanium ABI is supported. I'm going to add the Microsoft ABI ASAP (it's just a few lines of code) but it'll be untested. Could you explain can I call function from C++ dll directly? I am need only basic C++ support -- just ability to call very basic functions. Am I right understand that with Calypso I do not need to create bindings? If it's correct - could you provide any example of calling C++ function from dll? On Windows the Clang executable has to be in one of the %PATH% folders and then in your D code: modmap (C++) headerofyourdll.h; // will make Clang generate a precompiled header import (C++) Namespace1.Namespace2._; // If your functions are global functions inside Namespace1.Namespace2, _ is a special module (for now) that contains all the global funcs, vars and typedefs import (C++) Namespace1.Struct1; // If they are inside a struct named Struct1 The imports expose symbols that you can use like you'd use D structs and functions. Finally you need to tell LDC to link to your library: ldc -L=yourDLL.lib (...)
Re: Calypso: Direct and full interfacing to C++
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
Re: Calypso: Direct and full interfacing to C++
On Thursday, 22 January 2015 at 00:08:13 UTC, Walter Bright wrote: Just making STL work would be an achievement! Is the output of Calypso a file that can be imported? The only outputs specific to Calypso are ligthweight object files per C++ module that contain symbols created by LDC for aggregates (InitZ...) and template specializations by Clang if they're not defined in the PCH. What Calypso basically does is tell Clang to generate a big PCH for all the headers in modmap directives, and to map on demand C++ declarations from the PCH to D symbols in a separate tree of modules (hence the (C++) in imports, they're not physical modules). Those symbols can be used like D's, although they have different implementations to handle the C++ specificities, and all the non-trivial semantic work is done by Clang libraries and queried back by Calypso (aggregate layout, partial template argument deduction, ...). There are still some very feels hackish areas like the fact that DMD considers C++ classes to derive from Object too (fortunately Object is only a handful of virtual functions), I haven't solved yet how class values should be treated, etc. Also the PCH is a temporary solution because at the time I began working on Calypso Clang's support for modules was broken. But they would be great to break the global namespace in smaller pieces, so now that they seem ready to use the plan is to replace the PCH by them, or by a slightly different flavor of them (because there's currently one limitation that reduces its usefulness, it's that one header can't be split across several modules).
Re: Calypso: Direct and full interfacing to C++
On 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.
Re: Calypso: Direct and full interfacing to C++
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?
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 21 January 2015 at 10:37:18 UTC, Suliman wrote: Could you explain how to build it's on Windows. I read readme, but do not fully understand what I should to to to get it's work? You should follow the guides for LDC only you need to build Clang 3.5 as well beforehand and add the -DLLVM_SOURCE_PATH=/path/to/llvm/source/tree argument to the cmake command while building Calypso. Using Visual Studio: http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC Using MinGW : http://wiki.dlang.org/Building_LDC_on_MinGW_x86 Currently making D classes derive from C++ classes with a virtual table only works with MinGW because only the Itanium ABI is supported. I'm going to add the Microsoft ABI ASAP (it's just a few lines of code) but it'll be untested. On Wednesday, 21 January 2015 at 21:27:27 UTC, Walter Bright wrote: I think this is an exciting development! Considering the new D support for C++ namespaces, template mangling, etc., I think it would make Calypso's job easier. The big challenge is to get an interface to C++ STL, so one could do: import core.stdcpp.stl.vector; for example. I'd also like to encourage you to submit a Dconf 2015 presentation proposal on this. Thanks, Walter! A small update since the announcement: instantiation of C++ class templates is now working, with the right partial specialization selected if any. I'm still working as fast as I can to get Ogre3D working. Ogre3D makes wide usage of the standard C++ library so getting it running would be a milestone and at that point most C++ libraries will be usable or in close reach as well. And it'd also make a sweet demo :)
Re: Calypso: Direct and full interfacing to C++
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?
Re: Calypso: Direct and full interfacing to C++
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?
Re: Calypso: Direct and full interfacing to C++
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?
Re: Calypso: Direct and full interfacing to C++
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/weodkqwxrqetvolhb...@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.
Re: Calypso: Direct and full interfacing to C++
Or it can switch depending on preprocessor definitions:
---
class WXDLLIMPEXP_BASE wxString
#ifdef wxNEEDS_WXSTRING_PRINTF_MIXIN
: public wxStringPrintfMixin
#endif
{
---
