August 25, 2006
Okey,

here the problems then started.. it is much more difficult and I can see it now when I got to test it. Must modify almost everything manually and it is really difficult. Bcd generated code was ugly and unreadable, my experience is not so professional.. so it was enough for me. It is huge project.

But I learned something at least..


unknown kirjoitti:
> All problems solved / go around so far.
> 
> - removed some templates (vector3d<T> => vector3df, vector3di, etc.)
> 
> - added CXXFLAGS="-D __BCD_GEN__" to ignore problematic code (for example inner structs/unions (not only anonymous as I first said) and some templates )
> 
> - made script that searches and replaces some code after generation (for example namespaves ./replace_in_file ${i} " core::"  " irr::core::")
> 
> I try to automate as much as possible.
> 
> Now I got it compiled and next try example app. See how/if/what works and what not and what can be done.
> 
> Sorry, I have polluted wrong mailing list.
> Maybe I'll be back at the bcd forum at dsource.
> 
> 
> 
> unknown kirjoitti:
>> Hi,
>> no pressure..
>>
>> do you have solution for anonymous union/structs? Can't use -N option to just for now ignore, because they are anonyous, or can I?
>>
>> For example in SMaterial.h:
>> union {
>>     struct {
>>         ITexture* Texture1;
>>         ITexture* Texture2;
>>         ITexture* Texture3;
>>         ITexture* Texture4;
>>     };
>>     ITexture* Textures[MATERIAL_MAX_TEXTURES];
>> };
>>
>> Problem is that it generates illagel code in SMaterial.cc and SMaterial.d, like:
>>
>> void set_Texture1(ITexture * x) {
>> _BCD_set__ZN3irr5video9SMaterial4._104._118Texture1E(__C_data, x);
>> }
>>
>> There are lot of things irrlicht brings surface, that I think are quite common and not impossible to solve.
>>
>> Thanks
>>
>>
>> Gregor Richards kirjoitti:
>>> Sorry I haven't responded yet, I've been busy with other projects.  I'll try to help out ASAP.
>>>
>>>  - Gregor Richards
>>>
>>>
>>> unknown wrote:
>>>> Hi!
>>>>
>>>> I try to work on Irrlicht..
>>>>
>>>> So I got all files generated, except one not important I could exclude (propably much more files could be excluded)
>>>>
>>>> But then for example vecror3d is template class so it needs to be worked on.. so I add option -Tvector3d to the command, which is now:
>>>> ./bcdgen $1/${i}.h irrlicht -I/home/me/D/bcd/irrlicht-1.1/include/ -r -E -P -DV -Tvector3d -Tvector2d
>>>>
>>>> Get output:
>>>> vector2d
>>>> In file included from <command line>:88:
>>>> bcd/irrlicht/template_D.h:3: error: 'vector3d' is used as a type, but is not defined as a type.
>>>> bcd/irrlicht/template_D.h:4: error: 'vector2d' is used as a type, but is not defined as a type.
>>>> vector3d
>>>> In file included from <command line>:88:
>>>> bcd/irrlicht/template_D.h:3: error: 'vector3d' is used as a type, but is not defined as a type.
>>>> bcd/irrlicht/template_D.h:4: error: 'vector2d' is used as a type, but is not defined as a type.
>>>>
>>>>
>>>> template_d.h:
>>>> #include "../bind.h"
>>>> #include "/home/me/D/bcd/irrlicht-1.1/include/vector3d.h"
>>>> vector3d<DReflectedClass> __IGNORE_vector3d;
>>>> vector2d<DReflectedClass> __IGNORE_vector2d;
>>>>
>>>> Also template_D.h seems to be regenerated for every header, so it includes only vector3d.h.. I am not very experienced..
>>>>
>>>> maybe better idea to remove templates by duplicating the template class to two separate classes vector3df and vector3di? They are typedefed anyway there..
>>>> typedef vector3d<f32> vector3df;
>>>> typedef vector3d<s32> vector3di;
>>>>
>>>> Thanks.
>>>>
>>>> Gregor Richards kirjoitti:
>>>>
>>>>> I made an attempt at OGRE, which was unfortunately not very successful, because OGRE makes heavy use of the STL :(
>>>>>
>>>>>  - Gregor Richards
>>>>>
>>>>>
>>>>> unknown wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> I do not think it is competing too much. Native gui is necessary and important for D to collect momentum. Momentum brings more native work.
>>>>>>
>>>>>> But seems many ports to native D are started and then cancelled (no time, no interest, no people), so I see bcd very necessary.
>>>>>>
>>>>>> I did not know bcd. I am interested if binding to 3d engine like Irrlich, Ogre or similar could be generated. I might give it a try.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Gregor Richards kirjoitti:
>>>>>>
>>>>>>> I hate to compete with the far more compelling FLTK-port-to-D thread, but I don't think many people know about this, and it's definitely useful.  There are FLTK2 bindings in D, autogenerated by bcd.gen ( http://www.dsource.org/projects/bcd/ ).  Since they're generated automatically, they have very nearly the exact same API as the native C++ ones, PLUS they're easy to keep up to date (if they become incompatible, I can just run the script again and bring them up to date).
>>>>>>>
>>>>>>> They're available in SVN, info on checking them out is on the BCD web page ( http://www.dsource.org/projects/bcd/ ).
>>>>>>>
>>>>>>> Finally: These bindings have been partially but not completely tested. If you find a problem, it can probably be solved quite easily, in most cases it's a discrepancy between the FLTK2 .h files and .cxx files (naughty naughty).  Just tell me by some means (NG, email, whatever).
>>>>>>>
>>>>>>>  - Gregor Richards
December 05, 2006
Can't the same be done with wxWidgets?

Gregor Richards wrote:
> I hate to compete with the far more compelling FLTK-port-to-D thread, but I don't think many people know about this, and it's definitely useful.  There are FLTK2 bindings in D, autogenerated by bcd.gen ( http://www.dsource.org/projects/bcd/ ).  Since they're generated automatically, they have very nearly the exact same API as the native C++ ones, PLUS they're easy to keep up to date (if they become incompatible, I can just run the script again and bring them up to date).
> 
> They're available in SVN, info on checking them out is on the BCD web page ( http://www.dsource.org/projects/bcd/ ).
> 
> Finally: These bindings have been partially but not completely tested. If you find a problem, it can probably be solved quite easily, in most cases it's a discrepancy between the FLTK2 .h files and .cxx files (naughty naughty).  Just tell me by some means (NG, email, whatever).
> 
>  - Gregor Richards
December 05, 2006
bobef wrote:
> Gregor Richards wrote:
>> I hate to compete with the far more compelling FLTK-port-to-D thread, but I don't think many people know about this, and it's definitely useful.  There are FLTK2 bindings in D, autogenerated by bcd.gen ( http://www.dsource.org/projects/bcd/ ).  Since they're generated automatically, they have very nearly the exact same API as the native C++ ones, PLUS they're easy to keep up to date (if they become incompatible, I can just run the script again and bring them up to date).
>>
>> They're available in SVN, info on checking them out is on the BCD web page ( http://www.dsource.org/projects/bcd/ ).
>>
>> Finally: These bindings have been partially but not completely tested. If you find a problem, it can probably be solved quite easily, in most cases it's a discrepancy between the FLTK2 .h files and .cxx files (naughty naughty).  Just tell me by some means (NG, email, whatever).
>>
>>  - Gregor Richards
> Can't the same be done with wxWidgets?
> 

Not at this time. wxWidgets does some mighty funky things with C++'s lame ripoff of delegates, and those are 1) not consistent between compilers and 2) a black box, so there's no easy way to translate them to D.

 - Gregor Richards
December 06, 2006
What about FOX then :)


Gregor Richards wrote:
> bobef wrote:
>> Gregor Richards wrote:
>>> I hate to compete with the far more compelling FLTK-port-to-D thread, but I don't think many people know about this, and it's definitely useful.  There are FLTK2 bindings in D, autogenerated by bcd.gen ( http://www.dsource.org/projects/bcd/ ).  Since they're generated automatically, they have very nearly the exact same API as the native C++ ones, PLUS they're easy to keep up to date (if they become incompatible, I can just run the script again and bring them up to date).
>>>
>>> They're available in SVN, info on checking them out is on the BCD web page ( http://www.dsource.org/projects/bcd/ ).
>>>
>>> Finally: These bindings have been partially but not completely tested. If you find a problem, it can probably be solved quite easily, in most cases it's a discrepancy between the FLTK2 .h files and .cxx files (naughty naughty).  Just tell me by some means (NG, email, whatever).
>>>
>>>  - Gregor Richards
>> Can't the same be done with wxWidgets?
>>
> 
> Not at this time. wxWidgets does some mighty funky things with C++'s lame ripoff of delegates, and those are 1) not consistent between compilers and 2) a black box, so there's no easy way to translate them to D.
> 
>  - Gregor Richards
1 2
Next ›   Last »