Gau on, Mikel.
Allow me to answer between your lines.
2016-01-12 21:59 GMT+01:00 Mikel Artetxe <[email protected]>:
> Hi,
>
> On Tue, Jan 12, 2016 at 11:59 AM, Mikel L. Forcada <[email protected]> wrote:
>
>> Dear all,
>>
>> I hope I am luckier this time with this issue.
>>
>
> I guess that you are ;).
>
Yay!!
> The issue is fixed now and I have also updated the binary at
> https://svn.code.sf.net/p/apertium/svn/builds/apertium-omegat/apertium-omegat.jar.
> But it is just a quick patch that fixes the concurrency issues and I
> haven't taken the time to update lttoolbox-java and look into the other
> issues that Daniel mentions.
>
This is great. Daniel will surely check it thoroughly and get back to us if
there is a remaining problem.
>
>
>
>> Could whoever is in charge please take a look at this issue? As I said,
>> the Apertium plugin has a very nice use from inside OmegaT, but the way in
>> which the Apertium plugin handles multiple rapid-fire requests makes it
>> crash, and, as a result, OmegaT crashes too. I would appreciate it very
>> much if developers of apertium-omegat could get in touch with Daniel to
>> collaborate in a solution. If the issue cannot be solved, I will table a
>> motion to mark apertium-omegat as non-maintained / non-official software.
>>
>
> I would say that you very well know that it is me who developed
> apertium-omegat (and otherwise it is not very hard to figure it out by
> looking at svn, the authors file, the wiki or the mailing list).
>
You are right. But my memory fails me often, and I could not find the time
to do all the research. I'm grateful for your clarification!
> Does that make me that 'whoever is in charge' you were talking about? This
> is something I did for GSoC 2012 and as far as I know I never committed to
> maintain it forever.
>
You're absolutely right. In fact, no one could commit to something like
that.
>
> Don't get me wrong, I am happy to contribute with this kind of fixes once
> in a while.
>
Which is terrific and worth praise!
> Believe it or not, the reason why I didn't look into the issue when it
> first appeared is that my contract at that time didn't allow me to do so,
> and I later simply forgot about it.
>
I understand.
I was going to look into the issue after Daniel's last email but I didn't
> take the time for it until today.
>
That's fine. I hope you don't mind if I pushed it a bit further today.
>
> So, while I am happy to contribute with this kind of fixes as far as I
> can, I cannot commit to be the maintainer or person in charge of anything.
>
I can understand that. We can only be grateful for your help when it is
available.
> I don't know if apertium-omegat should be marked as non-maintained as a
> consequence, but I don't see why you would mark it as non-official. Why
> would my GSoC project become unofficial 3-4 years later?
>
The only reason to mark it as non-maintained is that it now consistently
crashes recent versions of OmegaT, which leads to frustration on the part
of end users (i.e. professional translators and translation students).
>
>
>> The second issue is related. Apparently, the language pairs in
>> apertium-omegat, apertium-android, etc. are not up to date. Is there any
>> way they could be kept up to date so that end users get the best possible
>> products (apertium-omegat, apertium-caffeine, apertium-android?). Any
>> suggestions?
>>
>
> That is also something that I did for that GSoC and as far as I know
> nobody has been regularly maintaining it. I have always found it a quite
> tedious task: I often don't realize when new versions are released, there
> are incoherences between the sourceforge releases, the wiki and svn (e.g.
> to know what language pairs and modes are considered officially released),
> I have sometimes had version problems with old and new releases and their
> dependencies... I think that it would be nice to centralize all this
> information somewhere (i.e. the release status of each language pair and
> their modes, their last version and its release date, and their
> dependencies) and keep it updated, it would definitely make this
> maintenance work easier.
>
This was not your call, I guess. We had a contract with Tino Didriksen to
maintain Apertium, and I was trying to find out if these updates were
automated and covered by that contract: Tino has gotten back to me and he
is now acting on this.
> In addition to that, even though I am the responsible for it I think that
> the java related package system used in Apertium is probably not the best
> we could have (e.g. maintaining release binaries in VCS was probably not a
> good idea),
>
You are very right there. It is clearly a hack.
> and I developed a different system addressing the specific needs of
> Mitzuli. This means that there are two parallel systems to maintain in my
> case. I would ideally like to unify them, but being realistic I don't have
> the time to do it in the short/medium term. But well, I haven't updated the
> language pairs in Mitzuli for a long time either, the next time I do I will
> also look at the ones in Apertium :)
>
Unifying them could be great, and perhaps a nice task for a new developer,
if they have enough information (in the wiki, READMEs etc. to do that).
Thanks a million for your response and apologies for not having found the
right tone in my message this morning.
Eskerrik asko benetan,
Mikel
>
> Mikel
>
>
>
>
>>
>>
>> 2016-01-08 13:59 GMT+01:00 Daniel Torregrosa <[email protected]>:
>>
>>> Hi all,
>>>
>>> I am still trying to fix apertium-omegat.
>>>
>>> I decided updating lttoolbox-java to the lastest version was a good
>>> idea, because lttoolbox-java.jar in apertium-omegat/lib is older than the
>>> first version of lttoolbox-java on the svn. I found 2 issues while doing so:
>>>
>>> - Translations replace whitespace with numbers. In
>>> OmegatFormatter.deFormat, lines 101 and 110, the command
>>> spaceWrite.append(currentChar); appends the numeric value of the
>>> whitespace
>>> characters, rather than the proper char (32 rather than ' '). It looks
>>> like
>>> reFormat does nothing to fix this. I thing both lines should
>>> read spaceWrite.append((char)currentChar); , however I am unsure of
>>> possible side effects.
>>> - Sometimes, a "wrong number of arguments" exception is thrown
>>> during the transfer. I am unsure about how to proceed, because, according
>>> to Jacob's comments, reflection is being used to execute bytecode. When I
>>> look into the apertium-xx-xx.jar files apertium-omegat plugin downloaded,
>>> they have files from late 2012. Could it be a lttolbox version mismatch?
>>> Should those files be updated? Who keeps
>>> https://svn.code.sf.net/p/apertium/svn/builds/
>>> <https://svn.code.sf.net/p/apertium/svn/builds/>?
>>>
>>>
>>> Thanks a lot.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Apertium-stuff mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/apertium-stuff
>>>
>>>
>>
>>
>> --
>> Mikel L. Forcada E-mail: [email protected]
>> Departament de Llenguatges Phone: +34-96-590-9776
>> i Sistemes Informàtics also +34-96-590-3772.
>> UNIVERSITAT D'ALACANT Fax: +34-96-590-9326, -3464
>> E-03071 ALACANT, Spain.
>>
>> URL: http://www.dlsi.ua.es/~mlf
>>
>>
>> ------------------------------------------------------------------------------
>> 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=267308311&iu=/4140
>> _______________________________________________
>> Apertium-stuff mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/apertium-stuff
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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=267308311&iu=/4140
> _______________________________________________
> Apertium-stuff mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/apertium-stuff
>
>
--
Mikel L. Forcada E-mail: [email protected]
Departament de Llenguatges Phone: +34-96-590-9776
i Sistemes Informàtics also +34-96-590-3772.
UNIVERSITAT D'ALACANT Fax: +34-96-590-9326, -3464
E-03071 ALACANT, Spain.
URL: http://www.dlsi.ua.es/~mlf
------------------------------------------------------------------------------
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=267308311&iu=/4140
_______________________________________________
Apertium-stuff mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
