[liblouis-liblouisxml] Re: Some refactoring in compileTranslationTable.c
- From: Bert Frees <bertfrees@xxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Sat, 18 Jan 2014 12:03:09 +0100
Exactly. Thanks for the explanation, Aaron. I should've been more clear myself.
The alternative table resolver is completely optional. By default, the function
is implemented in liblouis itself. My Java bindings[1] just offer a way to
"inject" a Java function into liblouis.
[1]: https://github.com/liblouis/liblouis-java/commits/table_resolver
On 18 Jan 2014, at 00:33, Aaron Cannon wrote:
> My understanding is that no Java or other dependencies were introduced
> by Bert's commit, but simply that now there is the option to register
> a custom function for locating tables, and that such a function can be
> written in Python, Java, or any other language that let's you export a
> c compatible function. I further understood that it is entirely
> optional whether or not one chooses to do so. If not, Liblouis will
> simply work as it always has in this regard, except for the extra
> functionality that Bert introduced.
>
> On 1/17/14, John J. Boyer <john.boyer@xxxxxxxxxxxxxxxxx> wrote:
>> Bert,
>>
>> I'm glad to see work on refactoring. Hwever, I'm a little concerned about
>> the mention of Java. liblouis shouldn't be dependent on it.
>>
>> John
>>
>> On Fri, Jan 17, 2014 at 02:20:39PM +0100, Bert Frees wrote:
>>> Hi all,
>>>
>>> I took the time to polish some code in compileTranslationTable.c,
>>> notably the code that handles "table resolving", i.e. finding the
>>> correct table files based on a "table list string" or an "include
>>> expression" in a table.
>>>
>>> Actually I changed quite a bit of code, but the functionality stayed
>>> largely the same. It is completely back-compatible but became more
>>> robust. The major improvement is that the code is cleaner and simpler,
>>> and without any duplication.
>>>
>>> If anyone is interested in reviewing my changes, see [1] (last 4
>>> commits).
>>>
>>> Basically, what I did is I've separated more clearly the compilation
>>> from the table resolving. I abstracted out the table resolving in a
>>> function called `resolveTable' that returns a *list* of file
>>> path's. The function now also accepts a *base* argument. The most
>>> obvious advantage of this is that you can specify a table with an
>>> (absolute or relative) path, while the "includes" in that table will
>>> still work as expected (meaning files in the same directory will be
>>> found).
>>> I need that feature in DAISY Pipeline.
>>>
>>> A small bonus of this refactoring is that the `resolveTable' function
>>> can easily be interchanged by alternative implementation, when the
>>> default implementation doesn't satisfy all the needs. The function
>>> `lou_registerTableResolver' was added to do exactly that. I'll like to
>>> use that feature too in DAISY Pipeline. In my case the alternative table
>>> resolver is written in Java[2], but it could be C or Python or whatever.
>>>
>>> I've created some tests that demonstrate the new features, and more
>>> importantly prove that all of this is back-compatible.
>>>
>>> WDYT?
>>>
>>> Cheers,
>>> Bert
>>>
>>> [1]: https://github.com/liblouis/liblouis/commits/table_resolver
>>> [2]: https://github.com/liblouis/liblouis-java/commits/table_resolver
>>
>> --
>> John J. Boyer; President, Chief Software Developer
>> Abilitiessoft, Inc.
>> http://www.abilitiessoft.com
>> Madison, Wisconsin USA
>> Developing software for people with disabilities
>>
>> For a description of the software, to download it and links to
>> project pages go to http://www.abilitiessoft.com
>>
> For a description of the software, to download it and links to
> project pages go to http://www.abilitiessoft.com
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
