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.

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

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

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?

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

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

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

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!

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.

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