Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-01-25 18:07, Trass3r wrote: Whats.necessary to use D in order to create C++ bindings ? github.com/jacob-carlborg/dstep I've released the first alpha/beta version: http://forum.dlang.org/thread/jt9i6l$2go5$1...@digitalmars.com -- /Jacob Carlborg
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Sat, 17 Mar 2012 02:29:26 +0100 Andrej Mitrovic andrej.mitrov...@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 signature.asc Description: PGP signature
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
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.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-03-17 04:34, Andrej Mitrovic wrote: On 3/17/12, Brad Andersone...@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. This is why a proper compiler is needed, this will not work in the long run. -- /Jacob Carlborg
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 03/17/2012 09:50 AM, Jacob Carlborg wrote: This is why a proper compiler is needed, this will not work in the long run. Are you aware that doxgen's xml output is based on gcc-xml ? I think it is necessary to say that doxygen, respective gcc-xml, is working on stripped and annotated header files (so called interface files) f.i. http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/interface/wx/ So, stupid manual work is needed to create these interface files. Until you don't have a heavily templated c++ lib, using doygen's xml output is, IMHO, a reasonable way to create bindings. well, will see
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-03-17 18:36, bls wrote: On 03/17/2012 09:50 AM, Jacob Carlborg wrote: This is why a proper compiler is needed, this will not work in the long run. Are you aware that doxgen's xml output is based on gcc-xml ? No, I was not aware of that. What is the problem then, doxygen choking on the XML or GCC choking on the include files? I think it is necessary to say that doxygen, respective gcc-xml, is working on stripped and annotated header files (so called interface files) f.i. http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/interface/wx/ So, stupid manual work is needed to create these interface files. That sucks. -- /Jacob Carlborg
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 03/17/2012 10:44 AM, Jacob Carlborg wrote: On 2012-03-17 18:36, bls wrote: On 03/17/2012 09:50 AM, Jacob Carlborg wrote: This is why a proper compiler is needed, this will not work in the long run. Are you aware that doxgen's xml output is based on gcc-xml ? No, I was not aware of that. What is the problem then, doxygen choking on the XML or GCC choking on the include files? I think it is necessary to say that doxygen, respective gcc-xml, is working on stripped and annotated header files (so called interface files) f.i. http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/interface/wx/ So, stupid manual work is needed to create these interface files. That sucks. Yeah it sucks, but on the other hand it is AFAIK just removing the private stuff (methods, decls, etc.) forward decls, and write some annotations.. like @iOS-only from the header. I really hope to see a working wxD soon. I will try to create bindings for the wxShapeFramework than..
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 03/17/2012 10:44 AM, Jacob Carlborg wrote: What is the problem then, doxygen choking on the XML or GCC choking on the include files? gcc-xml is stalled. Means newer C++ stuff is not supported. See news... http://www.gccxml.org/HTML/News.html
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 03/17/2012 10:51 AM, bls wrote: Are you aware that doxgen's xml output is based on gcc-xml ? I should be more carefull :( It's another wxWidgets utility that is using gcc-xml.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 3/17/12, Jacob Carlborg d...@me.com wrote: This is why a proper compiler is needed, this will not work in the long run. The generator doesn't really care which tool you use to extract the data. It should be possible to use a tool such as LLVM to fill the structs with all the information it needs to build the wrappers. So in essence it works in a similar way as your dstep project, although I don't really know how far you've gone in implementing dstep so I can't compare the two.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-03-17 20:20, Andrej Mitrovic wrote: On 3/17/12, Jacob Carlborgd...@me.com wrote: This is why a proper compiler is needed, this will not work in the long run. The generator doesn't really care which tool you use to extract the data. It should be possible to use a tool such as LLVM to fill the structs with all the information it needs to build the wrappers. So in essence it works in a similar way as your dstep project, although I don't really know how far you've gone in implementing dstep so I can't compare the two. Not ready for a comparison yet. -- /Jacob Carlborg
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2/11/12, Andrej Mitrovic andrej.mitrov...@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. :)
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Fri, Mar 16, 2012 at 7:29 PM, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 2/11/12, Andrej Mitrovic andrej.mitrov...@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
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 3/17/12, Brad Anderson e...@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.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2/11/12, Andrej Mitrovic andrej.mitrov...@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=dreyorder=priority
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 02/15/2012 06:53 AM, Andrej Mitrovic wrote: On 2/11/12, Andrej Mitrovicandrej.mitrov...@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=dreyorder=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.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Wed, 15 Feb 2012 15:53:32 +0100 Andrej Mitrovic andrej.mitrov...@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 signature.asc Description: PGP signature
wxD bindings (was Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.)
On Sat, 11 Feb 2012 20:45:06 +0100 Andrej Mitrovic andrej.mitrov...@gmail.com wrote: 542 classes are successfully generated (and buildable). 132+ are left to go. Great! I've ran into a few issues where the interface files (from which the xml is built) are not in sync with the code. So there might be missing types definitions, or wrong types in methods, etc. But these can be worked around by adding extra type definitions in the generator (IOW there's no need to manually touch the .cpp files by hand). 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? So wxc won't be done by this week, but it's progressing pretty good so far. Stay tuned.. All the best!! Sincerely, Gour -- Whatever action a great man performs, common men follow. And whatever standards he sets by exemplary acts, all the world pursues. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2/11/12, bls bizp...@orange.fr wrote: Silly Question .. did you try to to use regen (or however it is named) script to re-create the doxygen xml files ? That's what I do, yes. The wxPhp xml files were a little outdated anyway. Another question regarding wxC. Will there be an option to generate a shared library so/dll ? For wxc I'll have to provide both static and shared library support. 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.
Re: wxD bindings (was Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.)
On 2/12/12, Gour g...@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.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
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
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
Just a small update: 542 classes are successfully generated (and buildable). 132+ are left to go. I've ran into a few issues where the interface files (from which the xml is built) are not in sync with the code. So there might be missing types definitions, or wrong types in methods, etc. But these can be worked around by adding extra type definitions in the generator (IOW there's no need to manually touch the .cpp files by hand). So wxc won't be done by this week, but it's progressing pretty good so far. Stay tuned..
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2/11/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: 542 classes Sorry, when I said classes I meant wxc class wrappers. 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.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 02/11/2012 11:45 AM, Andrej Mitrovic wrote: Just a small update: 542 classes are successfully generated (and buildable). 132+ are left to go. I've ran into a few issues where the interface files (from which the xml is built) are not in sync with the code. So there might be missing types definitions, or wrong types in methods, etc. But these can be worked around by adding extra type definitions in the generator (IOW there's no need to manually touch the .cpp files by hand). So wxc won't be done by this week, but it's progressing pretty good so far. Stay tuned.. Chapeau Andrej ! Silly Question .. did you try to to use regen (or however it is named) script to re-create the doxygen xml files ? Another question regarding wxC. Will there be an option to generate a shared library so/dll ? Thanks (and please keep us informed.) Bjoern
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 1/26/12, bls bizp...@orange.fr wrote: Hi Andrej, first of all : it is NOT my intention to pick on your nerves. I am just curious and , ahem, a bit impatience. Have you made some progress on the code generator ? Are you running into problems, hard to solve problems ? Well, it would be nice to get some feedback. I am really keen to see the code. (cause I'll try,based on your code, to create bindings to the wxShapeFramework... ) Kind regards, Bjoern (bls) PS Have you noticed the wxPHP update. PPS Wouldn't make more sense to use the new Tango 2 'cause it has XPath support ? Given XPath support is imited, but I think good enough for this task. I'm working on this around the clock. If everything goes ok I might have the wxc wrapper done by the end of the week, but I'm not making any promises. I'm not having much difficulty, there are some edge-cases here and there but it's fine. PS: Yes, however I'm now basing the wxc generated code around the existing wxc binding, and not wxPhp. wxPhp uses some 3rd party library that has to do a lot of magic to interact with a C library, so it's code generators are not that useful to me. The existing wxc bindings already have memory management in place which I can reuse. PPS: I'm parsing the xml files fine, there's no need to use tango at this point. I'm not publishing any code yet since I don't want people to do duplicate work and make pulls, we'll end up stepping on each other's toes. And work can't be done in parallel since you need wxc before you can generate wxd wrappers. I'd ask for a little bit of patience! Thanks. :)
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 27 January 2012 18:38, Kagamin s...@here.lot wrote: On Wednesday, 25 January 2012 at 18:01:48 UTC, Zachary Lund wrote: I do not mind using a C library in D because of how straight forward it is. But simply mentioning C++ in D seems to add unneeded complexity which should be avoided. I think the answer to a question such as What's the alternative to Qt in D? should not be Qt bindings but maybe a library which imitates the implementation and/or interface of Qt UI widgets in native D. http://www.ohloh.net/p/qt/estimated_cost some scary numbers To be taken with a pinch of salt. I raised an eyebrow or two when looking at the estimated cost for GDC. ;-) -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Monday, 6 February 2012 at 11:25:09 UTC, Iain Buclaw wrote: To be taken with a pinch of salt. I raised an eyebrow or two when looking at the estimated cost for GDC. ;-) A C++ to D autoporter? That's an interesting idea.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 02/06/2012 03:06 AM, Andrej Mitrovic wrote: On 1/26/12, blsbizp...@orange.fr wrote: Hi Andrej, first of all : it is NOT my intention to pick on your nerves. I am just curious and , ahem, a bit impatience. Have you made some progress on the code generator ? Are you running into problems, hard to solve problems ? Well, it would be nice to get some feedback. I am really keen to see the code. (cause I'll try,based on your code, to create bindings to the wxShapeFramework... ) Kind regards, Bjoern (bls) PS Have you noticed the wxPHP update. PPS Wouldn't make more sense to use the new Tango 2 'cause it has XPath support ? Given XPath support is imited, but I think good enough for this task. I'm working on this around the clock. If everything goes ok I might have the wxc wrapper done by the end of the week, but I'm not making any promises. I'm not having much difficulty, there are some edge-cases here and there but it's fine. PS: Yes, however I'm now basing the wxc generated code around the existing wxc binding, and not wxPhp. wxPhp uses some 3rd party library that has to do a lot of magic to interact with a C library, so it's code generators are not that useful to me. The existing wxc bindings already have memory management in place which I can reuse. PPS: I'm parsing the xml files fine, there's no need to use tango at this point. I'm not publishing any code yet since I don't want people to do duplicate work and make pulls, we'll end up stepping on each other's toes. And work can't be done in parallel since you need wxc before you can generate wxd wrappers. I'd ask for a little bit of patience! Thanks. :) Very very good news. Thanks Andrej
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Mon, 6 Feb 2012 12:06:44 +0100 Andrej Mitrovic andrej.mitrov...@gmail.com wrote: I'm working on this around the clock. If everything goes ok I might have the wxc wrapper done by the end of the week, but I'm not making any promises. Thank you very much for your efforts!! I'd ask for a little bit of patience! Thanks. :) No problem. We've all the patience of the world. ;) Sincerely, Gour -- The spirit soul bewildered by the influence of false ego thinks himself the doer of activities that are in actuality carried out by the three modes of material nature. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
So, I would not minimize the fact to get stable/actively_developed/easily_maintained bindings for native multi-platform GUI toolkit. ;) Sincerely, Gour I just wonder dwt(http://www.dsource.org/projects/dwt) is not good enough? Regards Marton Papp
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Sat, 28 Jan 2012 12:14:12 +0100 equi...@atw.hu wrote: I just wonder dwt(http://www.dsource.org/projects/dwt) is not good enough? Well, I prefer wx over SWT and besides that, Jacob said he has other higher priorities at the moment besides working on DWT. Sincerely, Gour -- While contemplating the objects of the senses, a person develops attachment for them, and from such attachment lust develops, and from lust anger arises. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-01-28 12:47, Gour wrote: On Sat, 28 Jan 2012 12:14:12 +0100 equi...@atw.hu wrote: I just wonder dwt(http://www.dsource.org/projects/dwt) is not good enough? Well, I prefer wx over SWT and besides that, Jacob said he has other higher priorities at the moment besides working on DWT. That doesn't stop others to work on DWT :) -- /Jacob Carlborg
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Sat, 28 Jan 2012 16:12:57 +0100 Jacob Carlborg d...@me.com wrote: That doesn't stop others to work on DWT :) Of course, but we don't need new forces joining forking. Sincerely, Gour -- As fire is covered by smoke, as a mirror is covered by dust, or as the embryo is covered by the womb, the living entity is similarly covered by different degrees of this lust. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 01/28/2012 03:47 AM, Gour wrote: On Sat, 28 Jan 2012 12:14:12 +0100 equi...@atw.hu wrote: I just wonder dwt(http://www.dsource.org/projects/dwt) is not good enough? Well, I prefer wx over SWT and besides that, Jacob said he has other higher priorities at the moment besides working on DWT. Sincerely, Gour DWT is not playing in the same playground (feature wise-platform wise) . So to answer your question Yes, DWT is not good enough. Let me quote Gour : Let's not forget that today the language itself does not mean much without 'batteries included' and the whole ecosystem inckluding IDE/editors suppor, build systems etc. So, I would not minimize the fact to get stable/actively_developed/easily_maintained bindings for native multi-platform GUI toolkit. ;) I have to agree. 100 percent Bjoern
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 01/28/2012 07:12 AM, Jacob Carlborg wrote: That doesn't stop others to work on DWT :) No offense Jacob! It is just that imo wxWidgets is the most flexible gui toolkiy in town. and reading what is planned for 3.0 yum iOS.. maybe AndroidBut despite that, DWT requires Java like programming in D (well, a matter of taste) . But also , NO dockable planes receptive, windows... week grid support, etc.. and so on, and so on. NO we need a full blown GUI and wxWidgets is,at least, a very good one. a+ bjoern
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Thu, 26 Jan 2012 23:18:10 +0100 Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Anyway, the XML parsing script is done and I've verified it has the same output as the php script. This thing parsed about 1400 xml files, so I don't see any issues with parsing doxygen xml files with a lightweight xml lib, at least not for wxWidgets. The next step is to port the generator scripts. I'll make updates as progress continues. Andrej, you're the bearer of the best D-news these days. Congrats!!! Sincerely, Gour -- One who is not disturbed in mind even amidst the threefold miseries or elated when there is happiness, and who is free from attachment, fear and anger, is called a sage of steady mind. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 1/27/12, Gour g...@atmarama.net wrote: Andrej, you're the bearer of the best D-news these days. Congrats!!! I appreciate the enthusiasm, but I think it should be toned down a bit. At this stage this work is pretty insignificant compared to all the work on e.g. improving DMD.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-01-27 08:48, Andrej Mitrovic wrote: On 1/27/12, equi...@atw.huequi...@atw.hu wrote: It is not clear what you do not use xml in tango library. I'm using D2, not D1. Tango is working find with D2: https://github.com/SiegeLord/Tango-D2 -- /Jacob Carlborg
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Fri, 27 Jan 2012 10:29:43 +0100 Andrej Mitrovic andrej.mitrov...@gmail.com wrote: I appreciate the enthusiasm, but I think it should be toned down a bit. At this stage this work is pretty insignificant compared to all the work on e.g. improving DMD. I'm aware that the folks working on improving/fixing DMD is doing terrific job, but in one sense this is kind of work that new D user could take as granted based on the premise that 'it should just work as described in e.g. TDPL'. Otoh, your work is extending usability of D to be used for writing real-world GUI applications and we cannot say how many people may abandon the idea to use D just by seeing the present state of many half-baked GUI bindings *before* even stumbling upon some DMD bugs. Let's not forget that today the language itself does not mean much without 'batteries included' and the whole ecosystem inckluding IDE/editors suppor, build systems etc. So, I would not minimize the fact to get stable/actively_developed/easily_maintained bindings for native multi-platform GUI toolkit. ;) Sincerely, Gour -- All living bodies subsist on food grains, which are produced from rains. Rains are produced by performance of yajña [sacrifice], and yajña is born of prescribed duties. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 1/27/12, Jacob Carlborg d...@me.com wrote: Tango is working find with D2: https://github.com/SiegeLord/Tango-D2 It wasn't the first place I went looking for an xml lib since this port is pretty new. But I did hear Tango's xml parser was blazing fast.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-01-27 12:21, Andrej Mitrovic wrote: On 1/27/12, Jacob Carlborgd...@me.com wrote: Tango is working find with D2: https://github.com/SiegeLord/Tango-D2 It wasn't the first place I went looking for an xml lib since this port is pretty new. But I did hear Tango's xml parser was blazing fast. Most of Tango is ported. I've ported one of my projects to D2 using Tango and it's all working fine. -- /Jacob Carlborg
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Wednesday, 25 January 2012 at 18:01:48 UTC, Zachary Lund wrote: I do not mind using a C library in D because of how straight forward it is. But simply mentioning C++ in D seems to add unneeded complexity which should be avoided. I think the answer to a question such as What's the alternative to Qt in D? should not be Qt bindings but maybe a library which imitates the implementation and/or interface of Qt UI widgets in native D. http://www.ohloh.net/p/qt/estimated_cost some scary numbers
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
What's the alternative to Qt in D? should not be Qt bindings but maybe a library which imitates the implementation and/or interface of Qt UI widgets in native D. http://www.ohloh.net/p/qt/estimated_cost some scary numbers http://www.ohloh.net/p/qt5 dmd could really learn a thing or two from them: http://www.ohloh.net/p/qt5/factoids/15415862 ;)
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
Kagamin wrote: On Wednesday, 25 January 2012 at 18:01:48 UTC, Zachary Lund wrote: I do not mind using a C library in D because of how straight forward it is. But simply mentioning C++ in D seems to add unneeded complexity which should be avoided. I think the answer to a question such as What's the alternative to Qt in D? should not be Qt bindings but maybe a library which imitates the implementation and/or interface of Qt UI widgets in native D. http://www.ohloh.net/p/qt/estimated_cost some scary numbers $300K for build scripts... and Mozilla paid almost 3 million for the same.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
Are the Clang C bindings complete? I imagine they don't get that much attention. It depends on what complete means. If you mean that you can do all the things you can do with the C++ API, then no. If you mean it's complete enough to implement this project, then I don't know. I think at least parts of the C bindings are added when someone needs it. Well I know from the llvm bindings that they aren't complete and it's not hard to guess they don't pay that much attention to them. Is it easy to use them? From what I've seen the llvm bindings don't quite follow the naming scheme of the C++ counterpart which makes it harder to find the appropriate functions.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-01-26 13:24, Trass3r wrote: Are the Clang C bindings complete? I imagine they don't get that much attention. It depends on what complete means. If you mean that you can do all the things you can do with the C++ API, then no. If you mean it's complete enough to implement this project, then I don't know. I think at least parts of the C bindings are added when someone needs it. Well I know from the llvm bindings that they aren't complete and it's not hard to guess they don't pay that much attention to them. I think they pay quite much attention to the bindings. I mean Apple uses it in Xcode (at least I think it's the C bindings and not the C++ code) and the C bindings are much more API stable compared to the C++. Is it easy to use them? From what I've seen the llvm bindings don't quite follow the naming scheme of the C++ counterpart which makes it harder to find the appropriate functions. It seems fairly straightforward, I've just started to use the bindings. I'm not sure how the LLVM bindings work but these bindings for Clang are more of a C library built on top of the C++ code than actual bindings. You don't even link with the same library. Instead of linking to libclangSema, libclangAST and so on you just link to libclang. -- /Jacob Carlborg
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 01/25/2012 01:38 PM, Andrej Mitrovic wrote: The Json parsing I've initially attempted was a mistake. I've assumed the XML parsing would be harder than necessary, but I ended up fighting wxPhp's arbitrary Json output (arrays holding objects of different types.. which is no good for D, or my sanity). Yesterday I've started working on xml parsing instead (using Vladimir Panteelev's xml library) and now I have a full script that parses wx doxygen files in pretty much the same way as the wxPhp script (although the syntax is much nicer to work with). I'm now in the process of testing the entire output to verify that I've parsed the xml files correctly and loaded all the info in the same way as wxPhp's xml script (basically I'm going to do some printf diffs). Once that is done I can begin working on porting the source_maker script (obviously I can skip the Json part altogether since I have the structures in memory already). Andrej, I can't await your SUCCESS message. For me your upcoming code is the most important stuff since years. A few questions : where do I find Vladimir Panteelev's XML library ? Does this library support XPATH ? Maybe it's too early but what do you think about replacing wxEvent with a D solution ? I think about something similar to DGUI's event framework. Same is valid for the wxWidgets sizer framework. Enough now... Just want to say: Thanks man !
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Thursday, 26 January 2012 at 15:13:57 UTC, bls wrote: Andrej, I can't await your SUCCESS message. For me your upcoming code is the most important stuff since years. A few questions : where do I find Vladimir Panteelev's XML library ? Does this library support XPATH ? I don't know anything about Vladimir's parser, I've just been using xmlp, which has xpath though I have have not used. Xmlp has gone through some breaking changes recently as I've been submitting bugs. http://www.dsource.org/projects/xmlp/browser/trunk/std
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Thursday, January 26, 2012 19:44:18 Jesse Phillips wrote: On Thursday, 26 January 2012 at 15:13:57 UTC, bls wrote: Andrej, I can't await your SUCCESS message. For me your upcoming code is the most important stuff since years. A few questions : where do I find Vladimir Panteelev's XML library ? Does this library support XPATH ? I don't know anything about Vladimir's parser, I've just been using xmlp, which has xpath though I have have not used. Xmlp has gone through some breaking changes recently as I've been submitting bugs. http://www.dsource.org/projects/xmlp/browser/trunk/std xmlp is the one that Tomaz is working on to replace std.xml, correct? Any idea how close it is to actually being submitted for review? - Jonathan M Davis
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 1/26/12, bls bizp...@orange.fr wrote: A few questions : where do I find Vladimir Panteelev's XML library ? https://github.com/CyberShadow/ae/blob/master/utils/ (see xml.d) Does this library support XPATH ? I'm not sure. It's a light-weight library, you're probably not going to see libxml2 features in there. Maybe it's too early but what do you think about replacing wxEvent with a D solution ? I think it's too early for that, but I know it would be nice to have something D-like for events. We'll see later. Anyway, the XML parsing script is done and I've verified it has the same output as the php script. This thing parsed about 1400 xml files, so I don't see any issues with parsing doxygen xml files with a lightweight xml lib, at least not for wxWidgets. The next step is to port the generator scripts. I'll make updates as progress continues.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Thursday, 26 January 2012 at 19:02:30 UTC, Jonathan M Davis wrote: xmlp is the one that Tomaz is working on to replace std.xml, correct? Any idea how close it is to actually being submitted for review? - Jonathan M Davis Michael Rynn, no I don't know what Tomaz is up to. Maybe some form of contact information should be given on the ReviewQueue. I'll send an email to Michael about this discrepancy as I didn't notice this before. As for xmlp and its progress. I can't really say either. It seems he started using a custom hashmap implementation which probably doesn't jive with being included in Phobos. Organizational work would probably need to be done, it isn't flat which may or may not be good for Phobos.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Thu, 26 Jan 2012 23:18:10 +0100, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 1/26/12, bls bizp...@orange.fr wrote: A few questions : where do I find Vladimir Panteelev's XML library ? https://github.com/CyberShadow/ae/blob/master/utils/ (see xml.d) Does this library support XPATH ? I'm not sure. It's a light-weight library, you're probably not going to see libxml2 features in there. Maybe it's too early but what do you think about replacing wxEvent with a D solution ? I think it's too early for that, but I know it would be nice to have something D-like for events. We'll see later. Anyway, the XML parsing script is done and I've verified it has the same output as the php script. This thing parsed about 1400 xml files, so I don't see any issues with parsing doxygen xml files with a lightweight xml lib, at least not for wxWidgets. The next step is to port the generator scripts. I'll make updates as progress continues. It is not clear what you do not use xml in tango library. Regards Marton Papp
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 1/27/12, equi...@atw.hu equi...@atw.hu wrote: It is not clear what you do not use xml in tango library. I'm using D2, not D1.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 01/25/2012 09:07 AM, Trass3r wrote: Whats.necessary to use D in order to create C++ bindings ? github.com/jacob-carlborg/dstep Quote DStep is a tool for converting C and Objective-C headers to D modules. Well THAT'S nitty gritty :) C++ as well ? How ? And maybe the most imp[ortant point when ? Don't get me wrong Jacob. In case that dstep is working perfect for C++ hallelujah. (I am nevertheless convinced that porting from XML output has several advantages. Multi pass code generation. Bjoern - Slightly Off Topic DWT (Keinfarbton) f.i. was born on a idea of mine. Frank and I have discussed the idea of using Java2XML (ANTLR based) to generate D code )
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
Whats.necessary to use D in order to create C++ bindings ? github.com/jacob-carlborg/dstep
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 01/25/2012 11:41 AM, bls wrote: On 01/25/2012 09:07 AM, Trass3r wrote: Whats.necessary to use D in order to create C++ bindings ? github.com/jacob-carlborg/dstep Quote DStep is a tool for converting C and Objective-C headers to D modules. Well THAT'S nitty gritty :) C++ as well ? How ? And maybe the most imp[ortant point when ? Don't get me wrong Jacob. In case that dstep is working perfect for C++ hallelujah. (I am nevertheless convinced that porting from XML output has several advantages. Multi pass code generation. Bjoern - Slightly Off Topic DWT (Keinfarbton) f.i. was born on a idea of mine. Frank and I have discussed the idea of using Java2XML (ANTLR based) to generate D code ) I'm going to be rather straight forward on my opinion and, possibly, my ignorance. I think C (or any language with no symbol mangling) is an ideal language to create a library which is usable globally in almost any language. I think C++ libraries are an ideal language to create a library which is going to be used only within the C++ community because of it's ill symbol mangling system. There is no right way to work with C++ in D and although there are ways to interface with C++, I do not think that is the ideal situation. That being said, libraries like wxWidgets are very large and have been acquired over several years of hardwork by a very large group. I do not think that a GUI toolkit library should have to bother with networking, sound, and so on. Also given the standard library D has, I think the GUI library D can provide should use Phobos extensively rather than its own mechanisms. I think the ideal situation is to have a native D library. Creating binds to a C++ library is only a temporary solution and is not ideal both in implementation and in usage. I do not mind using a C library in D because of how straight forward it is. But simply mentioning C++ in D seems to add unneeded complexity which should be avoided. I think the answer to a question such as What's the alternative to Qt in D? should not be Qt bindings but maybe a library which imitates the implementation and/or interface of Qt UI widgets in native D. Another problem this causes is the seemingly unneccessary time needed to develop such libraries. I kinda regret saying this but using a C library in an OOP wrapper can be optimal and easy to work with. Perhaps adding to GTK+ as a C library for functionality that we want would be more ideal than trying to mess with C++. I personally think the SIMD feature is much more important than trying to mess with C++.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 01/25/2012 10:01 AM, Zachary Lund wrote: On 01/25/2012 11:41 AM, bls wrote: On 01/25/2012 09:07 AM, Trass3r wrote: Whats.necessary to use D in order to create C++ bindings ? github.com/jacob-carlborg/dstep Quote DStep is a tool for converting C and Objective-C headers to D modules. Well THAT'S nitty gritty :) C++ as well ? How ? And maybe the most imp[ortant point when ? Don't get me wrong Jacob. In case that dstep is working perfect for C++ hallelujah. (I am nevertheless convinced that porting from XML output has several advantages. Multi pass code generation. Bjoern - Slightly Off Topic DWT (Keinfarbton) f.i. was born on a idea of mine. Frank and I have discussed the idea of using Java2XML (ANTLR based) to generate D code ) I'm going to be rather straight forward on my opinion and, possibly, my ignorance. I think C (or any language with no symbol mangling) is an ideal language to create a library which is usable globally in almost any language. I think C++ libraries are an ideal language to create a library which is going to be used only within the C++ community because of it's ill symbol mangling system. There is no right way to work with C++ in D and although there are ways to interface with C++, I do not think that is the ideal situation. That being said, libraries like wxWidgets are very large and have been acquired over several years of hardwork by a very large group. I do not think that a GUI toolkit library should have to bother with networking, sound, and so on. Also given the standard library D has, I think the GUI library D can provide should use Phobos extensively rather than its own mechanisms. I think the ideal situation is to have a native D library. Creating binds to a C++ library is only a temporary solution and is not ideal both in implementation and in usage. I do not mind using a C library in D because of how straight forward it is. But simply mentioning C++ in D seems to add unneeded complexity which should be avoided. I think the answer to a question such as What's the alternative to Qt in D? should not be Qt bindings but maybe a library which imitates the implementation and/or interface of Qt UI widgets in native D. Another problem this causes is the seemingly unneccessary time needed to develop such libraries. I kinda regret saying this but using a C library in an OOP wrapper can be optimal and easy to work with. Perhaps adding to GTK+ as a C library for functionality that we want would be more ideal than trying to mess with C++. I personally think the SIMD feature is much more important than trying to mess with C++. Thanks for the feedback. well, I think we have very different views. Unfortunately I am not a student anymore instead I am a unhappy tax payer. To fulfill my Job I need GUI,RIA(WEB), Database and XML(SOAP) support. To say the least. So pretty much everything D is not able to deliver atm. We are buying 3 party add ons in a few kilo bucks region and unfortunately we have to work with a Tool chain which is far away from being perfect. In other words the D language is already offering more than we need,could be an option, but the library situation is a disaster. wxWidgets. Do you really care about wrapped vs native library ? Do you think that the D community will ever be able to create a wxWidgets comparable native D lib. while not being able to spend some time in creating a binding generator ? I would be glad to have such bindings ! My 2 cents.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Wed, 25 Jan 2012 10:44:43 -0800 bls bizp...@orange.fr wrote: Unfortunately I am not a student anymore instead I am a unhappy tax payer. Same here. To fulfill my Job I need GUI,RIA(WEB), Database and XML(SOAP) support. I need GUI Database support, but not for the job, but for a kind-of hobby (open-source) project. In other words the D language is already offering more than we need,could be an option, but the library situation is a disaster. /mer nods wxWidgets. Do you really care about wrapped vs native library ? I don't. Do you think that the D community will ever be able to create a wxWidgets comparable native D lib. while not being able to spend some time in creating a binding generator ? i Not soon. I would be glad to have such bindings ! After researching a lot, I believe that wxWidgets is the best solution for multi-platform development and I'll try to help as much as possible those people trying to make it happen. Sinvcerely, Gour -- A self-realized man has no purpose to fulfill in the discharge of his prescribed duties, nor has he any reason not to perform such work. Nor has he any need to depend on any other living being. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-01-25 18:41, bls wrote: On 01/25/2012 09:07 AM, Trass3r wrote: Whats.necessary to use D in order to create C++ bindings ? github.com/jacob-carlborg/dstep Quote DStep is a tool for converting C and Objective-C headers to D modules. Well THAT'S nitty gritty :) C++ as well ? How ? And maybe the most imp[ortant point when ? I had no plans on supporting C++ but we'll see what happens. I don't know when. I have much of the implementation already done but that was as a modification to Clang, not as a separate tool. I'm trying to reimplement the code as a separate tool in D using the Clang C bindings. So far it's not working out that well, there's not much documentation available. Don't get me wrong Jacob. In case that dstep is working perfect for C++ hallelujah. (I am nevertheless convinced that porting from XML output has several advantages. Multi pass code generation. Bjoern - Slightly Off Topic DWT (Keinfarbton) f.i. was born on a idea of mine. Frank and I have discussed the idea of using Java2XML (ANTLR based) to generate D code ) -- /Jacob Carlborg
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-01-25 20:13, Jacob Carlborg wrote: On 2012-01-25 18:41, bls wrote: On 01/25/2012 09:07 AM, Trass3r wrote: Whats.necessary to use D in order to create C++ bindings ? github.com/jacob-carlborg/dstep Quote DStep is a tool for converting C and Objective-C headers to D modules. Well THAT'S nitty gritty :) C++ as well ? How ? And maybe the most imp[ortant point when ? I had no plans on supporting C++ but we'll see what happens. I don't know when. I have much of the implementation already done but that was as a modification to Clang, not as a separate tool. I'm trying to reimplement the code as a separate tool in D using the Clang C bindings. So far it's not working out that well, there's not much documentation available. BTW, this is what I've got so far, in a somewhat useable state: https://github.com/jacob-carlborg/clang -- /Jacob Carlborg
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 01/25/2012 11:06 AM, Gour wrote: After researching a lot, I believe that wxWidgets is the best solution for multi-platform development and I'll try to help as much as possible those people trying to make it happen. Sinvcerely, Gour Hi Gour thanks for the feedback, Indeed. wxWidgets in 2.9.3 has closed the gap to QT. (webkit, f.i.) The documentation is also very close to what QT has to offer thanks to Doxygen. We should not forget that wxWidget is offering support for the RibboBar. (not that I like it too much) I wonder how much sense it would make to port the PHP parser/codegenerator source (wxPHP) into python. At least it should result in : More readable code, xml instead of shitty json intermediate output for the D codegerator. Despite that , developing a GUI tool to browse/modify the xml files is a piece of cake in wxPython. Of couse I would be nice to use D. But the XML files are simply to big to do DOM parsing. XPATH is required. Last thing. BCDGEN is using libxml2 to generate D code. and BCDGen was the tool to created the libxml2 wrapper. Eat your own Dog food. Good! http://dsource.org/projects/bcd Bjoern
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Wed, 25 Jan 2012 11:26:34 -0800 bls bizp...@orange.fr wrote: wxWidgets in 2.9.3 has closed the gap to QT. (webkit, f.i.) The documentation is also very close to what QT has to offer thanks to Doxygen. Let's hope 3.0 will polish it even further. I wonder how much sense it would make to port the PHP parser/codegenerator source (wxPHP) into python. You mean instead of porting to D (work done by Andrej)? At least it should result in : More readable code, xml instead of shitty json intermediate output for the D codegerator. For what would you use XML output? Of couse I would be nice to use D. But the XML files are simply to big to do DOM parsing. XPATH is required. I believe that our needs for DOM/XPATH parsing are not so big. :-) Last thing. BCDGEN is using libxml2 to generate D code. and BCDGen was the tool to created the libxml2 wrapper. Eat your own Dog food. Whatever tool can be made to help bind wx would be great...and considering there are some bindings for Sqlite3 (which, anyway, shoould not be too hard), we'd be satisfied to plunge into D project. :-) Finally, I hope that those of us interested to see active wxD project will be be smart-enough working together to overcome NiH syndrome. ;) Sincerely, Gour -- Whatever action a great man performs, common men follow. And whatever standards he sets by exemplary acts, all the world pursues. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
The Json parsing I've initially attempted was a mistake. I've assumed the XML parsing would be harder than necessary, but I ended up fighting wxPhp's arbitrary Json output (arrays holding objects of different types.. which is no good for D, or my sanity). Yesterday I've started working on xml parsing instead (using Vladimir Panteelev's xml library) and now I have a full script that parses wx doxygen files in pretty much the same way as the wxPhp script (although the syntax is much nicer to work with). I'm now in the process of testing the entire output to verify that I've parsed the xml files correctly and loaded all the info in the same way as wxPhp's xml script (basically I'm going to do some printf diffs). Once that is done I can begin working on porting the source_maker script (obviously I can skip the Json part altogether since I have the structures in memory already).
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
I'm trying to reimplement the code as a separate tool in D using the Clang C bindings. So far it's not working out that well, there's not much documentation available. Are the C bindings complete? I imagine they don't get that much attention.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
Whats.necessary to use D in order to create C++ bindings ? I forgot SWIG.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 01/25/2012 12:44 PM, bls wrote: On 01/25/2012 10:01 AM, Zachary Lund wrote: On 01/25/2012 11:41 AM, bls wrote: On 01/25/2012 09:07 AM, Trass3r wrote: Whats.necessary to use D in order to create C++ bindings ? github.com/jacob-carlborg/dstep Quote DStep is a tool for converting C and Objective-C headers to D modules. Well THAT'S nitty gritty :) C++ as well ? How ? And maybe the most imp[ortant point when ? Don't get me wrong Jacob. In case that dstep is working perfect for C++ hallelujah. (I am nevertheless convinced that porting from XML output has several advantages. Multi pass code generation. Bjoern - Slightly Off Topic DWT (Keinfarbton) f.i. was born on a idea of mine. Frank and I have discussed the idea of using Java2XML (ANTLR based) to generate D code ) I'm going to be rather straight forward on my opinion and, possibly, my ignorance. I think C (or any language with no symbol mangling) is an ideal language to create a library which is usable globally in almost any language. I think C++ libraries are an ideal language to create a library which is going to be used only within the C++ community because of it's ill symbol mangling system. There is no right way to work with C++ in D and although there are ways to interface with C++, I do not think that is the ideal situation. That being said, libraries like wxWidgets are very large and have been acquired over several years of hardwork by a very large group. I do not think that a GUI toolkit library should have to bother with networking, sound, and so on. Also given the standard library D has, I think the GUI library D can provide should use Phobos extensively rather than its own mechanisms. I think the ideal situation is to have a native D library. Creating binds to a C++ library is only a temporary solution and is not ideal both in implementation and in usage. I do not mind using a C library in D because of how straight forward it is. But simply mentioning C++ in D seems to add unneeded complexity which should be avoided. I think the answer to a question such as What's the alternative to Qt in D? should not be Qt bindings but maybe a library which imitates the implementation and/or interface of Qt UI widgets in native D. Another problem this causes is the seemingly unneccessary time needed to develop such libraries. I kinda regret saying this but using a C library in an OOP wrapper can be optimal and easy to work with. Perhaps adding to GTK+ as a C library for functionality that we want would be more ideal than trying to mess with C++. I personally think the SIMD feature is much more important than trying to mess with C++. Thanks for the feedback. well, I think we have very different views. Unfortunately I am not a student anymore instead I am a unhappy tax payer. To fulfill my Job I need GUI,RIA(WEB), Database and XML(SOAP) support. To say the least. So pretty much everything D is not able to deliver atm. We are buying 3 party add ons in a few kilo bucks region and unfortunately we have to work with a Tool chain which is far away from being perfect. In other words the D language is already offering more than we need,could be an option, but the library situation is a disaster. wxWidgets. Do you really care about wrapped vs native library ? Do you think that the D community will ever be able to create a wxWidgets comparable native D lib. while not being able to spend some time in creating a binding generator ? I would be glad to have such bindings ! My 2 cents. You misunderstood or did not read my entire post. I claimed messing with C++ was not productive. I did not claim we couldn't or shouldn't wrap over a library and even suggested we use a modified version of GTK+ for such a thing. I said writing a native D library was ideal. I did not say it was the most effecient method. I think working into playing with C++ libraries is asking for trouble and more man-time that it's worth. You seem to indicate that I meant otherwise.
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On Wed, 25 Jan 2012 22:38:58 +0100 Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Hello Andrej, Yesterday I've started working on xml parsing instead (using Vladimir Panteelev's xml library) and now I have a full script that parses wx doxygen files in pretty much the same way as the wxPhp script (although the syntax is much nicer to work with). You're my hero!!! I'm now in the process of testing the entire output to verify that I've parsed the xml files correctly and loaded all the info in the same way as wxPhp's xml script (basically I'm going to do some printf diffs). I am swamped with some other work with these days, but when you'll have something to share, I'd like to help by, at least, some testing. Once that is done I can begin working on porting the source_maker script (obviously I can skip the Json part altogether since I have the structures in memory already). Thanks to you, it looks as D community could get nice bindings to do real GUI programming, thank you very much. Sincerely, Gour -- As fire is covered by smoke, as a mirror is covered by dust, or as the embryo is covered by the womb, the living entity is similarly covered by different degrees of this lust. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.
On 2012-01-25 22:38, Trass3r wrote: I'm trying to reimplement the code as a separate tool in D using the Clang C bindings. So far it's not working out that well, there's not much documentation available. Are the C bindings complete? I imagine they don't get that much attention. It depends on what complete means. If you mean that you can do all the things you can do with the C++ API, then no. If you mean it's complete enough to implement this project, then I don't know. I think at least parts of the C bindings are added when someone needs it. -- /Jacob Carlborg
