On Monday, 17 February 2014 at 09:46:15 UTC, Andrej Mitrovic wrote:
> On 2/16/14, Abdulhaq <alynch4047@gmail.com> wrote:
>> that should of course be
>>
>> https://github.com/alynch4047/smidgen
>
> Nice. I've had a codegen project before which is currently stalled:
> https://github.com/AndrejMitrovic/dgen
>
> Some docs I wrote about peculiarities of wrapping C++:
> https://github.com/AndrejMitrovic/dgen/wiki
>

Nice tools, I've also been working on a C++ binding tool myself (mostly C#/.NET though).

https://github.com/mono/CppSharp

It is based on the Clang C++ parser. All the hard work of parsing and C++ AST support is done, so in theory a D backend could be added, if the days had more hours I'd work on one myself :)

The previous maintainer for Qyoto (Qt C# binding) and SMOKE (the binding generator I've seen referenced before in this thread) has been working on a new Qt C#-based binding effort, called QtSharp, that uses C++# (CppSharp).

https://github.com/ddobrev/QtSharp

On Monday, 17 February 2014 at 08:49:09 UTC, Abdulhaq wrote:
>
>> I have a SWIG version of D-VTK but it is a little flaky and soooo slow to generate. I've just started work developing D wrapper for VTK based on their Java wrapper but it's very early stages (started yesterday in fact).
>>
>> If you've got a VTK wrapping that generates D code I'd love to check it out.
>>
>
> The smidgen binding generator is (I believe) sufficiently feature rich to wrap all of VTK, but I've only wrapped a half dozen classes as proof of concept for now (I've been focussing on Qt5). My plan on the VTK side has been to use the automated binding generator in VTK to produce the *.sip (similar to *.h) files that smidgen needs.
>
> VTK is quite a large library so I would expect the wrapper to be a bit slow to generate, however it shouldn't be flaky when running. I would suspect that you've got a glitch in object ownership somewhere? My plan has been that the automatic VTK binding generator for e.g. python knows about object ownership, and so I can tap in to that to generate the correct smidgen annotations that are needed for that aspect of the binding. I've also found that you can get problems when wrapped methods return instances typed as base classes that need casting to more specific types.
>
> I'm wondering if we can pool our efforts somehow? Because I need to finish the last parts of smidgen (e.g. enums with specific values and subtleties with C++ multiple inheritance)and the Qt5 wrapping side of it I couldn't divert much from my current trajectory, but if you get a chance then have a look at what smidgen is doing and see if you think you'd get any benefit using it (and you'd have my efforts working to extend smidgen for you if needed). As soon as I've uploaded the current smidgen-vtk I'll notify here.
>
> Another way we might be able to cooperate is getting a full understanding of the current built-in VTK binding generator technology.
>
> Is your SWIG wrapping online somewhere? - I'd like to take a look.

https://github.com/lyrebirdsw/vtkdbind

The SWIG bindings were left in a very bad state so they won't work at the moment. It should generate the D code and possibly compile but I don't think it will link I sort of gave up on it and decided to try the VTK wrapper generator.

The last bindings I generated are in the repo under swigd/bindings/d

Oh and some of the scripts will have a copyright in them, ignore it. It is just the automatic header our editors at work stamp in. It is all opensource, consider it BSD, I just haven't bothered putting any license in the files themselves.

As for the VTK wrapper bindings they are convoluted but I'm making some headway. It is spread across C++/CMake files to complete the full process. The C++ creates a parser which extracts the required details, CMake then feeds the output of this into the wrapper generator.

I have it generating half D / half Java at the moment. If I get it all D and compiling I'll upload it.

Cheers,
ed

On 2/18/14, Joao Matos <joao@tritao.eu> wrote:
> Nice tools, I've also been working on a C++ binding tool myself
> (mostly C#/.NET though).
>
> https://github.com/mono/CppSharp

Does this use Clang's C++ API or libclang which is a C API? If the former, I didn't know you could call into C++ code from C#, at least not very easily. Was it hard to do? I guess I'm looking for any experiences you can share.

On Tuesday, 18 February 2014 at 06:44:19 UTC, ed wrote:
[snip]

>>
>> Is your SWIG wrapping online somewhere? - I'd like to take a look.
>
> https://github.com/lyrebirdsw/vtkdbind
>
> The SWIG bindings were left in a very bad state so they won't work at the moment. It should generate the D code and possibly compile but I don't think it will link I sort of gave up on it and decided to try the VTK wrapper generator.
>
> The last bindings I generated are in the repo under swigd/bindings/d
>
> Oh and some of the scripts will have a copyright in them, ignore it. It is just the automatic header our editors at work stamp in. It is all opensource, consider it BSD, I just haven't bothered putting any license in the files themselves.
>
> As for the VTK wrapper bindings they are convoluted but I'm making some headway. It is spread across C++/CMake files to complete the full process. The C++ creates a parser which extracts the required details, CMake then feeds the output of this into the wrapper generator.
>
> I have it generating half D / half Java at the moment. If I get it all D and compiling I'll upload it.
>
> Cheers,
> ed

Oh let me say this is real hack code I wrote for experimentation only :D

On Monday, 17 February 2014 at 22:58:57 UTC, Andrej Mitrovic wrote:
>
> And then there are things like trying to allow access to protected
> methods (meaning you have to re-declare them public for the C wrappers
> to access them), which isn't easy because simply re-declaring them
> only works in /some/ contests (specifically when overloads come into
> play it's a mess). And then having to handle namespaces.. etc etc.
> It's very easy to burn out. :)
>

There are many problems to solve, it take a lot of thought and time. I've ploughed all my spare time into it for a couple of months, then I moved house. Now I've got to get back in to it again :-).

>
> I can't even recall how I planned to support multiple inheritance. I
> think I was planning on using interfaces, but to keep all classes
> neatly castable up the hirearchy at the D side it would probably mean
> having to make /all/ classes inherit from interfaces.
>

I'm only trying to handle mixin-style multiple inheritance, and doing it with interfaces for the mixins. I've got to finish up dealing with the fact that the C++ pointer can change for the same object with multiple inheritance, but it's just about done.

> And then you have to worry about memory management. Fun stuff..

It's so depressing when it all seems golden and then the application using the wrapper crashes! Anyway I believe I've got that aspect sorted out now. I wish D had proper support for weak references.

I'm glad to have this conversation it's given me renewed energy to finish it off...

On Tuesday, 18 February 2014 at 08:32:07 UTC, ed wrote:
> On Tuesday, 18 February 2014 at 06:44:19 UTC, ed wrote:
> [snip]
>
>>>
>>> Is your SWIG wrapping online somewhere? - I'd like to take a look.
>>
>> https://github.com/lyrebirdsw/vtkdbind
>>
>> The SWIG bindings were left in a very bad state so they won't work at the moment. It should generate the D code and possibly compile but I don't think it will link I sort of gave up on it and decided to try the VTK wrapper generator.
>>
>> The last bindings I generated are in the repo under swigd/bindings/d
>>
>> Oh and some of the scripts will have a copyright in them, ignore it. It is just the automatic header our editors at work stamp in. It is all opensource, consider it BSD, I just haven't bothered putting any license in the files themselves.
>>
>> As for the VTK wrapper bindings they are convoluted but I'm making some headway. It is spread across C++/CMake files to complete the full process. The C++ creates a parser which extracts the required details, CMake then feeds the output of this into the wrapper generator.
>>
>> I have it generating half D / half Java at the moment. If I get it all D and compiling I'll upload it.
>>
>> Cheers,
>> ed
>
> Oh let me say this is real hack code I wrote for experimentation only :D

Thanks for taking the effort to upload it! If you do get the VTK wrapper approach going then please do upload that. I'd really like to know how the wrapper generator deals with object ownership transferal, or is it using some kind of reference counting?

On Tuesday, 18 February 2014 at 09:15:11 UTC, Abdulhaq wrote:
> On Tuesday, 18 February 2014 at 08:32:07 UTC, ed wrote:
>> On Tuesday, 18 February 2014 at 06:44:19 UTC, ed wrote:
>> [snip]
>>
>>>>
>>>> Is your SWIG wrapping online somewhere? - I'd like to take a look.
>>>
>>> https://github.com/lyrebirdsw/vtkdbind
>>>
>>> The SWIG bindings were left in a very bad state so they won't work at the moment. It should generate the D code and possibly compile but I don't think it will link I sort of gave up on it and decided to try the VTK wrapper generator.
>>>
>>> The last bindings I generated are in the repo under swigd/bindings/d
>>>
>>> Oh and some of the scripts will have a copyright in them, ignore it. It is just the automatic header our editors at work stamp in. It is all opensource, consider it BSD, I just haven't bothered putting any license in the files themselves.
>>>
>>> As for the VTK wrapper bindings they are convoluted but I'm making some headway. It is spread across C++/CMake files to complete the full process. The C++ creates a parser which extracts the required details, CMake then feeds the output of this into the wrapper generator.
>>>
>>> I have it generating half D / half Java at the moment. If I get it all D and compiling I'll upload it.
>>>
>>> Cheers,
>>> ed
>>
>> Oh let me say this is real hack code I wrote for experimentation only :D
>
> Thanks for taking the effort to upload it! If you do get the VTK wrapper approach going then please do upload that. I'd really like to know how the wrapper generator deals with object ownership transferal, or is it using some kind of reference counting?

Well I only know the Java wrapper as that is the one I'm trying to adapt. It uses reference counting and a custom garbage collector in the Java layer (vtkJavaGarbageCollector).

I'm looking at adapting this over to D. So far all goes well, Java -->> D is straight forward. It will get interesting though when things statr compiling :)

I'll post here if I get any further...

Cheers,
ed

vtkJava

On Tuesday, 18 February 2014 at 09:28:07 UTC, ed wrote:
[snip]
> Java -->> D is straight forward. It will get interesting though when things statr compiling :)

s/compiling/linking/

C++ binding generator is definitely something we will use. However, I would rather have a good, robust tool that can be used to generate bindings/wrappers to C libraries. That is of equal (or even higher I think) importance as C++ binding generator.

On Sunday, 16 February 2014 at 14:10:02 UTC, Abdulhaq wrote:
>
>> yes github please.. i'd like to check this out.
>
> OK I'm in the process of migrating the code to github. I was in such a hurry yesterday evening I didn't list the features properly:
>
> FEATURES
> ========
>
> * All D
> * Understandable, maintainable code
> * Wraps protected and virtual methods, allows virtual methods to be overridden in D
> * Mixin classes in target C++ library supported
> * Allows custom type conversions between C++ and D types
> * C++ enums mapped to D enums and are type checked in D
> * Wraps nested C++ classes
> * Tested
> * Based on the sip format. This is well proven and allows simplified maintenance of wrappers for multiple versions of the target library.  (All larger target libraries will need some ongoing maintenance of the wrapper regardless of the wrapping technology).
>
> Once all the code is in github I'll just check that a totally clean build is working, and then give you a heads up. FYI the repository is at
>
> https://github.com/alynch4047/smidgen/tree/master/morsel

This looks very nice!
Two questions, though:

1) Is it possible to use an already existing C API with morsel? The reason I'm asking is, because LLVM classes contain many methods where an automatic conversion is likely to cause memory leaks to appear. This is the main reason why I decided to use the C-API for my llvm-d project, instead of attempting to use automatic tools like SWIG (that and the fact that LLVM did not export C++ symbols properly for a Windows DLL, so you needed to use the C API anyway).

2) What is the main difference between using morsel and SWIG, other than the language used to specify the interface?