delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/01/06/09:00:19

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=iXrOiah2EbMTXUPYIrY/p6hjKd49znsa5wKhOcxSbDU=;
b=jSHJpYFIYGMvHdyPPqb29kiMIuxz/MWcOgttxIwzEMoASyJI/CpDRK//AE5bV+SPXG
N7LoVeZgD6/nP83RIX+zV3Kn+1alkjx86Z1Oh/QE5MiVYzanrIZ9o+4Y31iviqLoGZCN
pkGajtXZwF9zKb07hbck/+wvXf7b1xfrovkqCj/K6bYEV/DyCBSnReREk0TXdZDAltNs
cA8Ph9cVSM+VDK+0cfa8AOvpI7Z9Z0Tnqwys79wjT0Bl1pNwXD3xf3iMLyAswBkVhPeU
tyIb8kPKR5lDeGSFxUkUGMBO/VzP035aJlOS+eQEGY+bBu6ZqkSX01298pZBdrWZVHAW
6S0g==
MIME-Version: 1.0
X-Received: by 10.107.157.83 with SMTP id g80mr49799797ioe.187.1452088808859;
Wed, 06 Jan 2016 06:00:08 -0800 (PST)
In-Reply-To: <20160106133049.5A0E9809D79B@turkos.aspodata.se>
References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG>
<CAJXU7q_qxdvJaejF-VcY=u7VHZ-zrfrc+Z7-qSwfFyPdy-umxw AT mail DOT gmail DOT com>
<B02363CD-469D-493A-AC15-1D5DC7836982 AT noqsi DOT com>
<20151222232230 DOT 12633 DOT qmail AT stuge DOT se>
<0F6F1D0F-4F07-48EA-90FE-836EAD4E2354 AT noqsi DOT com>
<CAM2RGhTficnys3a4xs=UBFvk8aPwpzYWUADFLP_pUQ+R1iKs0g AT mail DOT gmail DOT com>
<0FCF3774-F93C-4BFF-BB61-636F75DCCACB AT noqsi DOT com>
<CAC4O8c_UAiFE-vGfoE2tXppHLhaa0dSYz9o_rkdCBo7_SRRtxw AT mail DOT gmail DOT com>
<FFBE7623-E240-4798-96B0-2BECF56C8E29 AT noqsi DOT com>
<CAC4O8c980g1gj15=5njstC_BT-WYDgKQx9BRycdFKA8OvgtiOg AT mail DOT gmail DOT com>
<B54C0E1F-1986-4C79-9F70-7F1919B8B26D AT noqsi DOT com>
<CAC4O8c9bxJP1eMG4yz3YwKkQJRmsDGmLQ0aMd5pJRyu0WpdCtQ AT mail DOT gmail DOT com>
<C1CFCCEE-C64A-4E49-AA64-446C061656D6 AT noqsi DOT com>
<CAC4O8c-zt8B=joDd+ws77D2jt6aZf3MWfR_dAvpzGcNuBrTURQ AT mail DOT gmail DOT com>
<alpine DOT DEB DOT 2 DOT 11 DOT 1601030040320 DOT 2176 AT newt>
<D9825C8C-B6FD-4C7F-A8D5-B8AF06253B72 AT noqsi DOT com>
<CAC4O8c_R5xWLmzj_cz0g0mPWNs6mR4efjXKGBoup8YO6nwnPTA AT mail DOT gmail DOT com>
<20160105182120 DOT 3237F809D79B AT turkos DOT aspodata DOT se>
<CAC4O8c8cVr1H3skmbGo4Rhf5ZTZj8bDxJw8a9C4qfHeGyXZ4XA AT mail DOT gmail DOT com>
<20160106091006 DOT 5F67B809D7A1 AT turkos DOT aspodata DOT se>
<CACwWb3CcsYJ9KgDFAa5pZqDzfTewhvbuatbxoKUp6PtHRCoa+w AT mail DOT gmail DOT com>
<20160106133049 DOT 5A0E9809D79B AT turkos DOT aspodata DOT se>
Date: Wed, 6 Jan 2016 15:00:08 +0100
Message-ID: <CACwWb3Cyk4yLwt3=V1Mu5C4RieOQEjYH3ej5MXZSNnLPbshqDg@mail.gmail.com>
Subject: Re: [geda-user] A fileformat library
From: "Levente (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA User Mailing List <geda-user AT delorie DOT com>
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

--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&#39;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&#39;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&#39=
;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&#39;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&#39;d write it from scratch. But =
this just my view.<br><br>Yes. Open source is about like this: &quot;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...&quot; 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&#39;=
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">&lt;<a href=3D"mailto:karl AT aspo=
data.se" target=3D"_blank">karl AT aspodata DOT se</a>&gt;</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"">&gt; When selecting a file format I would not have such co=
nstraints like &quot;it<br>
&gt; should be pretty for a human eye&quot;. CAD data is so complex, that o=
ne can<br>
&gt; (and I believe should not) parse them with naked eye. For a computer,<=
br>
&gt; binary is much more efficient.<br>
<br>
</span>If we really are going the &quot;complex cad data&quot; route, I&#39=
;d head Peter<br>
Cliftons advice to use step. And if I&#39;d start programming with that I<b=
r>
wouldn&#39;t concider the price of the step-cd be of any consern.<br>
<span class=3D""><br>
&gt; So I still prefer the SQLite database, as that library is optimized fo=
r our<br>
&gt; purpose. Yes, I prefer to have a library, that parses our files, and g=
ives<br>
&gt; us the possibility to use, or modify the data. I prefer this way becau=
se we<br>
&gt; have approx. 50 different implementation of pcb/gschem file parser. Th=
ere<br>
&gt; is one in pcb/gaf, and all the other power users wrote their own. It w=
ould<br>
&gt; be much better to write the parser once, and other could use that. If =
file<br>
&gt; 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&#39;t which one is the best one, do you know ?<br>
Can we take that one and improve upon ?<br>
<span class=3D""><br>
&gt; If we use a standard file format (SQL, YAML, JSON), the parsing librar=
y<br>
&gt; could be very thin. The independent parsing code is already written. O=
nly<br>
&gt; the application (gEDA) specific code has to be written. Remember, all =
of us<br>
&gt; 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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019