February 12, 2012
On 2/12/12, Gour <gour@atmarama.net> wrote:
> I saw your messages in wx-dev and wonder what will be the way to keep those files in sync or, at least, detect there are inconsistencies?

They have a tool called ifacecheck which compares the xml files generated by doxygen to the ones generated by using gccxml. I've used gccxml before. I haven't used ifacecheck yet but I'll give it a run.
February 12, 2012
On 02/12/2012 03:04 AM, Andrej Mitrovic wrote:
> For wxc I'll have to provide both static and shared library support.
>

Perfect!

> win32-only: I've tried statically linking 2.9.3 via optlink but it
> couldn't handle the vast amount of symbol names. Even if that was
> resolved (it won't be) I can't use optlink anymore since wxWidgets has
> basically dropped support for DMC, and I have to use either g++ or MSC
> to build wxWidgets. Remember that Optlink can't link to COFF. The
> alternatives that I know of are DMD+Unilink + static/dynamic library,
> DMD+Optlink + dynamic library, or GDC + static/dynamic library.
> There's also LDC but I haven't used it for D2 yet.


I think GDC is the tool of choice for wxd win32 and 64 development anyway. so i would use GDC. I meant _using_ wxD. Building wxD is most probably also more comfortable using GDC.

Event-Handling. Yesterday I had a look at the old wxd source from Anders. wxevent.d looks already very promising.

Thanks,
Bjoern
February 15, 2012
On 2/11/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> 132+ are left to go.

55 left. This is the harder part now since most of these left are interface mismatches and not codegenerator bugs. As you can see I've started filing reports with patches: http://trac.wxwidgets.org/query?reporter=drey&order=priority
February 15, 2012
On 02/15/2012 06:53 AM, Andrej Mitrovic wrote:
> On 2/11/12, Andrej Mitrovic<andrej.mitrovich@gmail.com>  wrote:
>> 132+ are left to go.
>
> 55 left. This is the harder part now since most of these left are
> interface mismatches and not codegenerator bugs. As you can see I've
> started filing reports with patches:
> http://trac.wxwidgets.org/query?reporter=drey&order=priority

Excellent. Most of your patches are already accepted and closed.

Seems you are a bug fixing machine. Let me quote Vladimir Zeitilin..
"I was trying to close these reports as you find them but it looks like your speed has picked up so it's going to be more difficult for me to keep up now...."

:)

I have a couple of questions, but I think I have to wait until wxC is done. Thanks Andrej.
February 15, 2012
On Wed, 15 Feb 2012 15:53:32 +0100
Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> 55 left. This is the harder part now since most of these left are interface mismatches and not codegenerator bugs. As you can see I've started filing reports with patches:

All glory to you!

I see that you're pushing constant stream of tickets to wx's Trac and many of them are even getting fixed.

It seems that at the end, besides getting wxC & wxD, that even wxWidgets project itself will be greatly benefitted.

My heartfelt gratitude for your work, Andrej.


Sincerely,
Gour

-- 
One who is not connected with the Supreme can have neither transcendental intelligence nor a steady mind, without which there is no possibility of peace. And how can there be any happiness without peace?

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


March 17, 2012
On 2/11/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> The D classes
> are not yet generated until I get wxc done, but wxc is 95% of the
> source of difficulty. Generating wxd should be easy after that.

Sorry for the long wait. Turns out I was *extremely* wrong about this. Generating the D side turned out to be a hell of a lot more work then I initially thought (mostly due to C++ and D type incompatibilities and scoping issues).

I could have tried to generate SWIG interfaces, however I wasn't impressed with wxPython which used thousands of lines of hand-crafted interfaces. I'm also really not sure just how stable SWIG is for D, especially for a large library like wxD. And then I saw that the new wxPython codebase (the Phoenix project) uses over 11000 lines of manually edited files that help the SIP generator do its work. I find maintaining 11K lines of code to be a huge burden, so I stayed away from that codebase alltogether. I want as much code to be autogenerated as possible. Note that I didn't base my codgenerator on wxPhp either, that codebase is very specific to php and so I've had to go from scratch. I've initially used wxPhp just to figure out which xml info I had to extract (I'm extracting a lot more info now compared to wxPhp).

I've recently had a major refactoring of the autogenerator to make it easier to generate wxd. However I have to re-edit the wxc generator due to this new refactor (it shouldn't be too much work). On the upside of things the autogenerator can now generate around 85000 lines of compileable D code (that's the actual wxD library). That's around 300 files and 643 classes that compile. This is not linkable yet, since wxc has to be recreated again. Another cool statistic is that generating all of this takes about 4 seconds. (I can regenerate individual files as well which only takes a split second). The xml parser is a bit slow right now and takes some ~24 seconds to parse around 1500 XML files. This can be optimized later. But it too can re-parse single classes/headers which takes only a split second to do.

So now I'm starting to work on wxc generation again. Once that's done, I have to test linking between wxd and wxc. Then, I have to fix any runtime segfaults I might run into (there's bound to be a few codegen issues). Once I have a few wxD samples working on the major platforms, I'll release an alpha of wxD (+ the codegenerator) and then we can start testing the library more thoroughly before any official release.

So, stay tight! Good times ahead. :)
March 17, 2012
On Fri, Mar 16, 2012 at 7:29 PM, Andrej Mitrovic <andrej.mitrovich@gmail.com
> wrote:

> On 2/11/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> > The D classes
> > are not yet generated until I get wxc done, but wxc is 95% of the
> > source of difficulty. Generating wxd should be easy after that.
>
> Sorry for the long wait. Turns out I was *extremely* wrong about this. Generating the D side turned out to be a hell of a lot more work then I initially thought (mostly due to C++ and D type incompatibilities and scoping issues).
>
> I could have tried to generate SWIG interfaces, however I wasn't impressed with wxPython which used thousands of lines of hand-crafted interfaces. I'm also really not sure just how stable SWIG is for D, especially for a large library like wxD. And then I saw that the new wxPython codebase (the Phoenix project) uses over 11000 lines of manually edited files that help the SIP generator do its work. I find maintaining 11K lines of code to be a huge burden, so I stayed away from that codebase alltogether. I want as much code to be autogenerated as possible. Note that I didn't base my codgenerator on wxPhp either, that codebase is very specific to php and so I've had to go from scratch. I've initially used wxPhp just to figure out which xml info I had to extract (I'm extracting a lot more info now compared to wxPhp).
>
> I've recently had a major refactoring of the autogenerator to make it easier to generate wxd. However I have to re-edit the wxc generator due to this new refactor (it shouldn't be too much work). On the upside of things the autogenerator can now generate around 85000 lines of compileable D code (that's the actual wxD library). That's around 300 files and 643 classes that compile. This is not linkable yet, since wxc has to be recreated again. Another cool statistic is that generating all of this takes about 4 seconds. (I can regenerate individual files as well which only takes a split second). The xml parser is a bit slow right now and takes some ~24 seconds to parse around 1500 XML files. This can be optimized later. But it too can re-parse single classes/headers which takes only a split second to do.
>
> So now I'm starting to work on wxc generation again. Once that's done, I have to test linking between wxd and wxc. Then, I have to fix any runtime segfaults I might run into (there's bound to be a few codegen issues). Once I have a few wxD samples working on the major platforms, I'll release an alpha of wxD (+ the codegenerator) and then we can start testing the library more thoroughly before any official release.
>
> So, stay tight! Good times ahead. :)
>

As a heavy user of wxWidgets (in C++) I'm very excited about this.  I'll definitely be one of your alpha testers when it comes out.

Could the wxc generator be be used as a base for building bindings for other libraries? How about the XML D generator?

Regards,
Brad Anderson


March 17, 2012
On 3/17/12, Brad Anderson <eco@gnuk.net> wrote:
> Could the wxc generator be be used as a base for building bindings for other libraries?

I hope it will be. It's kind of crazy that the first thing I'm using it on is a huge library like wxD, this will likely be its biggest unittest, so to speak. :p

Doxygen can be run on libraries with no documentation (there's a switch for that), so it can extract the needed data for the generator. Of course it depends how complex the library is, e.g. you can't run doxygen directly on wxWidgets include files because they're very complicated (it actually crashes doxygen), but this is why the wx devs have created a separate set of interface files for doxygen.

> How about the XML D generator?

Sorry for not being clear, that part is not an xml D generator but an xml extractor used for doxygen xml files. The process is the following:

1. Extract as much information as possible from the doxygen xml files
and store them to various structs (I have
header/class/typedef/enum/etc structs).
2. Serialize the structs to json for the generator (this is a simple
toJson() call). I do this step so I don't have to re-run the xml
extractor every time I run the generator.
3. Run the generator, it deserializes the json files and gets all
those structs with information like classes, typedefs, enums,
parameter types, default values, etc. Then it generates the D code.

The xml extractor is about 1500 lines of code, and the D generator about 2000 lines (with a few string-processing helper functions in other modules), but this will be compacted later when I get rid of various code duplication.
March 17, 2012
On Sat, 17 Mar 2012 02:29:26 +0100
Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> Sorry for the long wait. Turns out I was *extremely* wrong about this. Generating the D side turned out to be a hell of a lot more work then I initially thought (mostly due to C++ and D type incompatibilities and scoping issues).

Huh, Murphy in action?

> So now I'm starting to work on wxc generation again. Once that's done, I have to test linking between wxd and wxc. Then, I have to fix any runtime segfaults I might run into (there's bound to be a few codegen issues). Once I have a few wxD samples working on the major platforms, I'll release an alpha of wxD (+ the codegenerator) and then we can start testing the library more thoroughly before any official release.

Although we're still swamped into non-D computer issues, we'll find the time to be tester of your alpha release.

Thank you, again, for your hard work!


Sincerely,
Gour


-- 
O chastiser of the enemy, the sacrifice performed in knowledge is better than the mere sacrifice of material possessions. After all, O son of Pṛthā, all sacrifices of work culminate in transcendental knowledge.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


March 17, 2012
On 03/16/2012 06:29 PM, Andrej Mitrovic wrote:
> So, stay tight! Good times ahead.:)

Incredible good news! Thanks.

One of the very first wxD applications could be a GUI for the generator.