Mail Archives: geda-user/2015/08/25/06:55:24
Am 25.08.2015 um 11:45 schrieb Levente (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]:
> Think of that your scripts will be much more compact. No need to implement
> parsing N times.
>
> Generating a drill report is just one query of the database. Your script is
> just to pretty print the output.
> Same goes for XY files for your pick and place machine.
That's undoubtly nice. Still you do a few assumptions:
- People writing their tweaker know what SQL is. Often they just whip up their vi or emacs or geany to adjust a few coordinates. pcb nicely saves markers, like the 'selected' flag to help here. "Parsing" is done with the blank eye.
- The tweaking script has access to one of these language bindings. Shell scripts, good old AWK, generic text editors, don't.
- People are willing to rewrite their scripts. Honestly, I couldn't do that for stuff I did two years ago, I'd have to start from scratch.
- Having a binary format gives an advantage outpacing the above. I think writing one importer and one exporter is much much easier than rewriting hundreds of scripts.
- And then there are habits, people being used to do things a certain way. This is where the flamewars start, so let's ignore this. :-)
Undoubtly there's a clash between practical considerations and considerations for clean, efficient software. One can't have both at the optimum.
By no means I want to hold you back from hacking away. Actually I'd like you to be successful. I just want to share some of my 30 years of experience, because you'd be not the first to shipwreck with challenging plans. It's a huuge task.
It's important to consider that people won't change their toolchains because it's a toolchain much better in aspects of software theory. They change their toolchain solely for personal gain. If benefits don't at least outweight the burden (learning curve + the above), people will keep what they have. "Never change a winning team". May sound sad, but that's how life is.
If I'd plan on such a fundamental change, I'd do it in small steps:
First step: import and export the current file format. Software behaviour to the outside unchanged, but internally there's now a DB in parallel with the current storage arrays.
Second step: move code for one object, e.g. plain tracks, from the current array based design to the DB based design. Behaviour to the outside, to the user, still unchanged.
Then I'd repeat this for other objects, until these storage arrays are gone.
With all the internal stuff now being based on a DB, half of the goal is achieved. At this time user-visible improvements can start. Like making pads a special case of generic tracks. Like introducing sub-circuits or linked elements. Like extending the file format to store the results.
This way the learning curve for users is flat, granting high acceptance. Also, small changes are much more robust against regressions in software stability.
Now, happy hacking! Looking forward to see code :-)
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
- Raw text -