>
> Lets put people in two rough groups:
>
>
> 1) Apertium core developers. They are each maintaining 2-5 of the 20-30
> language pairs that gets updated once in a while (lets say a release once a
> month, on average). They are used to use makefiles and scripts.
>
>
> 2) All opthers. Occational users of Apertium and newbie developers.
>
>
>
> Anything involving requiring 1) to use a GUI to maintain stuff is NOT
> good. They will want to put stuff in makefiles and scripts to automate it.
> Not because they hate GUIs (OK sometime I think that perhaps they hate GUIs
> as well :-), but its just much faster to invoke 'make' than to locate and
> invoke a GUI, pointing and clicking etc etc.
>
>
> My hunch is that group 2) will very seldom need your fine GUI, and if
> they do, they will survive just fine using WinZip. If they ask 1) they will
> be instructed on how to use command line tools.
>
>
> SO: Im sorry, I wasnt clear in my wording:
>
> Easily maintainable means doable from command line. A script somewhere
> that updates alle the JAR language pairs that need to be updated and
> uploads/synchronizes the file tree on some download server.
>
> We have some binary stuff in SVN (look for big files in dir 'webspace' in
> the SVN tree - no-one remembers how to maintain this stuff but luckily
> there is a makefile or update script somewhere I don't remember).
>
> Another place would be on the download servers of Sourceforge, if we can
> find out how to script upload and download from their servers.
>
>
> 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?
>> 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?
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. As
for the dependencies, I simply compile them targeting iOS and link
statically, and it worked.
So this is the current situation. During GSoC I would try to fix the
problems that I had with the transfer stage to get a fully working app and
try to adopt a more elegant and maintainable solution (after all, I
considered it a throwaway prototype to prepare myself and learn about
apertium, so what I did wasn't useful in terms of code but in terms of
experience).
You then updated the wiki and I saw that the "Apertium on your mobile" task
>> was mainly focusing on Android, so I definitely gave up and start focusing
>> on this other project idea.
>>
>
> I wasnt aware that you had already done work on porting the C++ code
> iOS. Sorry about that!
>
It is my fault for not telling you! I worked on February, when you (I mean
Apertium, as an organization) were still working on its application, so I
decided that it was going to be better not to bother you with it...
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.
But we should set some time aside for iOS and of course we should following
> the path that you judge is most feasible.
>
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.
- 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.
- 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?
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
