Mail Archives: geda-help/2020/09/03/19:13:38
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--8323329-1433235500-1599173951=:4145
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
On Thu, 3 Sep 2020, Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via
geda-help AT delorie DOT com] wrote:
> The third [motivation] was restricting of introducing of third party
> code written in whichever language in order to maintain code base
> maintainable given what man-power we had all the time :-)
The use of Python in gEDA/gaf was preceded by an extensive discussion
about the advantages and disadvantages of various languages in question.
Besides that – given the amount of work I had already done at that point
and the fact that I obviously cared about the code I contributed, how can
you now claim this was ever about the question of it being maintained?
> Roland decided (in my view) to transform geda-gaf into his xi/xorn by
> replacing some pieces of C and Guile project code with his new Python
> code.
That's not correct.
1. Since the wish for a more integrated GUI between gschem and PCB was
coming up again and again, and GTK had a history of removing features
which were important for gschem, I wrote Xi and its associated toolkit
from scratch as a unified GUI for gEDA/gaf and PCB.
http://hedmen.org/xi/
It was never used due to the lack of a proper abstraction layer and API.
2. Partly in response to that, I wrote libxornstorage, a C library, from
scratch as a replacement for the gEDA/gaf storage routines. This library
has Python bindings, but you could (and are encouraged to) create bindings
for whichever language you want to write code in.
3. The main practical use case for this was as a refactoring aid for
gnetlist. The gnetlist code was in its existing form practically
unmaintainable, so I put a lot of effort into converting it to a more
usable form, making extra sure I didn't accidentally introduce changes
which would break existing projects.
> Lepton has no issues with obsolete Guile and Python versions
Since I wanted to make the transition as smooth as possible, I wrote glue
code that allowed existing Scheme backends to be run with the Python code.
Guile 2.2 removed the "scm_frame_procedure" function which is crucial for
having a Guile <-> Python bridge. So while I *could* bump the Guile
dependency to a higher version at any point, I believe it may be
desireable to keep that feature for some more time.
CPython 3 uses a different extension API than CPython 2. While I could go
through the extension code, manually updating it to the new API, I believe
it is far better to migrate to an implementation-agnostic API like
PyPy/cffi. As far as I know, this hasn't been done for a project like
gEDA/gaf before, so I have to overcome some new kinds of problems.
(If anyone who knows their way around PyPy/cffi is reading this, please
feel free to join the effort!)
> IMO, xorn could live as a separate project, though without geda-gaf it
> could die, which I consider an only reason why Roland strived to include
> it in geda-gaf
As I have outlined in the other mail, Xorn is a custom-tailored set of
libraries for gEDA/gaf. Of course I included them in gEDA/gaf, this is
the whole point. (It may have been wiser to call them "geda-libs" or
something like that, though.)
Roland
--8323329-1433235500-1599173951=:4145--
- Raw text -