Mail Archives: geda-user/2015/07/03/23:53:52
On Fri, 3 Jul 2015, Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> On Fri, Jul 03, 2015 at 08:32:01AM -0700, Ouabache Designworks (z3qmtr45 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> ...
>> It has been very stable but the current release (1.8.2) has been out for
>> several years. Ver 1.9 has some nice features that I woud like to use but
>> until it is blessed and pushed out to all the repo packagers then I will
>> stay with the older one that is an easy apt-get install away.
>>
>> Does gEDA still run on windows? I have heard rumblings that it is
> Yes, it works again on windows :) I'm working on the windows port for
> quite some time and I can say that cross-compilation is a nightmare :)
> And the most harmful thing in this process was not geda-gaf but the
> 'mingw vs guile+gc' thing :)
>
> There are some quirks but I've managed to make work all geda-gaf programs
> (excluding maybe some minor utilities which I've not tried).
>
> Now, I'm trying to organize, clean up and finish all (patches/ideas)
> I've got now. All this runs slowly since I've limited bandwidth (as all
> developers all over the world) and some other hard circumstances
> limiting my time.
>
> I don't think I'll get something 'ready for production use' any time
> soon. So for now, if there is somebody who wants to try the last (git
> HEAD) geda-gaf on windows, I could provide him/her with a tarball with
> binaries and some little instructions on how to use it.
>
>> currently broken. Bit rot is real. Unless you are actively testing with the
>> newest distros then any open source project will sink into decay.
> There is no such danger for geda-gaf yet, as I constantly work with its
> latest version and I know that while it compiles at least on Linux,
> it'll live :) The same I can say about pcb and gerbv. It is even
> much easier to compile them now for windows than geda-gaf.
>
>>
>>
>> You also have the big issues like the choice of scheme as gEDAs scripting
>> language and the gEDA file formats. Is there anything to gain by changing
>> and if so then what would be better and how do we transition?
>
> The big issue is with people who consider only their favorite languages
> as the only one which is worth to be used in geda. While I'm already not
> young (though not so old as John Doty :)), I've decided to learn Scheme
> and I can say it's a very interesting experience for me.
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.
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)
- 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)
- 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.
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.
Regards,
Igor2
- Raw text -