Thanks for the comment.. I'm working on bug fixes and trying to upload a patch asap.
My LibreOffice Plugin was not a fully tested or a better formatted one. It was done as an experiment. It's repository was a mess with many gibberish. I added the important files into a separate repository. old one - https://github.com/tmtlakmal/EasyTuteLO new one - https://github.com/tmtlakmal/EasyTuteLibreOffice I'm working on a Haskell implementation and will send you a working code before the selection process ends up. Regards On Wed, Mar 19, 2014 at 4:54 PM, Stephan Bergmann <sberg...@redhat.com>wrote: > On 03/19/2014 10:44 AM, Tharindu Lakmal wrote: > >> I'm Lakmal From University of Moratuwa, Sri Lanka. I like to contribute >> for the topic Haskell UNO Language Binding. I'm looking for a mentor for >> the project. >> >> I read about your description about the project and browsed through many >> details around the topic. I had written a libreoffice plugin a few >> months ago using pyuno. It made me easier to find the details about UNO >> bindings. >> >> I like to get some advice from you about 1 st and third options. >> >> As I got to know, FFI doesn't provide direct support for C++, but >> there exist many code generators and methods to do that. >> >> The following links added me another option to call pyuno library >> through Haskell. Better if I can get an opinion on that >> >> http://www.haskell.org/haskellwiki/Cxx_foreign_function_interface >> https://john-millikin.com/articles/ride-the-snake/ >> >> By the way I would like to get some opinion about pros and cons of >> option 1(FFI) and 3(Remote Protocol). >> >> I'll prepare the proposal asap and get your feedback also. >> > > Hi Lakmal, > > Great to see you interested in this topic. A few notes: > > * Doing a UNO Remote Protocol (URP) bridge might be easier than an FFI > bridge in that you do that in an external, purely Haskell process (and the > documentation of URP might be somewhat better than the documentation of > Binary UNO, which you need to interface with in the FFI case). In the end, > a "real" UNO binding would support both, but it would of course be fine to > concentrate on one of them, at least initially. > > * FFI being C rather than C++ should not be a problem, as the Binary UNO > code that it needs to interact with is just C (although partially > implemented in C++). (One UNO concept is the "Binary UNO hub" that bridges > between different language bindings, which each provide a bridge between > that language binding and Binary UNO, so if e.g., some C++ code calls a UNO > method implemented in Java, that call goes via the C++-to-Binary-UNO and > then via the Binary-UNO-to-JNI bridge.) > > * You mention Python, but I wouldn't make a bridge between Haskell and > PyUNO, but rather between Haskell and Binary UNO. I see no advantage in > the former, just more layers of indirection that complicate matters. > > * Great to read you already did a LO plugin. Is the code available > somewhere to have a look at it? > > * To be eligible for LO GSoC, you'd need to do some Easy Hacks first. > > * Do you also have experience with Haskell itself? > > Stephan > -- *Lakmal Muthugama,* *Undergraduate,* *Department of Computer Science and Engineering,* *University of Moratuwa,* *Sri Lanka.*
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
