Re: gEDA-user: Parsing and writing schematics with Perl

[fricker <fricker@xxxxxxxxx>]

On 21 avr. 08, at 02:53, Peter Clifton wrote:

> On Mon, 2008-04-21 at 00:05 +0200, fricker wrote:
>> Hi all,
>>
>> Is there a Perl interface to gschem I could use to:
>> - parse a given set of schematic (or symbol) pages and get a data
>> structure of the full (flat) design
>> - write back schematic (or symbol) pages given the same and modified
>> data structure (and do a backup first)
>>
>> I already have something working that uses Parse::RecDescent (see
>> http://search.cpan.org/~dconway/Parse-RecDescent-v1.95.1/, I wrote
>> the grammar specification as an exercise based on http://
>> geda.seul.org/wiki/geda:file_format_spec), but I know it might be
>> just Yet Another Gschem Parser... and was wondering if there was some
>> *simple user-level* API to libgeda I should be using instead (and  
>> how?).
>
> No, libgeda isn't ready to define any external and gauranteed API, it
> changes every release.
>
> Also, due to some technical problems with Guile (the scripting  
> language
> it uses internally), we can't (in general) write language bindings for
> it, even if we could make any API guarantee.
>
> I started writing YANGP for Python, but realised it was going to be
> tricky. My end approach was to write a C utility program which can  
> work
> with libgeda, then communicate with that program.
>
> gschem's file format is quite simple and easy to parse, it may have  
> been
> quicker to implement the parser, but that's not really the kind of
> coding I enjoy.

Reading you it seems to me that the gschem file format changes less  
often than a potential API in libgeda. I should therefore keep such  
parser/writer completely independent from libgeda and base it only on  
the file format. I.e. I went down the right path so far... Thanks!

BTW: Parse:RecDescent provides the extra benefit of error handling,  
it flags quite nicely if the file has errors and where, in a top-down  
fashion. I didn't write any parsing code, just its grammar.

>
>> Below is an example of such data structure output using Data::Dumper
>>
>> Thanks,
>> _jP
>>
>> data = [
>>           {
>
> ...
>
> [snip example]
>
> This kindof feels like a DOM tree in HTML / XML. If its a convenient
> format for you to process, it looks quite neat.

It's just the way Data:Dumper outputs an internal data structure of  
arrays [] of hashes {} containing string elements and other arrays,  
containing hashes, etc. I can just access things like this then to  
change the sheet number on every sheet of a design:

$data[$file_idx]->{objects}->[$object_idx]->{Attributes}->[$attr_idx]- 
 >{value} = $sheets++;

> What sort of processing are you needing to automate in this way?

Here is a short list:
- update/create sheet to sheet net cross references (with ~200  
sheets, this is a must have!)

- update current sheet number and total sheet numbers

- replicate similar subsections of schematics (a given schematic page  
used multiple times where you need to update refdes and netnames).  
Some might want to use hierarchical designs instead, but I stay away  
from such approach for board design!

- update component attributes based on an "Approved Device  
List" (output from a PLM database), i.e. add/update device=<part  
number> on passives based on value, tolerance and ratings attributes  
and verify the other active components

- design-wide component updates (with correct handling of attributes  
and symbol version changes)

- design-wide cleanup and checks (text size, alignment, location, not  
connected nets, etc., mostly to enforce drawing guidelines)

- generate multiple versions of a given root schematic based on a  
configuration file: simulation vs. prototype vs. production bom  
alternatives, each one having its own set of pdf, etc. I use a  
bom=1,2,... attribute to tag such alternatives in the root design,  
then change it to bom=NOSTUFF in the specific versions, this way the  
folks debugging the board don't have to look-up the bom options in a  
table. I then generate actual boms using gnetlist out of these  
derived schematic files. I also replace the CVS tags such that they  
look neat when printed.

- generate tagged pdf, with sheet to sheet net links and attributes  
pop-ups.

And all of this has to be controllable through Makefiles, this way  
the generation process is inherently documented for your coworkers or  
newbies.

I used to use Makefiles and sed s/.../.../ a lot but file-wide regex  
are dangerous since it isn't so easy to control what the s/.../.../  
is really going to change.

And I would not want this to be integrated in the gschem gui! gschem  
is - and IMHO should remain - just a drawing tool. It is far more  
powerful and convenient to control the above with perl scripts and  
Makefiles, including and especially bom handling stuff.

What I need to achieve all of this is a Perl module that offers:
- readFiles(\@files) that returns a reference to an array of hashes  
(file names are pushed into the data structure)
- writeFiles(\@data) that writes the data structure back into the  
files (file names are within the data structure already)

I could package what I have and share it if anyone is interested.

_jP


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user