Karl,

I don't think that ST= EP is the way. It would really hurt John, because it is waaay too complex, = (even more complex then pcb application requires), and AFAIK, has NO open s= ource library.

The 50+ library is written in AWK, Per= l, you name it. I also have one. As pointed out earlier, it is a partial im= plementation. Just approx 100 lines of code. I'm also a script writer b= oy, but I certainly do NOT want to maintain that library. I just want to ha= ve an API, and use it. Of course, if I will be a gPCB developer, yes, I'= ;d contribute code, but I think it is a waist effort in the community to wr= ite the same code n times. To be honest, I don't think you can use any = of the current implementation. It is either not a complete parser (the scri= pts), or unusable (sorry for PCB devs). I'd write it from scratch. But = this just my view.

Yes. Open source is about like this: "hey gu= ys, this is the idea of what I have, and I implemented it. Here is the code. Do you think it is=20 okay? Yes, and here is a patch to your original code to enhance the=20 features..." IMHO. So if you write one, you shall decide what you writ= e. It is your free time after all.

Yes. I also started to= write a parser for the existing format, to be able to translate a pcb file= to my new, SQL based format. It is written in perl, and looks ugly. I'= m not a good programmer.

Lev

On Wed,= Jan 6, 2016 at 2:30 PM, <karl AT aspodata DOT se> wrote:
Levente:
...
> When selecting a file format I would not have such co= nstraints like "it
> should be pretty for a human eye". CAD data is so complex, that o= ne can
> (and I believe should not) parse them with naked eye. For a computer,<= br> > binary is much more efficient.

If we really are going the "complex cad data" route, I'= ;d head Peter
Cliftons advice to use step. And if I'd start programming with that I wouldn't concider the price of the step-cd be of any consern.

> So I still prefer the SQLite database, as that library is optimized fo= r our
> purpose. Yes, I prefer to have a library, that parses our files, and g= ives
> us the possibility to use, or modify the data. I prefer this way becau= se we
> have approx. 50 different implementation of pcb/gschem file parser. Th= ere
> is one in pcb/gaf, and all the other power users wrote their own. It w= ould
> be much better to write the parser once, and other could use that. If = file
> format changes, you have to just change one code, and not 50+.

I agree that it would be wery nice to have a lib for sch/pcb file (regardless whatever format they have) parsing+extra with bindings to
mult. languages. But as you said we already have one (+49 others),
I don't which one is the best one, do you know ?
Can we take that one and improve upon ?

> If we use a standard file format (SQL, YAML, JSON), the parsing librar= y
> could be very thin. The independent parsing code is already written. O= nly
> the application (gEDA) specific code has to be written. Remember, all = of us
> has very limited time to contribute code to gEDA nowadays.

So your stance in the end, is that it is the doers who decide,
irrelevant if the lib is thin or thick ?

And the first step would nevertheless be to be able to parse the
current formats, at least for backward compatibility.

Regards,
/Karl Hammar

-----------------------------------------------------------------------
Asp=C3=B6 Data
Lilla Asp=C3=B6 148
S-742 94 =C3=96sthammar
Sweden
+46 173 140 57=

--001a11407aaca26d470528aac5d1--