Fwd: GSOC 2014 - Haskell UNO Language Binding

[Tharindu Lakmal]

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 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
>> 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.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20140319/5ca387df/attachment.html>