[liblouis-liblouisxml] A new liblouis?
- From: "John Gardner" <john.gardner@xxxxxxxxxxxx>
- To: <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Fri, 25 Oct 2013 09:25:14 -0700
Hello all. John Boyer has been the guiding light of liblouis from the
beginning, and it is hard to imagine the project without him. But all good
businesses need to have succession plans, and it is hard for many of us to
imagine how anybody else could take over the liblouis project as it now
exists. I believe that we should begin a twin project to remake liblouis
and liblouisutdml into something that uses modern scripting languages that
many more people can write and maintain. I have previously suggested
adopting a good well-known well-supported scripting language so that the
translator for any given language could just be a script. This approach has
many advantages, including the fact that almost anybody can learn a good
scripting language well enough to write and maintain translators. The
project would be big, and it would need to be done largely by volunteers
over time. We would certainly be using the present system for years. Let
me emphasize that I am definitely not suggesting that present developers
divide their time - we cannot afford that. Any parallel development must be
done by other people and by current developers during personal time.
The problem with scripting languages has always been that they are typically
much slower than good compiled languages. Consequently, a number of people
on this list have objected to such a change. In a few private discussions
with APH developers, we have worked out a plan that has the advantages of a
scripting language, a way to introduce it without disrupting the way
liblouis is currently being used, and that does not sacrifice speed.
Ken has offered to write up a library that permits one to substitute a
script for the current liblouis table+engine for any given language, so that
as a new script is perfected, it can be slipped in with no change in any
software that uses it. Ken needs to explain the details though.
The speed penalty can be minimized by letting any "heavy lifting" be done
by compiled routines, for example a look-up table that will translate 95% of
the words probably faster than the current method. If necessary, the script
can be compiled. If properly made, the compiled version can run as fast as
a hand-coded routine.
I have proposed using Python as the scripting language, and Michael Whapples
has propposed using it in a controlled manner so that it can be compiled to
C with Cython. I believe that this is a good approach, and I like it
because I am more or less capable of writing Python, so I would volunteer to
start the process by writing a new translator for Nemeth and UEB.
Okay, it is now time for all you stakeholders to weigh in. Succession
planning is not really an option - we have to do something. The question
really is "What?" We all understand about the need to keep translation fast
and the need not to take up any significant amount of present developers'
time. What are other issues, and what are other answers to "what?"?
John Gardner
_____
John Gardner
|
President
|
Description: Description: Description: ViewPlus
541.754.4002 x 200
|
<http://www.viewplus.com/> www.viewplus.com
_____
PRIVILEGED AND CONFIDENTIAL: This message and any files transmitted with it
may be proprietary and are intended solely for the use of the individual to
whom they are addressed. If you are not the intended recipient, any use,
copying, disclosure, dissemination or distribution is strictly prohibited;
please notify the sender and delete the message. ViewPlus Technologies, Inc.
accepts no liability for damage of any kind resulting from this email.
Other related posts:
