Mail Archives: geda-user/2015/09/13/14:56:31
On Fri, 11 Sep 2015, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
geda-user AT delorie DOT com] wrote:
> Roland Lutz <rlutz AT hedmen DOT org> wrote:
>> The obvious thing would be to continue that scheme for PCB, too:
>>
>> xorn.storage - in-memory representation of PCB objects
>> xorn.pcb.read - reads .pcb files
>> xorn.pcb.write - writes .pcb files
>
> Is this something that's about to happen? If so I'll stop working on
> wrapping the parser from PCB.
It is definitively going to happen, but considering my current workload,
it may take anywhere between a few weeks and a few months. It may be
possible to work together on this, though:
> Speaking of the parser, I think the easiest way to get an accessible
> version of it would be to add a structure that corresponds one-to-one
> with what goes in a .pcb file. The parser could load stuff into that.
I agree; that was my first step with xorn.geda, too. You could manage
these data structures using the Xorn storage functions, or you could write
your own object list management code. (I'd obviously suggest using
libxornstorage--that's what it's for, after all--but I wouldn't mind if
you used other list structures since it should be easy to change this
later on.)
On Fri, 11 Sep 2015, DJ Delorie wrote:
> Add xorn just to be a reader/writer for pcb doesn't really add anything.
It would be the first step to a more thorough integration.
> Given how many discussions we've had about improving the data
> structure itself (which would be a huge job due to the amount of code
> that knows about it, even just switching to a xorn data), is this a
> path to simplify that?
I don't see a way around refactoring the PCB code so the data
representation is separated from PCB's internal data structures. This may
be split in small, manageable steps, though, as Britton has been
suggesting. Really, the difference to what I had in mind isn't too big;
making the code compatible with the Xorn libraries later wouldn't be much
additional work.
On Sat, 12 Sep 2015, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
geda-user AT delorie DOT com] wrote:
> So is this intended to consist of a superset of what's currently in a
> .pcb? If so, I think it's probably an ambitious mix of two different
> goals, one being a refactor of the parsing code the other an extension
> of the format. It might be best to tackle these one at a time, and I
> think the refactor should happen first.
Absolutely. These are two very different tasks, and mixing them is
probably going to make things much more complicated. When I was at the
same point with schematic files, I tried very carefully to fix some things
about the .sch/.sym file format; some worked well, but most things turned
out to be trouble later on.
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.
On Sat, 12 Sep 2015, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
geda-user AT delorie DOT com] wrote:
> As I mentioned in a previous post, I woulnd't try to keep a
> dot-pcp-equivalent data structure alive during execution of pcb, so
> syncing wouldn't be required. I would parse to the former structure,
> then destructively translate the result to PCBType (change ownership
> of it's pointer fields to PCBType instance).
That sounds like a reasonable thing to do. It would split the task of
introducing the new data structure in two steps: first, define the data
structure and port the PCB read/write code to use it; second, port the
rest of PCB to use this data structure.
Roland
- Raw text -