On Tue, Feb 23, 2016 at 9:27 AM, Tino Didriksen <[email protected]>
wrote:
> I have updated all the pairs I could in
> https://svn.code.sf.net/p/apertium/svn/builds with these omissions:
>
> apertium-ca-it no longer installs mode ca-it - bug, or should ca-it be
> removed from language-pairs?
>
> apertium-eo-es mode es-eo now uses CG-3.
>
> apertium-fr-ca has since been renamed to fra-cat, but now uses CG-3.
>
> apertium-fr-es throws an exception when executing:
> http://codepad.org/1eAyqhEL
>
It looks there is an lrx-proc implementation in Java but is still
experimental and not used. The dispatcher tries to invoke it as an external
program and there is a bug that makes it crash (the -m flag is treated as a
file and it is not found in the package when trying to extract it). I will
fix the bug when I have time.
But the important thing here is that lrx-proc is an external dependency,
just as cg3 and hfst, so we should not have Java language pairs that depend
on it (unless we use some mechanism to handle these dependencies as
discussed below). Is there any other language pair that also depends on
lrx-proc now?
> apertium-ht-en no longer exists.
>
> apertium-oc-ca throws exceptions when jar'ing: http://codepad.org/NZne49C1
>
> apertium-oc-es ditto: http://codepad.org/Ju9D58UO
>
Those two happen because of the '@' character in the filenames of the
Aranese variant. '@' is not a legal character for Java class names, so this
causes a mismatch between the filename and the class name. This shouldn't
be hard to fix but I haven't taken the time for it yet and I simply skipped
the Aranese variant for Mitzuli. A straightforward solution would be to
rename these Aranese files, but a proper fix shouldn't be hard either.
> apertium-sv-da has since been renamed to swe-dan, but there is no release
> with that name yet.
>
> And, I had to bump the used revision for en-es, eo-en, eo-fr, es-ca
> because their releases were so old they no were no longer buildable.
>
> I made a script to do the updating for me
> https://svn.code.sf.net/p/apertium/svn/builds/update-pairs.php which
> pulls revisions from the packaging system, because that is currently the
> best source of release information.
>
> I would like to add a 5th field to language-pairs which is a comma
> separated list of extra dependencies needed for the pair, instead of simply
> skipping them. E.g., "cg, hfst" for kaz-tat. Then systems that can't
> install such dependencies can skip those pairs.
>
Sounds good to me, but we should first update all the applications that
make use of Java pairs to properly handle it and leave some time for users
to update. Otherwise all the current applications would break. For
instance, users would see new pairs in the official Android app and they
would even be able to install them, but the app would crash when trying to
run them.
A dirty solution to avoid these problems would be to have a separate
manifest file for language pairs with external dependencies. This way,
current applications would keep working as they are, and we would still be
able to update them to use pairs with external dependencies if possible.
Mikel
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Apertium-stuff mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
