[liblouis-liblouisxml] Re: A new liblouis?

  • From: Michael Whapples <mwhapples@xxxxxxx>
  • To: liblouis-liblouisxml@xxxxxxxxxxxxx
  • Date: Sat, 26 Oct 2013 07:14:49 +0100

I agree with your point that it would require someone experienced with writing high performance code, but I dispute whether they would be up to writing it in C or C++. I really needed to be forced into writing C++ before I would actually write any and I still personally prefer to avoid it where ever possible, but I certainly understand some of the areas of potential performance issues in Python, but may be writing high performance Python code is a different thing to writing high performance C code. Also may be I would be up to writing it in C++ but I would just prefer not to.


You make some good points on applications which might try and load multiple Python versions. This was something I was not really aware of, probably because I tend to be working the other way (IE. writing python and extension modules where I need more performance rather than embedding python).

I also am unsure exactly how this will all work. Letting one just write a script does sound a little bit bulky and may be even scary (security concerns as what code might they run, huge variation in performance, etc and also just much repetition between scripts). I would certainly think that a core library and data on how to do the translation sounds preferrable.

I think there is a long way to go before even the first line of code can be written.

Michael Whapples
On 25/10/2013 22:40, James Teh wrote:
Hi.

I certainly agree that we need to think about succession planning.

Even as a huge fan of Python (I use it for everything I can), I'm concerned about performance for something like this. I realise that you can make something very fast in Python or Cython "if properly made". However, the primary reason you cite for moving to such a language is that more people can write and maintain it. I'd argue this isn't so much the case if coding for high performance is a requirement, which requires a fairly advanced programmer anyway, in which case they can probably learn to code well enough in C or C++.

There may be all sorts of people wanting to call the library. I guess there must be a way to build a shared library which exposes Python code so it can be called from native code (though I'm not familiar with it). However, that still requires a Python interpreter to be loaded and initialised, which is a fair amount of overhead. It's also not possible in some situations. For example, an application may already be using a Python interpreter for something else, in which case the library can't load its own interpreter. You also can't load two Python interpreters of differing versions. (We actually hit this problem with NVDA and a speech synth that was using Python for some, but not all, of its internals.)

We need to think about embedded and mobile situations. It might be fine for a notebook, desktop or server computer to run a braille translator in Python, but that may not be feasible for mobile or embedded. Even if it were, it may not perform well enough on these lower powered processors.

I'm unclear on one point. It could be interpreted from this message that each braille code will have its own script. If so, this would be fairly bulky. I think there still needs to be a core library which then loads data (in Python or otherwise) for each braille code.

Finally, I would hope the new library can load the current liblouis braille tables or that there will be a converter for them. It would be a shame to see all of the current work on tables need to be done from scratch, especially as some of the contributors may not be willing to do this.

Just my AUD$0.02. :)

Jamie

On 26/10/2013 2:25 AM, John Gardner wrote:
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



  |



www.viewplus.com <http://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.



For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com

Other related posts: