I think I'm gonna need to read that again a few times to see if that'd
affect the Java runtime at all, but I thought I'd at least pitch in
with an explanation of how the Java runtime currently handles .mode
files.
When the Java runtime is invoked, it's given a "data directory" as a
command-line parameter. It expects to find the mode files in the
"modes" directory under that data dir. Inside that directory it looks
for a file matching the name of the language pair and direction given
(ex: en-es, es-en, en-eo, eo-en) plus ".mode". (See
org.apertium.pipeline.AperiumMain.java, line 282.)
It then parses that file, splitting on pipes ("|", see
org.aperium.pipeline.Mode.java, line 39), and then parses each
individual program. Then in org.aperium.pipeline.Program.java it
checks to see if the program is one of the components that was ported
to the Java runtime, and if so, sets it up to be run using that.
Otherwise sets it up as an UNKNOWN program. (See lines 67 - 85.)
UNKNOWN programs are run by calling Runtime.getRuntime().exec() and
then trying to execute the full path of the program as specified in
the mode file. (See org.apertium.pipeline.Dispatcher.java, lines 270
and 271.)
A quick fix that uses path could be to check for existence of the
program at the specified path, and if not, try running it w/ just the
command name w/o a full path. I'm not certain at the moment how
fragile that'd be though. ;) Again, AFAIK this only effects language
pairs that use components that aren't in the Java runtime.
Hope this helps add to the discussion. ^_^
-- Stephen
------------------------------------------------------------------------------
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
