[liblouis-liblouisxml] Re: A new liblouis?
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Sat, 26 Oct 2013 10:50:14 -0500
I think that designinng the algorithms is much more important than
chosing a language. Of course we have to consider extensibility also and
making it possible for non-programmers to implemennt new natural
languages and improve existing tables.
John
On Sat, Oct 26, 2013 at 04:20:04PM +0100, Michael Whapples wrote:
> I think Python has been mentioned up to now simply because that is what
> John Gardner and myself are most familiar with, but yes if others know
> of another language which might be more suitable then mention it.
>
> I know Lua is popular as a scripting language but I have little
> knowledge of what it is capable of. May be give some more details of how
> it could be good for Braille translation.
>
> Michael Whapples
> On 26/10/2013 12:11, Rui Batista wrote:
> >Hi,
> >
> >One alternative to Python would be a more lightweight language such as
> >Lua. It's already used as a scrypting language for games, web servers such
> >as NNGINX and other high performance situations. It's easy to embed a LUA
> >interpreter in a C program or library, from what I know. IMO, it would be
> >nicer to use such a language and possibly creating a DSL for braille
> >tables than creating a home-grown scrypting language from scratch.
> >
> >LUA is just an example, probably someone would come with a better idea.
> >
> >Regards,
> >
> >Rui Batista
> >
> >
> >No dia 25/10/2013, às 22:40, James Teh <jamie@xxxxxxxxxxxx> escreveu:
> >
> >>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
> >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
--
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
Other related posts:
