[liblouis-liblouisxml] Re: A new liblouis?
- From: Ken Perry <kperry@xxxxxxx>
- To: "liblouis-liblouisxml@xxxxxxxxxxxxx" <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Sat, 26 Oct 2013 18:47:11 +0000
I think my idea of a shell library would be easier because it wouldn't mean a
forced code freeze. Problems in liblouis now could be improved which would
improve the overall library while if someone has wrote new parsers for some
languages they could be used instead of the current liblouis all under the hood.
Ken
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Mesar Hameed
Sent: Saturday, October 26, 2013 2:27 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: A new liblouis?
It sounds like what is being suggested is to rebuild liblouis from scratch.
Might it be more beneficial to enforce a feature freeze for an extended period
of time, where no new code is allowed to enter the repository.
During this refactoring time, we try to untangle the spaghetti code/rewrite
those parts, and make things more modular.
This would mean that segments of the existing liblouis could be tackled,
cleaned up and when tested to be equivilent to the one in trunk, merged back.
At the end of the process we have improved liblouis, and positioned it
hopefully in a better place to tackle new challenges.
The effort required is somewhat less than starting from scratch, but is also
not negligible.
Mesar
On Sat 26/10/13,07: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.
> >
>
> --
> James Teh
> Director, NV Access Limited
> Ph + 61 7 5667 8372
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @nvaccess
> For a description of the software, to download it and links to project
> pages go to http://www.abilitiessoft.com
Other related posts:
