www.delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2015/09/11/22:39:19

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Fri, 11 Sep 2015 22:39:10 -0400
Message-Id: <201509120239.t8C2dAiO026962@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to:
<CAC4O8c_XFEAgyrokrwwavB0C+OjWXCB5xptkVwMx2i_t960qFg AT mail DOT gmail DOT com>
(geda-user AT delorie DOT com)
Subject: Re: [geda-user] shortest way towards parsing .pcb files outside pcb
References: <CAC4O8c_XFEAgyrokrwwavB0C+OjWXCB5xptkVwMx2i_t960qFg AT mail DOT gmail DOT com>
Reply-To: geda-user AT delorie DOT com

> Is this something that's about to happen?  If so I'll stop working on
> wrapping the parser from PCB.

It's not clear to me what the advantage of this would be.  Most of the
things that deal with pcb structures are either scripts that use text
processing (which could use a standalone parser), or pcb plugins which
have access to the full pcb data structure anyway.

If we were to add xorn as a scripting engine to pcb, it would need to
be integral to the core data structures so the scripts could affect
the live data, which would be a huge task.  Add xorn just to be a
reader/writer for pcb doesn't really add anything.

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?

- Raw text -


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