2012/3/30 Mikel Artetxe
>
>
> In any case, this is just my opinion (and, please, note that my opinion is
> not that iOS should have a bigger priority than Android whatsoever, I just
> defend that developing for iOS wouldn't be as useless as you said).
>
Thanks for providing some numbers, to give
>
>>> 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
>>
>
>
>> In any case, I think that working for iOS is still wo
2012/3/28 Mikel Artetxe
>> 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
>
> In any case, I think that working for
> > 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
>
> 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 ha
On 28 March 2012 13:24, Jacob Nordfalk wrote:
> What!?
The App Store usage agreement has improved a little:
You may not copy (except as expressly permitted by this license and
the Usage Rules), decompile, reverse-engineer, disassemble, attempt to
derive the source code of, modify, or create deri
What!?
2012/3/28 Jimmy O'Regan
> On 28 March 2012 11:33, Jacob Nordfalk wrote:
> > Overall, make sure that your port can be published in Apples store.
> >
>
> The short answer is, it can't be.
>
> The long answer is, it would require every major contributor of every
> component that would be di
On 28 March 2012 11:33, Jacob Nordfalk wrote:
> Overall, make sure that your port can be published in Apples store.
>
The short answer is, it can't be.
The long answer is, it would require every major contributor of every
component that would be distributed to agree to a set of exceptions to
the
2012/3/28 Mikel Artetxe
>
>> 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 unde
On 27 March 2012 23:27, Mikel Artetxe wrote:
> 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 proble
>
> 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
On 27 March 2012 11:22, Jacob Nordfalk wrote:
> 2012/3/27 Mikel Artetxe
>>> I'd prefer to avoid modifying JAR files.
>>> It's a ZIP file. If people wants several pairs in the same ZIP file they
>>> can use ZIP.
>> I don't know if I have correctly explained my idea. In fact, this idea of
>> the se
2012/3/27 Mikel Artetxe
>
>>> Week 7-8: Adapt and extend the previous application so that it can work
>>> with several language pairs. This could be achieved by having a JAR per
>>> language pair and the main JAR executable that makes use of them or by
>>> integrating everything on a single JAR
>
> OK. This would be my very first draft of the 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 4: Make an API class that easily allows the translation of an
>> embedded language
On 26 March 2012 13:49, Jacob Nordfalk wrote:
> 2012/3/25 Mikel Artetxe
>>> I think we should leave 'reducing start-up time' for now, as its not
>>> neccesarily a task that has anything to do with embedding. Sorry.
>>
>>
>> Well, maybe I can work on it, the only thing that I meant was that right
2012/3/25 Mikel Artetxe
I think we should leave 'reducing start-up time' for now, as its not
>> neccesarily a task that has anything to do with embedding. Sorry.
>>
>
> Well, maybe I can work on it, the only thing that I meant was that right
> now I wouldn't really know how to accomplish it
>
> Here's another aspect, which I want to share with you about the loading
>>> of resources - as it is inevitably related to how resources are packaged:
>>>
>>> When translating short sentences the Java port has the disadvantage that
>>> it takes about 1/3 of a second to load.
>>>
>>> This is mai
2012/3/23 Mikel Artetxe
>
>> Sure, make an API class. There are some APIs around that it
>> should probably try to resemple (C++, webservice, ...). I'm not against it.
>>
>> An API that allows acces to the intermediary translation stages, like
>> Apertium-viewer would need, would be interesting
(cc apertium-stuff@lists.sourceforge.net )
About
http://wiki.apertium.org/wiki/Ideas_for_Google_Summer_of_Code/Make_lttoolbox-java_embeddable
2012/3/20 Mikel Artetxe
> Hi,
>
> I am a 2nd year undergraduate in Computer Science at the University of the
> Basque Country that would like to particip
2012/3/19 Marta Maria Casetti
> Hi,
>
> I had your email from jimregan on the IRC channel; I am writing you
> because I am interested in the "Make lttoolbox-java embeddable" task for
> the GSoC - but I do not know if what I know is enough (I have never
> participated in a project like this). To b
20 matches
Mail list logo
