>
> 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.
>
My experience writing makefiles is also quite limited as I said, but I
accept the challenge.
>> 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.
>
As it has been said, the main problem to publish in the app store would be
the GPL license: Apple doesn't currently allow apps licensed under GPL (I
thought that you were aware of that), although I hope that they will be
making this terms more flexible as the competence becomes stronger... In
any case, I think that working for iOS is still worth it. Jailbreak is a
relatively popular practice to overcome this sort of stupid restrictions
that Apple imposes. Popular open source projects such as ScummVM, XBMC and
VLC distribute their software through Cydia, for instance.
So using xmlvm to convert the bytecode used by lttoolbox-java and avoid the
interpreter step can be interesting from the point of view of performance,
but this wouldn't allow us to publish the app in the app store.
>
>> 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.
>
I had my doubts about the time that I would need to complete these two
tasks, so this is why I haven't specified week 3 for one of them.
Additionally, I might be a bit busy during the first two weeks (specially
during the first one) because I will be taking some exams at university,
although I expect to be able to work a minimum of 30-40 hours each week in
spite of that.
> 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'.
>
OK. But I think that it is going to be better to let the implementation for
week 5, what do you think?
- 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.
>
My experience with Java is mostly with common desktop applications (I see
that I have a lot of limitations :$), but it would be nice to work on that.
I'd like Android embedability, Servlets and applet to get a higher priority.
>
OK. We could include it in week 9-11, I guess (I think that this
generalization is better because we don't really know how much time we
would be needing for each of the tasks, it is more an "investigation" work
than a foreseeable coding task). What do you think?
> 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.
>
I guess that the API should be providing a solution for this. So yes, this
is something in which I would be working in week 1-4.
So the updated work plan would be the following:
- 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. At the same time, 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).
- Deliverable #1: The above mentioned JAR executable.
- Week 5: Implement what has been decided in week 4.
- Week 6: Make a small user-oriented application for translation (something
similar to apertium-tolk). The idea is that any user with the only
prerequisite of having JVM installed could easily use it. It would consist
of an applet or, preferably, java web start.
- Week 7-8: Work on the embeddability of the C++ version of Apertium and
lttoolbox, focusing on iOS.
- Deliverable #2: The 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 (paying special attention to
Android) as well as on servlets and applets. 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...
I don't know if I have correctly reflected your feedback... What do you
think about it now?
Mikel
------------------------------------------------------------------------------
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
