Mail Archives: geda-user/2015/07/07/12:01:49
On Sat, Jul 04, 2015 at 05:59:25AM +0200, gedau AT igor2 DOT repo DOT hu wrote:
...
> I think there's another side of this story.
>
> Current situation is that scheme being the only language at some parts of
> project. Many others, including me, suggest there could be support for other
> languages as well, or if that's not possible, at least more of the core
> functionality should be moved from scheme to C so that bindings to other
> languages are possible.
Why not to assembler? ;)
I think other way round. For me, interpreted languages are preferable.
BTW, Stefan Salewski (who started this flame :)) has often claimed
that if we'd use an interpreted language, the development of gEDA would
be quicker.
It's frustrating for me that the core functionality of libgeda/gschem is
written in C (e.g. reading and writing of files) which makes it
unmaintainable (see, for example, what bugs are marked as critical at
https://bugs.launchpad.net/geda) for a long time. I believe, it would be
easier to fix them if the geda-gaf language was really Guile/Scheme.
>
> While I do have preferred languages, I never said they should be the only
> ones used, and I can't remember anyone else suggesting similar things. So
> that part is quiet the opposite: the current favorite language is scheme,
> and this is the only one available in relation with some parts of gschem,
> while users suggest there could be alternatives.
>
> Btw, I did dive down in scheme too, and managed to write netlist exporters,
> but it was ultra painful and time wasting. There's no perfect language, and
> people are different. Some people will be efficient with scheme, others
> won't. The key here is:
>
> - Try not to limit the scripting languages a project can use to 1 (this,
> unfortunately is not a popular idea, and most projects are more or less
> coupled with a single language)
I don't think anybody is trying to limit which languages should be used :)
OTOH, lots of dependencies makes the life of the developers much worse
(especially, when you'll try to meet all dependencies for cross
compilation).
BTW, a while ago I found that PCB depends on tk, having, IIUC, only one
script written in it. I found this during cross-compilation of it.
>
> - If for some reason the project is indeed coupled with a single language,
> at least be aware of all the consequences, and don't try to pretend that it
> doesn't matter (in number of contributors for example)
I know that many geda developers use C to add functionality to geda-gaf
(which frustrates me) and that this is not a reason why they cannot do
more.
>
> - The core is written in C; decouple scripting support from core as much as
> possible. And I mean it strictly: all basic functionality should work
> without scripting (some netlisters included in my system of preference).
> Scripting should be for extra, optional features. In such a world, it
> wouldn't be a problem to compile gschem on windows - at least the core would
> work perfectly, and if guile doesn't crosscompile, some extra features (...
> written in one of the available scripting languages) are at risk.
Do you mean gnetlist must be rewritten in C? :)
As for guile, what language is better crosscompiles on windows? And why
should I bother if it is assembler? (Just a joke, don't take it
seriously :))
>
> What should we do about it? With the limited developer resources the project
> currently has, providing fully functioning alternatives to scheme is not
> realistic. However, we could focus on not making the matter worse. My humble
> suggestion:
>
> When writing new code, wherever possible consider using C instead of scheme.
> If anyone later on tries to provide bindings for another languages, he needs
> to do the C <-> scriptlang binding, and doesn't need to reproduce scheme
> code in C or another language and doesn't need to do scheme <-> scriptlang
> bindings.
I believe real coding is the way to go.
For language bindings, gobject libraries already used in geda-gaf would
be helpful. I didn't hear about any comparable libraries yet.
Cheers,
Vladimir
- Raw text -