Mail Archives: geda-user/2015/09/13/18:00:15
--f46d0445182ff3e899051fa81167
Content-Type: text/plain; charset=UTF-8
> On Sat, 12 Sep 2015, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
> geda-user AT delorie DOT com] wrote:
>
>> The standalone parser would be a much slower reinvention, so it was
>> suggested to use the one already in pcb. The idea is to ship language
>> modules that people can use to parse .pcb from their own scripts.
>>
>
> Also, it's important that the parser sees the same thing when looking at a
> PCB file as PCB does.
>
> The point is that a file should survive a read -> new data structure ->
> write round trip and still remain exactly the same. This isn't stricty
> true for xorn.geda since gschem preserves the (usually redundant) ripperdir
> attribute of buses even if there are no rippers left, but xorn.geda drops
> the ripperdir field and re-calculates it from the existing rippers at write
> time instead. If there have been rippers at some point, but they were
> deleted, the ripperdir field is written as zero. I think that's an obscure
> enough corner case, though, and the behavior of gschem is debatable in this
> point, so it shouldn't be an issue.
I suspect pcb has some similar stuff. Trace size setting in the config
file at least are normalized to pcb-preferred units, or clamped or
defaulted (or something, I'm not sure what) if they are out-of-range. So
round-trip-survival may be a slightly messy metric, making this migration
approach slightly less appealing. DJ can you confirm how this works with
respect to .pcb files?
--f46d0445182ff3e899051fa81167
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><span class=3D"">
On Sat, 12 Sep 2015, Britton Kerin (<a href=3D"mailto:britton DOT kerin AT gmail DOT c=
om" target=3D"_blank">britton DOT kerin AT gmail DOT com</a>) [via<br>
<a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delori=
e.com</a>] wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The standalone parser would be a much slower reinvention, so it was<br>
suggested to use the one already in pcb.=C2=A0 The idea is to ship language=
<br>
modules that people can use to parse .pcb from their own scripts.<br>
</blockquote>
<br></span>
Also, it's important that the parser sees the same thing when looking a=
t a PCB file as PCB does.<br>
<br>
The point is that a file should survive a read -> new data structure -&g=
t; write round trip and still remain exactly the same.=C2=A0 This isn't=
stricty true for xorn.geda since gschem preserves the (usually redundant) =
ripperdir attribute of buses even if there are no rippers left, but xorn.ge=
da drops the ripperdir field and re-calculates it from the existing rippers=
at write time instead.=C2=A0 If there have been rippers at some point, but=
they were deleted, the ripperdir field is written as zero.=C2=A0 I think t=
hat's an obscure enough corner case, though, and the behavior of gschem=
is debatable in this point, so it shouldn't be an issue.</blockquote><=
div><br></div><div style=3D"">I suspect pcb has some similar stuff.=C2=A0 T=
race size setting in the config file at least are normalized to pcb-preferr=
ed units, or clamped or defaulted (or something, I'm not sure what) if =
they are out-of-range.=C2=A0 So round-trip-survival may be a slightly messy=
metric, making this migration approach slightly less appealing.=C2=A0 DJ c=
an you confirm how this works with respect to .pcb files?</div><div>=C2=A0<=
/div></div></div></div>
--f46d0445182ff3e899051fa81167--
- Raw text -