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 <martindeme...@gmail.com> 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>
------------------------------------------------------------------------------
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
