EdaCore: What's up about it? Any news? - Page 1
Forum section: electronics / general

author: timofonic
author_rank: Frequent Contributor
timestamp: July 13, 2015, 02:38:54 pm
content: Hello.Any news about EdaCore? Is it alive? Are there short term goals?QuoteQuote from: Circuiteromalaguito on June 21, 2015, 08:35:10 amQuote from: ScribblesOnNapkins on June 22, 2015, 01:19:51 amhttp://edacore.orgI asked in the IRC channel, but it seems inactive with only three people.Regards.

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: July 15, 2015, 02:45:10 am
content: For some of the reasons I described in the last thread took hold and ground things to a crawl if they are in fact moving at all.For those who want a quick summery of what killed it.*Kicad - is trying to clean up the underlying concept of how it handles a schematic in eeschema. I think they are also trying to work out how to do hierarchy and a few other things geda already has. (someone on the kicad side should really say more, I am on their users list but not their internal dev one)*gEDA and Friends - one of the and friends PCB has the same fundamental problem as eeschema, no clear concept of what a PCB is. We already have hierarchy but our development slowed for a number of reasons and some of us are trying to move it forward again. gEDA and friends started before doxygen existed, we are hoping with added documentation and a few sexy new features we will pull in some added talent. Most of our existing talent got the suite to the feature set that suited them and then settled in on developing a library of symbols and footprints.(I am still working on my thing but the re-awakening of geda's development is eating more of my free time)

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: July 15, 2015, 02:55:08 am
content: I can't fix kicad's eeschema issues but if geda can get pcb in order than we can consider making footprints and later whole layouts portable.

author: Bassman59
author_rank: Super Contributor
timestamp: July 15, 2015, 02:54:45 pm
content: Quote from: ScribblesOnNapkins on July 15, 2015, 02:45:10 amKicad does hierarchy well, actually.There are, as I can see, (at least) two main tasks set out for eeschema after the upcoming stable is released:Moving the schematic symbol libraries over to the "library tables" concept that's in pcbnew.Embedding symbols added to the schematic instead of caching them in a separate file. This will make designs easier to share.

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: July 15, 2015, 11:09:58 pm
content: Apologies Bassman59, I read that it was something on the todo list in kicad's doxygen. What else on that list is not current?For geda embedding symbols is an optional thing.The following is what I was basing my comments on. I think I also got the same general picture a few months back from some of the kicad devs.http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_road-map.html"Coherent SCHEMATIC ObjectGoal:Clean up the code related to the schematic object(s) into a coherent object for managing and manipulating the schematic.Task:Move most if not all of the code from SCH_SCREEN to the new SCHEMATIC object.Add any missing functionality to the SCHEMATIC object.Dependencies:NoneStatus:No progress.Hierarchical Sheet DesignGoal:Create a more robust sheet instance design rather than recreating them on the fly every time sheet information is required.Task:Choose a data structure to contain the sheet hierarchy.Create helper class to manipulate the hierarchy data structure.Dependencies:NoneStatus:No progress."

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: July 16, 2015, 12:00:24 am
content: I was asked off list what my ideas on the direction of this would be. I have some but honestly I already spent a while talking to both groups and we got collectively no where. People were receptive and a lot of ideas were shared. If you want to see mine or other peoples please just look at the archives for geda-users (delorie) and kicad users (yahoo). I don't feel like reposting stuff here.

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: July 16, 2015, 12:01:31 am
content: EDA Core did get a wiki but I am basically the only one to post anything on it. ( a rundown of documentation of other CAD suites file formats as a reference.)

author: timofonic
author_rank: Frequent Contributor
timestamp: September 13, 2015, 10:24:39 pm
content: Are there some new interest in this?

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: September 15, 2015, 02:03:11 pm
content: It is stalled.KiCAD rightfully went back to focusing on their own stuff.gEDA went through some internal turmoil.EDAcore will probably resume but when I can't say.

author: timofonic
author_rank: Frequent Contributor
timestamp: September 15, 2015, 10:12:48 pm
content: Quote from: ScribblesOnNapkins on September 15, 2015, 02:03:11 pmgEDA situation is totally insane. It's even worse than my crazy teenage days, but with extreme geeks involving. What's happening?It's a shame, because I like diversity. I would love pragmatic code reusability, so that things would be easier for everyone.I think EDAcore should focus very strongly on file format parsers, providing it in an application agnostic way. I mean something similar toThe Document Liberation ProjectApart of typical propietary schematic and PCB formats (Altium, OrCAD, PADS, MultiSim, Eagle, DipTrace, Zuken ones...), there's ODB++, ODSII, IPC-2581...Who knows, maybe it's possible.Maybe a LGPL/MPL set of libraries for this could even attract contributions from even propietary EDA developers.Maybe EDAcore started with a too wide focus? What about a subproject just about file format liberation?Electronics File Format Liberation?Electronics Liberation?EDA Document Liberation?(I run out of ideas)With the own domain, a strong manifesto, working stuff and negotiate again with more EDA software.And....blablabla is part of EDAcore Initiative blablabla...

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: September 16, 2015, 04:43:28 am
content: I started to write the story of geda from birth to death when I realized how late it was. At the 7th paragraph when I realized that talking now was risking our current quasi stable politics.gEDA is painfully close to getting a small band of leaders with authority to fix things. (I am a proposed member.)

author: ElektroQuark
author_rank: Unknown
timestamp: September 16, 2015, 08:03:38 am
content: I would like to read that.

author: timofonic
author_rank: Frequent Contributor
timestamp: September 17, 2015, 02:15:09 am
content: Quote from: ScribblesOnNapkins on September 16, 2015, 04:43:28 amI want a bilingual giveaway "thesis" to my vocational school and part of that is going to be about gEDA. Are you going to mention Atari days?Maybe we can collaborate, excuse me for my poor English.There's these emails I've sent to both KiCad mailing lists:Quote from: toQuote from: Mario Luzeiro

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: September 17, 2015, 03:14:43 am
content: I can not post that right now. Things are just calming down.gEDA did not start on atari. PCB did. Later on gEDA and PCB developers got together because most of them were users and at the time gEDA was the only open source schematic capture and PCB was the most modern layout tool that was open source.The trouble with EDA core is not one of file format. People have this idea that we have no good way to represent the data when it is stored. That is not true. The real issue is the layers above it. Look at the number of translation utilities between gEDA and Orcad or geda and kicad. The real issue is how you represent the data after the file is read because you want some kind of data structure that can elegantly be read by functions to do 3 different things.1. Make a netlist2. Make a 2D drawing. (for a schematic)3. Make a BOMgEDA in it's start embodied the ideas of EDAcore in that it was not distributed as 1 package but as a family of them.libgeda - library to handle schematicsgschem - program to manipulate schematics graphicallygattrib - program to tweek symbol attributes in a spreadsheetgnetlist - prgram to make a netlist from a schematicand etc.For users this was a pain but the intention was for 3rd parties to use libgeda to write stuff that used our file format and etc. libgeda's functions had a reasonable amount of documentation and example code to let you do this.In the here and now I am hoping we kind of return to that model. I would like gEDA to have an interface to KiCAD's libraries it can natively support their symbols and vice versa. Then we could collectively move on to doing the same thing for Eagle. Later we could do the footprints.Schematic support is not really possible as I see it. At least not in a way that would work cleanly. There would always be translation issues.

author: timofonic
author_rank: Frequent Contributor
timestamp: September 17, 2015, 03:06:09 pm
content: Quote from: ScribblesOnNapkins on September 17, 2015, 03:14:43 amI understand it. There must be a momentum and avoid history to not be repeated again. A constructive critique is necessary for improving the current environment.FOSS really needs a disruptive change to make FOSS a lot more interesting and avoid oligopolies with very limited focus.The Document Foundation is ac very good example. There needs to forgive about competition and share all of the possible resources.- Why just modularize gEDA suite? What about the very best of both KiCad, gEDA other electronics open source projects?* A common and scripting framework with a good refactoring could be done, making electronics a more collaborative and powerful firm on it too.There would be separated projects, even the the actual ones. But code would be massively saved, because reusing it . A common format is preferable.What's so difficult about to read more schematic file formats and convert/parse then incorrectly? I supposed it to be the pcb file, I would like to know it.I guess C vs C++ could be a lot of controversy between both KiCad and gEDA projects

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: September 17, 2015, 05:53:18 pm
content: C/C++ is not an issue. Actually DJ and others have long wanted to make the code of PCB more C++ in feel. A larger fight inside of gEDA is Scheme and Python. We have an optional alternative netlister in the next release that adds python as a dependency which has been controversial.As to your thoughts about the other issues regarding parallels to office suites, file formatting and etc. You are obviously a smart person but you need more experience in the guts of a CAD program to understand the scope of some things. KiCAD took a very different approach on a number of levels that make our codebases very different in architecture. I am not making a judgement here. gEDA's architecture has some things I don't care for too. Blending the two would be a larger project than ether of them individually.The Document Foundation is a good example *now*. They had a lot of internal struggles early on.

author: timofonic
author_rank: Frequent Contributor
timestamp: September 18, 2015, 05:49:49 am
content: Quote from: ScribblesOnNapkins on September 17, 2015, 05:53:18 pmI'm pleased to know they are interested in C++. Many projects are too old-school and hate OOP.Quote from: ScribblesOnNapkins on September 17, 2015, 05:53:18 pmI did see that alternative netlister as a very interesting project. Unfortunately, some conservative people attached him.I don't understand that Python vs Scheme fight. I think Scheme may be a good programming language, but not an easy one. Python is easier and a lot more widely used.KiCad people have been working about improving Python scripting:https://github.com/KiCad/kicad-python[quote author=ScribblesOnNapkins link=topic=50684.msg757233#msg757233 date=14425123EDAAs to your thoughts about the other issues regarding parallels to office suites, file formatting and etc. You are obviously a smart person but you need more experience in the guts of a CAD program to understand the scope of some things.Despite TDF has a lot more resources than most known FOSS electronics software, they are always blaming about the lack of resources. A reason their mathematical part lacks some stuff send due to that and not being a mainstream demand. Real geeks seem to use LaTeX for that.I have tons of stuff to understand, not just CAD/CAE/EDA stuffI fail to understand the scope of too many things, this one too. Are there some article, paper it document explaining it in some way?Quote from: ScribblesOnNapkins on September 17, 2015, 05:53:18 pmI hope this doesn't end in something similar to Linus Vs. Tanenbaum. You know what I mean. Everyone losses at the end.What are those architecture differences? Are there at least some overall comparison about them?Are the involved parties so stubborn to be unable to reach a rational and reasonable consensus? That's a big problem of humanity, but I hope ACTIVE people on both parties get able to reach some kind of agreement someday.I understand it might be a titanical task to do, but I think it would improve the FOSS EDA ecosystem in a very exponential way.gEDA even uses GNU Triangulation Surface library (GTS), an unmaintained project since years. Someone said the software is "complete, but other said: " Probably not. Triangular meshes are surprisingly tricky and currentversion 0.7.6 does not suggest stability. There seems to be a lot more maintained alternatives. I'm not sure about features, but they seem we powerful:http://www.cgal.orghttp://www.openmesh.orghttp://www.salome-platform.orghttps://github.com/tpaviot/oceQuote from: ScribblesOnNapkins on September 17, 2015, 05:53:18 pmSUN managed the project in an awful way. Oracle bought it and they did distrust the new owner even not than SUN.The fight made possible the LibreOffice fork. Oracle responded in an hostile way because they really hate FOSS even more than SUN (do you remember about CDDL controversy).After the OOo debacle and the fork started to surpass the original, Oracle and IBM " donated" their code to Apache.Fortunately SUN used a copyleft license instead their CDDL trap (incompatible with GPL) license in OOpenOfficeThey relicensed to the propietary-friendly Apache License clearly as a marketing strategy and probably use it as a cheap coding resource for their property derivatives and promote Java (Apache Foundation? They're more of a Java and BSD-like licenses) but finally LibreOffice won in an extreme way and Apache Office is now just a known zombie just some stubborn users still use.I'm sure there were a lot more problems than that. But if they succeeded, I have hopes on this.

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: September 18, 2015, 03:36:47 pm
content: More on C/C++ the code used in geda proper is a lot of gtk+ and glib calls. Those libraries were kind of written by people who wanted to use C++ but in C.Xorn has it's issues fitting into the rest of the codebase but people are working on that.The original developers love of scheme is IMHO one of the reasons for the projects floundering. For a few reasons it is more convenient to code netlisting functions in a language other than C but that means added developers need to be bilingual and most hardware people (like me) do not like python. It is hard to find people who actually understand the issues that come with writing a cad program and even harder to find the subgroup of that group who understand scheme. I know the CS people think all programming languages are ultimately progressing into LISP but it is not a very practical language for these purposes.Python to me feels like Perl did in the early days, it is the start of an idea but not fully thought through. I feel like it is one in a series of languages being developed that are heading in a direction. I see a lot of CS people going from perl (10years ago) to python (last 5 years or sooner) to ruby. Eventually something will replace ruby. We are writing code "for the ages" meaning that it has to be built to last and well C is not an ephemeral language.gEDA has never blamed anything on a lack of resources as far as I can remember. I mean there are times when we might say "I can't do that right now" but that in truth as a few different meanings. Perhaps one of the most problematic issues for geda devs is the number of users who repeatedly ask (demand) a feature that honestly we *don't* want.Linus vs Tanenbaum (linux vs minix) was not a bad thing. Some things are settled in architectural discussions others via evolution/competition. This is more like Jazz music, people playing off each other. IMHO having kicad and geda separate is actually good for everyone. Both ideas of how the design should be done are getting explored and questioned. Linux vs Minix was always stupid because it was not really about engineering. People like Linus, he is a hero but the reality is that he and Tanenbaum are frequently abrasive from what I have been told.gEDA does not use GTS you are thinking about PCB which is a partner project. One thing to know here is that because gEDA and PCB are separate but associated projects there are small feuds between the two. I am on the gEDA side while DJ is on the PCB side. I have a lot of respect for DJ but even he has to admit there are limits on the future growth of both programs because of decisions that were made early on. I have been pushing a documentation project like the one brlcad went through a while back. GTS might be unmaintained but it's bugs have yet to actually effect us. It is used in the DRC which also generates the netlist used for back annotation and ratline stuff. I can't say more because honestly no one (including DJ) actually understands that code any more. gEDA would like the PCB folks to clean house a bit, PCB would like gEDA to accept more new code even if it is not of as high a standard as they would like. There is also a running disagreement about how back annotation should be done which is complicated by the fact that gEDA supports multiple workflows with things other than just PCB, a fact that the PCB people can dismiss too quickly.gnetlist lets us use drive pcb, allegro, liquidpcb, mathematica, protel, switchcap and generate verilog, vhdl, systemc and..... a lot more.Yes I know about these I too have google and for work did some multiphysics stuff at one point. Please don't just google stuff and post it. Answering this is not a good use of my time.Openmesh is used for fluid dynamics and other related work on physics and mechanical problems. Like GMSH. It is intended to do things like let you load, mesh and pass models in 3D into programs like OpenFOAM. The same is true of CGAL I think.Salom-platform is just someone's stuff to sit on top of opencascade.Opencascade has it's own issues with it's developer / user communities. That fight caused the creation of it's community edition and later a change in how dassault sys. manage the project. Opencasecade has taken a long time to adopt a true gpl compatible license. Plus it is really a 3D thing for mechanical cad.You seem to understand a lot more CS than you do EE. The thing about EE CAD is that the key property of things is how they are connected, the mechanical stuff is just attributes of the connected features. Mechanical software is written the other way around and is for the most part not viable.I knew people who were involved in The Document Foundation. It was bigger than the change over in ownership. Although I was/am a big proponent of what SUN. They were for CS people what HP Labs was to EEs.

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: September 18, 2015, 05:50:34 pm
content: The best and worst thing to ever happen to gEDA was the creation of KiCAD.With KiCAD in the picture all the users who were harassing us to make gEDA & PCB more like Eagle had someplace else to go. We lost a few developers I think but they were people who were minor contributors to begin with.The bad side for gEDA was CERN picking KiCAD and throwing their programmers time at it. The problem here was the blow to the communities moral.Again this is all IMHO.

author: timofonic
author_rank: Frequent Contributor
timestamp: November 06, 2015, 06:19:26 pm
content: @ScribblesOnNapkinsI'm sorry. Anyway, the massive forking of gEDA and the flaming at geda-users doesn't help too.They are using languages that aren't popular. These days it's better to use C++ and Python.Anyway...Are there hope about something to happen at FOSSDEM?

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: November 08, 2015, 12:47:36 am
content: @CircuiteromalaguitoIt's ok. Since my last post a few things have happened. C++ is not that popular among people working on Linux or most of the BSD's. Torvalds for example famously declared that the kernel would never move to C++. This is going to sound really elitist but there is a curve between the ease of a language and the average quality of the programmers using it.The forking is not a bad thing. Igor2's fork IMHO embarrassed a lot of the other developers into behaving productively.1. There was a whole anti-fork movement to pull viable code into the mainline of PCB.2. A number of new backends to gnetlist have been written by John Doty which enable you to do things like verify people have not used symbol slots correctly. He also did another one that generates Makefiles to drive the suite via schematics. The idea is for users who want to use the Automation (the A in gEDA) with out opening a text editor and draft a makefile.3. Igor2 in his own fork3a) implemented back annotation (notation really) with a cool video.https://archive.org/details/pcb-rnd-back-annotation3b) A cool parametric footprint generator.3c) Minicut which uses an massively better algorithm for finding shorts between nets3d) GPMI which enables the use of way more languages for plugins in pcb-rnd.4. We have a new unstable release of geda-gaf with some cleanups, corrections,5. We have a general consensus that scheme needs an alternative.6. There is an accepted proposal to have a backend that lets you pull more info from the schematic into the pcb layout. So you would be able to label a trace as needing a specific kind of routing. The idea being that you could label a trace as needing to be a given width/current rating or that it should be done via a matched impedance or as a differential pair.FOSSDEM mostly depressed me when it was announced again. I can't help but reflect on how incredible our optimism was then vs now. Still

author: timofonic
author_rank: Frequent Contributor
timestamp: November 08, 2015, 10:34:16 pm
content: @ScribblesOnNapkinsWhat's wrong with FOSSDEM? gEDA can attend and I hope there's mutual code sharing between both projects. I see it as a win-win situation.

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: November 12, 2015, 02:19:41 am
content: Oh nothing is wrong with FOSSDEM. I am just sad about the 1 year mark passing and progress of gEDA.

author: timofonic
author_rank: Frequent Contributor
timestamp: May 22, 2016, 06:51:35 am
content: Any news about this?

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: May 25, 2016, 02:42:42 am
content: gEDA has some internal news but to my knowledge EDAcore has no news.

author: timofonic
author_rank: Frequent Contributor
timestamp: May 27, 2016, 10:37:43 am
content: Are there any interests in this? It's sad there's lack of common code.

author: ScribblesOnNapkins
author_rank: Regular Contributor
timestamp: May 29, 2016, 11:02:34 pm
content: Common code is not a good thing. Sure it saves time but it is better to have the two camps trying different approaches. The shame is what it does to our user base. What we do need and what I was hoping would come from EDAcore was a common interchange format or common file format library.