X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Wed, 12 Jul 2017 05:44:50 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: "Britton Kerin (britton DOT kerin 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] element restrictions: is it really about the file format? (was: Re: PCB, load element bug) In-Reply-To: Message-ID: References: <20170711005040 DOT d96eccaffe490027849789c3 AT gmail DOT com> <20170711020955 DOT 0108aaea AT akka> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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 Tue, 11 Jul 2017, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > It's been obvious for a long time that the file format is not the > major problem, anyone who has spent time time in e.g. search.c or > find.c knows this. The file format is itself a problem for other > reasons, however. > > If you're going to replace the entire data model, why not use SQLite? > This would give you an almost free replacement for the convoluted and > buggy rtree and undo implementations as well as providing file format > accessible to almost every language anyone might care to use. Haha, this again... We probably have megabytes of the sql debate in the mail archives already - yet I am going to answer it as a genuine question. For that I deliberately ignore the language accessibility part, you know exactly why. (I do this mainly to convert it into another devblog entry so if this sql idea comes up again I won't have to type it again.) First of all, if you read carefully what I wrote: my goal is exactly not to rewrite the whole data model in one big go, but to gradually upgrade it and slowly replace elements with subcircuits while keeping everything compatible and working all the time. I also want to keep the good part and replace the bad parts only. Glib is already replaced, and I am going to keep rtree. If you want to learn more about the process, please read the oldest devblog entry I linked in the other mail. Why not SQL: because I prefer simplicity, portability and don't want to cut down mega-lib dependencies instead of introducing more of them. Sqlite is 50k sloc, while the complete pcb-rnd source is 200k sloc. If you want to use or contribute to projects where this does not matter, please chose gEDA/PCB or kicad. Purpose/functionality/capability: my opinion is that sqlite, and sql in general would be an inefficient, bloated solution that would attempt to fix something that's not really broken, taking away energies from fields where we do have things to fix or implement. In return sql is not that efficient on spatial data as people love to believe^1. Just because it's huge and popular and everyone tries to use it doesn't mean it's the good solution for every possible problem. "Don't fix what's not broken" (especially not with a worse solution): - we already have a very good native file format, lihata, there's 0 reason to replace it (no, we won't switch to YAML either). The lihata parser is very small, it's trivial to make bindings to from any language or even reimplement it in any language. Contribute bindings if your favorite language doesn't have support. If you can't stand lihata, just don't use pcb-rnd. - the rtree code works fine, there's no known bug at the moment. If you know about bugs, be constructive: report them, patch them, commit the fix. - same for the undo engine: no known bug. (Note: I have plans to rewrite parts of the undo engine to make it more extensible from plugins (cost estimation: 20..30 hours), but it's somehwat unrelated.) Conclusion: if you want sqlite, that's not pcb-rnd, that's another project. Levente once started such a project but it didn't get too far - maybe go and pick that up. Or try selling the idea to mainline or kicad. Or fork kicad or mainline or pcb-rnd, rename, add sql, see if users are really turned on by it. You said sqlite is an "almost free replacement", so this must be a real quick project for you. Regards, Igor2 Footnote: ^1: we did test that once for a challenge24 task, with postresql's spatial support and the result was so disappointing that we ended up implementing a custom solution in C. If you disagree, and think sql will be more efficient than rtree: go and implement a script that loads a complex board into sql and execute and time 1M screen-searches with the rtree code and the sql version. Although other disadvantages of sql would make it a no-go for pcb-rnd even if you could get similar efficiency, it'd be still an interesting result to achieve!