Thanks for fleshing this out!
Your characterisation of wxc/wxdirect sounds better. Can't claim to be new at
this myself, but it's been a while.
In the absence of a response from the devs, I would suggest not waiting for a
blessing and going ahead and modifying wxdirect if working from the json for
the macro view of the *.h files any easier. You lose nothing from it (well,
time, but time that would be spent anyway doing the equivalent pre-processing
yourself) and you potentially make life easier for others in the process.
Only thing I might be nervous about is making wxdirect depend on libraries that
don't ship with the Haskellp platform (presumably something like aeson) because
I'm not sure what the implications would be for expressing pkg dependencies
(when the deps are used for Setup.hs and not the program itself). In the worst
case though, you could turn wxdirect into a library and make tool that depends
on it.
Would be curious to see how wxOcaml dealt with the same situation, if they just
up and parsed our header/macros.
It could also be a good way to become for familiar with wxdirect/wxc.
Thanks!
Eric
On 4 November 2013 at 08:13:26, Martin DeMello (martindeme...@gmail.com) wrote:
>
>Hi Eric
>
>I'm new to this too, so I could be wrong, but this is how I understand
>the hierarchy of layers:
>
>* C++ wxWidgets
>* wxc: hand-rolled C wrapper code + header files + macros indicating
>the types that get erased by the C layer
>* wxdirect: "type-aware" header file parser that uses the macros
>within the wxc headers to set up a strongly-typed haskell layer
>corresponding to the original C++ code
>* a few more haskell-specific layers, as you note.
>
>According to the wxHaskell project, the point of doing it this way
>was, in part, to let other languages use the wxc layer as well. Now
>what wxRust etc. would need to do is:
>
>1. Write a low-level binding generator that preprocesses the wxc/*.h
>files, gets rid of the macros etc. and generates direct 1-1 bindings
>to the C functions (fairly straightforward using something like swig
>or the language-specific equivalent; doesn't depend on the specifics
>of the wxc project in any way)
>2. Parse the macro view of wxc/*.h to generate a higher-level
>(strongly typed, object oriented, etc) layer that more closely
>corresponds to the original c++ code, and calls the low-level bindings
>internally.
>
>For instance
>
>TClass(wxPoint) wxListCtrl_GetItemPosition2( TSelf(wxListCtrl) _obj, int item
>);
>
>would become after preprocessing
>
>void* wxListCtrl_GetItemPosition2(void* _obj, int item);
>
>which in the bindings would generate the corresponding low level function
>
>c_voidptr wxListCtrl_GetItemPosition2(c_voidptr _obj, cint item);
>
>and which would be wrapped by (pseudocode)
>
>class wxListCtrl {
>wxPoint GetItemPosition2(int item) {
>cast(cast self, item);
>}
>}
>
>One problem is that generating this higher level layer from the header
>files is essentially repeating whatever wxdirect does, in every
>language. My idea was that wxdirect be modified to add a -json flag,
>which rather than generating .hs files generates a json view of the
>in-memory data structures it has assembled in the process of parsing
>the files, and that the .json files then be checked in somewhere under
>wxc/. (I'd be willing to contribute the -json flag to wxdirect myself,
>but it'd take me a while; I figured someone already familiar with the
>project could do it in a few hours). That would let other languages
>have an exact idea of the class and method hierarchy, and whether
>method arguments are in, out or in/out, without having to
>independently deduce the information.
>
>In the long run it would be great if wxRust, wxOcaml etc. started
>contributing back to wxc, but to start off I was proposing the simpler
>step of at least building on rather than duplicating the work that
>wxHaskell is doing.
>
>Thanks for the pointer to the wxOcaml reloaded post too; I'd missed
>that. It looks like they're already thinking in terms of starting from
>the original C++ code and generating the C wrappers automatically.
>
>martin
>
>On Sun, Nov 3, 2013 at 9:58 PM, Eric Kow wrote:
>> Hello!
>>
>> First, do you know about the work on wxOcaml?
>> http://www.ocamlpro.com/blog/2013/04/02/wxocaml-reloaded.html
>>
>> Thought it would be good if wxHaskell, wxOcaml, and wxRust made a
>> deliberate point of working together on a single wxC project. (and
>> before anyone suggests autogenerating wxc from wxWidgets via Doxygen,
>> yes, that sounds awesome! but maybe we should still try to pool
>> resources first and then worry about getting wxc done the right way
>> instead of getting stuck salivating over an ideal)
>>
>> As for the proposal itself, sorry I don't really understand it, but
>> I'm not working on wxHaskell much so this is really a question for the
>> not-really-wxHaskell devs like me. Could you remind those of us how
>> things fit together? Do I have this right?
>>
>> * C++ wxWidgets
>> * wxc: Hand-rolled C++ to C wrapper code + header files
>> * wxdirect: utility that parses .h files written using wxc conventions
>> and generates generates Haskell FFI layer code to call the
>> corresponding (wx)C functions
>> * wxcore: autogenerated code via wxdirect (wxc/src/include/*.h =>
>> wxcore/something/.*hs) + some handwritten Haskell
>> * wx: less low-level Haskell code on top of wxcore
>>
>> If so, are you proposing to replace wxc/src/cpp/*.cpp with something
>> like json? That's what your example looks like. I'm a bit confused
>> because I thought it was the effort of parsing of the header files you
>> wanted to avoid duplicating? Would it be possible to autogenerate
>> both the .cpp and the header files from this data structure?
>>
>> Sorry to be dense, and thanks!
>> (I'm guessing your mail only showed up this late because it was caught
>> in the mailman spam filter?)
>>
>>
>> On 9 October 2013 08:06, Martin DeMello wrote:
>>> Hi,
>>>
>>> I'm working on rust bindings to wx, based on the (wonderful!) wxc
>>> layer exposed by wxhaskell. When starting on the wxdirect equivalent,
>>> it struck me that it was wasteful for everyone to be parsing the .h
>>> files - instead, wxc could consist of both the header files and some
>>> sort of serialised data structure (e.g. json):
>>>
>>> C file:
>>>
>>> TClassDefExtend(wxTimerEx,wxTimer)
>>> void wxTimerEx_Connect( TSelf(wxTimerEx) _obj,
>>> TClass(wxClosure) closure );
>>> TClass(wxTimerEx) wxTimerEx_Create( );
>>> TClass(wxClosure) wxTimerEx_GetClosure( TSelf(wxTimerEx) _obj );
>>>
>>> parsed data:
>>>
>>> class: wxTimerEx
>>> parent: wxTimer
>>> methods: [
>>> { c_fn: wxTimerEx_Connect
>>> name: Connect
>>> return_type: void
>>> args: [[wxClosure, closure]]
>>> },
>>> ...
>>> ]
>>>
>>> What do you think? Would this add an unnecessary extra burden? I
>>> figure the data structure is in memory at some point anyway, so
>>> dumping it to a file shouldn't be too much of a problem.
>>>
>>> martin
>>>
>>> ------------------------------------------------------------------------------
>>> Android is increasing in popularity, but the open development platform that
>>> developers love is also attractive to malware creators. Download this white
>>> paper to learn more about secure code signing practices that can help keep
>>> Android apps secure.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> wxhaskell-devel mailing list
>>> wxhaskell-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>>
>>
>>
>> --
>> Eric Kow
>
--
http://erickow.com
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
