2012/3/28 Mikel Artetxe <artet...@gmail.com>
>
>> If you really really want to make a GUI on this, fine, OK. But I'd
>> expect it to not been usen very often and I'd only spend limited time on
>> it. And as command line script for group 1) I think a makefile/shell script
>> is more adequate.
>>
>
> Now I really understand you and you have definitely convinced me. So yes,
> it is going to be better to forget about my GUI idea and work on a command
> line tool. The utility proposed by Jimmy seems very interesting in that
> respect. The only problem that I see is that I have never worked with Ant
> (and my experience with makefiles and so is also quite little), so this
> would be something new for me. Would this suppose a big difficulty? I mean,
> I would be reading documentation and working hard to learn about it, but my
> lack of experience could perhaps be a problem... What do you think about it?
>
Its no problem.
People around here would probably prefer a makefile anyway and while jarjar
look cool we probably wont need anything beyond ZIP.
I actually also have limitied knowledge on writing ant stuff. I can type
'ant' and compile and thats it.
>
>>> By the way, getting the different libraries that Apertium C++ is
>>> dependent on included in an iOS app is not too complicated. In fact, I
>>> successfully got to compile apertium for iOS solving all the dependencies.
>>> Everything worked correctly in my prototype app up to the transfer step, in
>>> which something was failing (the translations that it was giving were empty
>>> strings, and I wasn't able to find out why).
>>>
>>
>> That sounds great!
>>
>> I'd suggest that we put aside some time to diverge a little from
>> lttoolbox-java and see if we can embed lttoolbox as well.
>>
>
> Great! Let's take about 2 weeks for it. Is that OK?
>
Thats great.
I wont be of much help on the task (apart from the UNIX stuff) but probably
theres other out there.
BTW I feel that stuff like getting help, contacting other devs, perhaps
even make them work on something, is really also part of the open source
work, and therefore I feel that such parts also creditable GSoC work (as
long as the main stuff is still coding).
>
> Just mention that the main problem that I found when working on the iOS
> prototype was the fact that there were several duplicated symbols. For
> instance, each program (ltproc, interchunk, postchunk and so on) has
> logically a main function but, since iOS apps must consist of a single
> executable, their names collide when putting them together. The solution
> that I adopted was simply to rename them. Because of that, I sort of
> hardcoded the pipeline for a single language pair, using temporary files to
> communicate between the different stages of the translation. And, as I said
> before, the transfer stage wasn't working, but I couldn't find out why.
>
Cant help thinking about that the C++ transfer is an interpreter. At some
point in time interpreters were forbidden by Apple, though I think they
relaxed that bit. Unless Steve has gotten paraphysic power after he passed
this shouldnt be linked to your current problem.
The Java ports doesent have the interpreter step (therefore transfer is
faster), but here is instead a requirement that language pairs contain
compiled bytecode. You could convert that bytecode to objective-C with
xmlvm.org. Ive got it all installed and could send you some sample
objective-C from bytecode.
Overall, make sure that your port can be published in Apples store.
> My own experiences are with Android and I am in general biased towards
>> open source platforms (and I would be unable to mentor iOS stuff). One
>> could probably argue endlessly about each platform's qualities etc.
>>
>
> I don't defend that iOS is better than Android, I think that both are
> incredible platforms. And I also prefer Android's open philosophy rather
> than Apple's strict control. If I have focused on iOS it is because I have
> experience with it since I am currently involved in an iOS project
> (actually, it is a language learning app!) along with a partner that had
> this preference, but we also have the intention to work for other platforms.
>
Cool. If its open source you are welcome to use me to mentor/repair the
Android code.
> So this would be my new work plan:
>
> - Week 1-3: Adapt lttoolbox-java so that it can directly work with
> embedded files without the need of copying them to a temporary directory.
> - Week 3-4: Make an API class that easily allows the translation of an
> embedded language pair. Work on a demo JAR executable usable from the
> command line that would make use of it with a specific language pair. Time
> permitting, work on an API class that allows access to the intermediary
> translation stages.
>
Just one week on API should suffice here.
Add here 'Decide together with the Apertium organization on how to organize
easy download of precompiled langugage pairs for users (SF, website,
something else) and easy maintenance for developers
(makefile/script/something) and implement what's decided'.
> - Deliverable #1: The above mentioned JAR executable.
> - Week 5: Work on a command line tool to easily create and maintain JARs
> for each of the language pairs.
> - Week 6: Make a small user-oriented Swing application for translation
> (something similar to apertium-tolk). The idea is that any user with the
> only prerequisite of having JVM installed could download and run it by just
> double-clicking it.
>
Make it an applet or better java web start, like Apertium-viewer so it can
be used both from a web page with no install and also downloaded and
installed for frequent users.
> - Week 7-8: Work on the embeddability of the C++ version of Apertium and
> lttoolbox, focusing on iOS.
> - Deliverable #2: The Swing application developed on week 6 and what has
> been produced regarding the iOS port (code, documentation and, hopefully, a
> working app).
> - Week 9-11: Work on mobile embeddability (J2ME, Android...). If the work
> regarding iOS has been fruitful, we could consider to take some more time
> for it during this weeks if it would be worth it.
> - Week 12: Suggested "pencils down" date: write documentation, test
> everything...
>
> Extra tasks (these wouldn't be planned, but I could be working on them if
> I finish before expected):
>
> - Integration of the JAR files with apertium-viewer.
> - Investigate about the possibility of reducing loading time by memmaping
> techniques.
>
>
> Is it better now? Any other suggestion?
>
>
Looks good.
I'd like Android embedability, Servlets and applet to get a higher
priority.
For all these things it is a problem to read/write to stdin/stdout.
Probably you could do something about that as well in week 1-3.
--
Jacob Nordfalk <https://plus.google.com/114820443085046080944>
http://javabog.dk
Android-udvikler og underviser på
IHK<http://cv.ihk.dk/diplomuddannelser/itd/vf/MAU>og
Lund&Bendsen <https://www.lundogbendsen.dk/undervisning/beskrivelse/LB1809/>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Apertium-stuff mailing list
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
