X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Sat, 4 Jul 2015 05:59:25 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: "Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] gEDA/gschem still alive? In-Reply-To: <20150703191532.GB21182@localhost.localdomain> Message-ID: References: <1435510363 DOT 682 DOT 26 DOT camel AT ssalewski DOT de> <20150703030409 DOT 32398 DOT qmail AT stuge DOT se> <20150703191532 DOT GB21182 AT localhost DOT localdomain> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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