Mail Archives: geda-user/2016/01/06/13:12:12
On Wed, 6 Jan 2016 17:40:22 +0100 (CET)
karl AT aspodata DOT se wrote:
> Levente:
> > I'd make such API calls, for example move (change coordinate) of
> > object, add new, or iterate through objects.
>
> If you want scripting outside of pcb, then I don't know about
> anything currently available. If we make a simple parsing thing that
> gives you a parse tree, could that be something to start tinkering
> with. First is some header things, then a list of "Symbol", Grid
> setting, Vias, elements, then list of layers which contains lines,
> arcs, text and polygons; followed by a list of nets. Given that you
> could do something like:
>
> pcb.read(myfile.pcb);
> pcb.layer[1].line[14].x1 += 122;
> pcb.layer[1].line[14].y1 -= 33;
> pcb.export_ps(excellent_design.ps);
>
> one could implement search queries:
>
> my_line = find_line(pcb.layer[1], x1 > 299 && width < 13);
Yes, this is what I am thinking about.
> in whatever language you'd use.
>
> Would that be something ?
Yes!!!
> ///
>
> For scripting, why don't you try out Igor2's pcb-rnd, he has
> implemented scripting. See
>
> http://www.delorie.com/archives/browse.cgi?p=geda-user/2016/01/06/06:44:34
>
> and report back goods and bads.
The main reason, is that I couldn't compile it on my FreeBSD box. By the way,
I'd use LUA as scripting language. It is very easy to run a LUA script within
a C/C++ environment.
> ///
>
> Or, you can help by looking through action scrips and see what can be
> improved. I tried this little script
>
> Select(All)
> Mode(Move)
> MovePointer(100, 100)
>
> but I got ":unknown action `MovePointer'", so a lot could be improved
> there.
I do that too, and I like it. I have a script that generate PCB action files
to automatically generate panel PCBs. It works! :-)
> ///
>
> Can a plugin solve your need, I don't know much about pcb's plugins.
The thing is, when I am doing stuff with PCB, I have my hardware engineering
hat on. Writing scripts is okay, but I don't want to hack plugins. I could,
but I don't think this is the way.
> > If we talk about SQL implementation,
> > that would be fairly easy to implement with SQL queries inside the
> > library.
>
> Well, now you are talking about bypassing the lib :)
No. What I wrote, that those API calls would call simple SQL queries. Of
course, if the underlaying file format was an SQLite.
> But given a parsetree, it wouldn't be hard to export it to some sql
> and do queries there, somehow correlate what's in memory with the
> answer or import from sql, do your stuff, and then save it.
If the file format is not SQL, than it makes no sense to convert it to SQL.
Lev
--
73 de HA5OGL
Op.: Levente
- Raw text -