Fwd: GSOC 2014 - Haskell UNO Language Binding
tmtlakmal at gmail.com
Wed Mar 19 07:08:35 PDT 2014
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.
On Wed, Mar 19, 2014 at 4:54 PM, Stephan Bergmann <sbergman at 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
>> 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
>> 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?
*Department of Computer Science and Engineering,*
*University of Moratuwa,*
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LibreOffice