Hi. I'm currently working on some bug fixes. I prepared my plan for the the project. Please add your comments for the proposal On Wed, Mar 19, 2014 at 7:38 PM, Tharindu Lakmal <tmtlakmal@gmail.com>wrote:
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 <sbergman@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.*
-- *Lakmal Muthugama,* *Undergraduate,* *Department of Computer Science and Engineering,* *University of Moratuwa,* *Sri Lanka.*
Attachment:
GSOC Proposal - Haskell UNO Language Binding.pdf
Description: Adobe PDF document