Mail Archives: geda-help/2011/12/21/09:08:01
On Wed, 21 Dec 2011 14:17:08 +0100, Andrea Perdicchia
<trinkity DOT spam AT gmail DOT com> wrote:
> Il giorno 20/dic/2011, alle ore 12:21, Peter TB Brett ha scritto:
>
>>
>> Hahahahahahahahahahahahahahahahaha.
>
> What answer is this? You are not a professional man !!!
You asked what I thought, and that is *exactly* what I thought when I read
your e-mail. By the way, it's also not very "professional" to glance at a
project's code and write to the *user help list* to say, "You should
rewrite this entirely in a different language," with nothing even
resembling a justification for your opinion.
Let me waste more of my time in providing a more expanded answer: a switch
away from C as the core programming language for gEDA/gaf is not currently
a feasible proposition.
- For most users, it is necessary to execute Scheme code in order to even
correctly load a schematic, and it would be necessary to develop a
migration tool for those users. This by itself would be a non-trivial
exercise.
- Unfortunately, many of the key algorithms used in e.g. gnetlist are very
poorly documented. It would be necessary to either ensure that the output
of the Python version is bug-compatible, or (once again) provide a
migration tool.
- Using a C library like libgeda means that it is (in theory) possible to
make core code accessible to many other programming languages. If the core
code is written in Python, it is only usable from Python.
- Python is *slow*, and we already suffer from rendering performance
problems for large schematics. I have been programming in Python for
almost ten years, and in that time there have been several programs that I
have *had* to rewrite in C in order to get acceptable performance.
- Rewriting everything in Python would take a very large amount of
developer effort to even get back to parity with current features -- effort
that is already in short supply.
So, to summarise: we would spend a lot of valuable time and throw a way a
large amount of working code to obtain a solution that performs worse,
provides less flexibility to third party developers, and requires a tricky
migration for existing users and their designs.
My time, and the time of other developers, would be much better spent on
improvements to the current codebase and a gradual, smooth migration in the
direction of improved API stability and more easily portable project
formats.
If you're so intent on using Python, I suggest writing a Python binding for
libgeda.
Peter
P.S. Since your original e-mail and the ensuing thread have been completely
off-topic for the gEDA-help mailing list, please direct any further
discussion to the gEDA-user mailing list.
--
Peter Brett <peter AT peter-b DOT co DOT uk>
Remote Sensing Research Group
Surrey Space Centre
- Raw text -