Re: [orca-list] Draft Proposed Two-Year Roadmap

[Michael Whapples <mwhapples aim com>]

Hello,
I am not sure how much value is in considering other programming 
languages, particularly those which would require a full 
reimplementation of orca as that would be much work and may not solve 
inefficiencies where orca/atk/at-spi/any other part of the accessibility 
framework is doing more work than it needs to.

I am a bit more welcoming to the idea of C/C++ extensions for python to 
replace components of orca as that could be done in a gradual way as and 
when there is time and as places where performance would really benefit 
from reimplementation were identified. However having said that, is 
C/C++ to write the extensions the best thing, I don't know as it depends 
on what skills are out there but there are other solutions which may fit 
better with the way python programmers may think. One suggestion I would 
make is cython (www.cython.org) or pyrex 
(http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex) which allow 
you to write modules in a python like syntax but have access to C 
libraries and then compile it into a standard C extension for python. 
Personally I am a bit of a C ignorant but have managed to get to grips 
with cython fairly quickly and use other C libraries from it. As a 
little bit of a note, other than python my other main programming 
language is Java, so it was mainly pointers in cython which took the 
most time for me to get to grips with.

Just my thoughts.

Michael Whapples
On -10/01/37 20:59, Mike Gorse wrote:
> I don't think that it's possible to decide whether to partly rewrite 
> Orca in C/C++ until some performance analysis is done, since we need 
> to know whether or not it would significantly speed things up.  There 
> are a lot of factors which can affect performance aside from the 
> programming language. Ie; do some of Orca's algorithms take a long 
> time to run?  If so, is this because it, for instance, repeatedly 
> calls atk code that winds up doing some complex calculation on certain 
> toolkits / in certain cases?  Are there changes to at-spi's ipc or api 
> that could be made to simplify the work that Orca needs to do?  So 
> this debate about whether to use C++ could be mostly moot in the end, 
> or, if some of the significant performance issues are caused by things 
> other than what I mentioned and we have an estimate as to how much 
> using C/C++ could improve performance, then that will inform the 
> discussion.
>
> -Mike G-