Newbie question: Sub-interpreters for CAD program

[Guest]

Hi all,

I'm a newbie to Python, so I have a question about writing an
application that also has a scripting ability. I'm thinking of Eric3
as an example. It's written in Python, but it also has an interpreter
window. The user doesn't have access (I don't think...) to all the
internal stuff that makes the IDE work.

In my case I'd like to write a CAD program which allows the user to
write Python scripts, and to provide an API to do CAD stuff, manipulate
parameters, circuits, layouts, simulations, etc. The user should not
have access to the internals of the CAD program itself. The CAD
program is written primarily in Python, with possibly C++ extensions
for speed critical stuff.

There is another posting currently asking about how many interpreters
are needed with how many thread states each. Since this is new to me,
can someone please explain how this sort of thing is "supposed" to
work, from a high level?

I have a strong EE and hardware background (hence my need to write a
CAD program that doesn't piss me off), but not a CS background.

Thanks
Michael

 

[Terry Hancock]

In my case I'd like to write a CAD program which allows the user to
write Python scripts, and to provide an API to do CAD stuff, manipulate
parameters, circuits, layouts, simulations, etc. The user should not
have access to the internals of the CAD program itself. The CAD
program is written primarily in Python, with possibly C++ extensions
for speed critical stuff.

This is a straightforward case of "embedding Python". You'll want to
google for that and do some research on it.

You could also choose to make your CAD program a library, and use
Python to control it, accessing the C/C++ layer via something like Pyrex.
That's a fundamental design decision obviously.

There is another posting currently asking about how many interpreters
are needed with how many thread states each. Since this is new to me,
can someone please explain how this sort of thing is "supposed" to
work, from a high level?

Frankly, I can't imagine why a script in a CAD program would need to
use threads at all. Keep it simple (here I'm assuming that the heavy-lifting
is done by your C++ code, so Python wouldn't have need of such
optimizations).

I have a strong EE and hardware background (hence my need to write a
CAD program that doesn't piss me off), but not a CS background.

Cool. If you do write it and release it, I'd be interested in finding out
about it.

You probably ought to consider starting with something existing like
the Gnu EDS project -- but I'm assuming you probably already know
about that.

Cheers,
Terry

 

[Peter Hansen]

Cool. If you do write it and release it, I'd be interested in finding out
about it.

You probably ought to consider starting with something existing like
the Gnu EDS project -- but I'm assuming you probably already know
about that.

Or even http://www.pythoncad.org/ which, although probably for
mechanical CAD work (I haven't looked at it, don't really know), is
surely a good place to get ideas of what Python can do in this area.

-Peter

 

[Terry Hancock]

Or even http://www.pythoncad.org/ which, although probably for
mechanical CAD work (I haven't looked at it, don't really know), is
surely a good place to get ideas of what Python can do in this area.

No, I doubt it. PythonCAD is a 2D mechanical CAD drawing system.
I don't think it would be anywhere near what this guy wants. They're
just different applications. He's looking for an electronic CAD system or
EDA, I'm pretty sure (or looking to write one, rather).

Anybody that says he's not "looking for a CAD program" but "looking
for a CAD program that doesn't piss me off" is probably a power-user. ;-D

Not a reflection on PythonCAD, though -- it's a pretty cool project,
I recommend it to anyone interested in exploring general purpose
2D CAD drawing systems. Among other advantages, it is written in
Python, so probably somewhat easier to script (haven't tried, though),
and it uses a self-defined XML format for CAD drawings, which is an
interesting standards move, given that free CAD formats have hitherto
been pretty limited, leaving professionals stuck with proprietary binary
formats, and not very happy with them (there are technical reasons for
not liking the DXF format which is a free format, albeit created by
AutoDesk).

At present I believe that PythonCAD is about on par with QCAD, but
I'd bet on PythonCAD for potential, because of these design advantages.

Cheers,
Terry

 

[Peter Hansen]

No, I doubt it. PythonCAD is a 2D mechanical CAD drawing system.
I don't think it would be anywhere near what this guy wants. They're
just different applications. He's looking for an electronic CAD system or
EDA, I'm pretty sure (or looking to write one, rather).

As an engineer who's worked extensively in both kinds of systems
(primarily designing microcontroller-based circuit boards), and a
programmer who's stolen useful ideas from endless amounts of other
people's code, I'll say only that I disagree with your implication that
looking at PythonCAD will give him no useful ideas whatsoever about how
certain aspects of CAD programs could be handled. PCB layout programs
do, after all, have to do the basic work of displaying circuits (which
as you know are generally shown as 2D drawings).

-Peter

 

[Terry Hancock]

As an engineer who's worked extensively in both kinds of systems
(primarily designing microcontroller-based circuit boards), and a
programmer who's stolen useful ideas from endless amounts of other
people's code, I'll say only that I disagree with your implication that
looking at PythonCAD will give him no useful ideas whatsoever

Heh. Well I didn't use the word "whatsoever" did I. ;-)

No you're right, if you're looking to write code from the ground-up, then
it's certainly true that this would help. But I pointed him at Gnu EDA,
because it already seems to do *most* of what he was looking for, I think.

There's also PCB and zcircuit to be considered. All of these are C language
programs, I believe, and he's already an experienced C/C++ programmer it
would seem.

OTOH, PythanCAD serves as an example of why he might be better off
to *write* the CAD program in Python and use C/C++ extension modules
as needed, instead of embedding Python into a C/C++ application.

But I kind of got the impression he was attached to using C++ for the job,
which would not be *my* choice, but is certainly preferred by a lot of
programmers.

There is another, community-oriented reason for writing it in Python and
looking at PythonCAD, of course. It would not be unreasonable to write
an EDA/PCB/autorouter application that worked IN PythonCAD. That
would be pretty cool. It would also be a good way to leverage community
support for the project.

But I have a feeling this is not going to be the way the OP will want to go,
since he came asking only how to embed Python into a C/C++ application.

 

[Guest]

Hi,

Actually I was thinking of doing the bulk of everything in Python, and
then embedding a Python interpreter into the CAD program. Anything in
C++ would be to speed up critical things, like rules checking, etc. I
have looked at python cad (found it a year or two ago) and am inspired
by it; I'm glad someone's done the legwork, although it's a long way
from anything EDA related (well, the 2d stuff could be used for
schematics). I have also looked at gEDA and found it lacked the
"modern feel" I'm looking for. It seems people are stuck on batch
processing of text descriptions, and NOT integrating completely the
front-to-back design process. I'd like to write something that
(eventually) would actually have an install program and run like a
normal app, on Windoze or Linux. Most of my experience with open
source software is that it's not user-oriented. Finally, if I write
something that's cool, I may try to make money from it, which means I'm
not sure how much I'm going to want to release to the general public.
This means I can't use code from pythonCad, etc., if I want to keep it
propietary. I could make it free for noncommercial use. Anyway,
that's a long way off. My original question was about how to run an
interpreter within the interpreter, and whether that's what needs to be
done to have some scripting capabilities which separated the user's
code from the main application.

Michael

 

[David MacQuigg]

Hi all,

I'm a newbie to Python, so I have a question about writing an
application that also has a scripting ability. I'm thinking of Eric3
as an example. It's written in Python, but it also has an interpreter
window. The user doesn't have access (I don't think...) to all the
internal stuff that makes the IDE work.

In my case I'd like to write a CAD program which allows the user to
write Python scripts, and to provide an API to do CAD stuff, manipulate
parameters, circuits, layouts, simulations, etc. The user should not
have access to the internals of the CAD program itself. The CAD
program is written primarily in Python, with possibly C++ extensions
for speed critical stuff.

There is another posting currently asking about how many interpreters
are needed with how many thread states each. Since this is new to me,
can someone please explain how this sort of thing is "supposed" to
work, from a high level?

I have a strong EE and hardware background (hence my need to write a
CAD program that doesn't piss me off), but not a CS background.

Sounds like we have similar backgrounds and motivations. I have a
project started along these lines, but I haven't had time to work on
it for the last few months.
http://www.ece.arizona.edu/~edatools/
Project page
EDA Tools Projects:
An Open-Source Platform for Front-End IC Design cdp_tut01-a1.zip
cdp_tut01-a1.tar.gz
The goal of this project is an easily-learned, universal, open-source,
circuit design platform that will allow IC designers to use whatever
tools they want for design entry, simulation, and display of results.
The platform should provide a simple GUI, basic services such as
storage of tool setups, and should define a simple, standard interface
for each class of tool. Most of the work will be in documenting the
design and construction of the platform, using a simple scripting
language ( Python ) and GUI toolkit ( Qt ) so that others may easily
follow the pattern and extend the platform to support new and more
varied tools.
------

Take a look also at the MyHDL link from the main page. This is a
similar effort for digital design. Mine is mostly analog.

The discouraging thing about the EDA tools situation is that no matter
how loudly design engineers complain about the poor quality of the
proprietary tools they are using, there is very little interest in
participating in an open-source project. They just can't see how it
would ever do what their expensive tools do now.

There is a similar lack of interest in the academic community. None
of this is likely to lead to publications in scholarly journals.

 

[Terry Hancock]

The discouraging thing about the EDA tools situation is that no matter
how loudly design engineers complain about the poor quality of the
proprietary tools they are using, there is very little interest in
participating in an open-source project. They just can't see how it
would ever do what their expensive tools do now.

Yes. I think this is analogous to the problems with word processors and
office workers. The concern is driven I think by a fear of incompatibility.
It's certainly difficult to deal with the reality that many people in business
insist on distributing information in whatever nasty variant of .doc format
their word processor happens to spit out, and it's not easy to be sure you
can read it.

Similarly, if you can't read AutoCAD formatted CAD files in a mechanical
design business, you're basically screwed. That's a strong motivation to
keep using AutoCAD no matter how awful the program itself is.

It will take a really big, long-term push by a fair number of interested
people to give a free alternative a chance against such an entrenched
existing proprietary application. In the long term, it would be worth it,
but a lot of people have to back it for a long time, and that's hard to
organize.

There is a similar lack of interest in the academic community. None
of this is likely to lead to publications in scholarly journals.

I'm confused by what you meant by this. Are you saying that academics
are afraid of using or creating open source CAD tools, or that they have
a lack of interest in tools development, because it won't generate papers
(directly anyway)?

 

[Guest]

Cool, I went to the UofA for my MS in ECE, 2000. I did my theses under
Chuck Higgins. --
http://neuromorph.ece.arizona.edu/pubs/ma_schwager_msthesis.pdf

The tools we had were constantly underwhelming me, so I've been
thinking for years that a properly designed new toolset for students
should be marketable, etc. I'll take a look at your site (although I
think I may have come across it before.)

Michael

 

[David MacQuigg]

I'm confused by what you meant by this. Are you saying that academics
are afraid of using or creating open source CAD tools, or that they have
a lack of interest in tools development, because it won't generate papers
(directly anyway)?

It seems like a lack of interest in tools development, because there
are no new fundamental principles, sophisticated math, or anything
that could help directly and in the short term to get a publication.
There is probably also a perception, shared with engineers in
industry, that the complexity of these tools is inherent in the task.
It's OK for a full-time engineer to spend a few months learning the
intricacies of a poorly-designed scripting language that works with
just one tool, but not appropriate for students.

My hope is that we can get a few good projects to demonstrate the
utility of Python in doing sophisticated designs with simple tools.
Then we will have a foothold in the Universities. Next will be small
companies that can't afford a CAD department with 10 engineers
dedicated to tool setup.

 

[David MacQuigg]

Cool, I went to the UofA for my MS in ECE, 2000. I did my theses under
Chuck Higgins. --
http://neuromorph.ece.arizona.edu/pubs/ma_schwager_msthesis.pdf

The tools we had were constantly underwhelming me, so I've been
thinking for years that a properly designed new toolset for students
should be marketable, etc. I'll take a look at your site (although I
think I may have come across it before.)

A toolset for students is exactly what we need. Whether that turns
into a marketable product is a question for later. At this point, we
need a few people with a strong motivation to help students. Sounds
like you might have what it takes. Send me an email if you are
interested.

-- Dave