Mail Archives: geda-user/2016/01/06/09:00:19
--001a11407aaca26d470528aac5d1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Karl,
I don't think that STEP 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 source library.
The 50+ library is written in AWK, Perl, you name it. I also have one. As
pointed out earlier, it is a partial implementation. Just approx 100 lines
of code. I'm also a script writer boy, but I certainly do NOT want to
maintain that library. I just want to have 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 write 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 scripts), 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 guys, this is the idea of what I
have, and I implemented it. Here is the code. Do you think it is okay? Yes,
and here is a patch to your original code to enhance the features..." IMHO.
So if you write one, you shall decide what you write. 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 constraints like "it
> > should be pretty for a human eye". CAD data is so complex, that one can
> > (and I believe should not) parse them with naked eye. For a computer,
> > 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 for
> our
> > purpose. Yes, I prefer to have a library, that parses our files, and
> gives
> > us the possibility to use, or modify the data. I prefer this way becaus=
e
> we
> > have approx. 50 different implementation of pcb/gschem file parser. The=
re
> > is one in pcb/gaf, and all the other power users wrote their own. It
> would
> > 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 library
> > could be very thin. The independent parsing code is already written. On=
ly
> > the application (gEDA) specific code has to be written. Remember, all o=
f
> 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
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Karl,<br><br><br></div>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.<br><br><br></div><div>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.<br><br>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.<br></div><div><br>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.<br><br></div><div>Lev<br></div><div><br><br><br></=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed,=
Jan 6, 2016 at 2:30 PM, <span dir=3D"ltr"><<a href=3D"mailto:karl AT aspo=
data.se" target=3D"_blank">karl AT aspodata DOT se</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">Levente:<br>
...<br>
<span class=3D"">> When selecting a file format I would not have such co=
nstraints like "it<br>
> should be pretty for a human eye". CAD data is so complex, that o=
ne can<br>
> (and I believe should not) parse them with naked eye. For a computer,<=
br>
> binary is much more efficient.<br>
<br>
</span>If we really are going the "complex cad data" route, I'=
;d head Peter<br>
Cliftons advice to use step. And if I'd start programming with that I<b=
r>
wouldn't concider the price of the step-cd be of any consern.<br>
<span class=3D""><br>
> So I still prefer the SQLite database, as that library is optimized fo=
r our<br>
> purpose. Yes, I prefer to have a library, that parses our files, and g=
ives<br>
> us the possibility to use, or modify the data. I prefer this way becau=
se we<br>
> have approx. 50 different implementation of pcb/gschem file parser. Th=
ere<br>
> is one in pcb/gaf, and all the other power users wrote their own. It w=
ould<br>
> be much better to write the parser once, and other could use that. If =
file<br>
> format changes, you have to just change one code, and not 50+.<br>
<br>
</span>I agree that it would be wery nice to have a lib for sch/pcb file<br=
>
(regardless whatever format they have) parsing+extra with bindings to<br>
mult. languages. But as you said we already have one (+49 others),<br>
I don't which one is the best one, do you know ?<br>
Can we take that one and improve upon ?<br>
<span class=3D""><br>
> If we use a standard file format (SQL, YAML, JSON), the parsing librar=
y<br>
> could be very thin. The independent parsing code is already written. O=
nly<br>
> the application (gEDA) specific code has to be written. Remember, all =
of us<br>
> has very limited time to contribute code to gEDA nowadays.<br>
<br>
</span>So your stance in the end, is that it is the doers who decide,<br>
irrelevant if the lib is thin or thick ?<br>
<br>
And the first step would nevertheless be to be able to parse the<br>
current formats, at least for backward compatibility.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Regards,<br>
/Karl Hammar<br>
<br>
-----------------------------------------------------------------------<br>
Asp=C3=B6 Data<br>
Lilla Asp=C3=B6 148<br>
S-742 94 =C3=96sthammar<br>
Sweden<br>
<a href=3D"tel:%2B46%20173%20140%2057" value=3D"+4617314057">+46 173 140 57=
</a><br>
<br>
<br>
</div></div></blockquote></div><br></div>
--001a11407aaca26d470528aac5d1--
- Raw text -