[cad-linux-dev] Re: format as a mini-language
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: cad-linux-dev@xxxxxxxxxxxxx
- Date: Sun, 7 Dec 2003 11:53:16 -0600
> The following was supposedly scribed by
> cr88192
> on Sunday 07 December 2003 02:04 am:
>assertions:
>many "common" features (eg: destructive operations, quite likely io, a
>general type system, ...) would not be necessary;
>hopefully geometric primitives and collections of primitives (eg: unions and
>such) would be builtin;
>evaluation semantics may be very much like macros (primarily consisting of
>replacing function calls with expanded geometry);
>..
>
The issue is how you expand the geometry. On-screen display vs FEA will
require very different types of expanded geometry. For this reason, I think
the expansion is best left to the running code (via a library of course.)
>the language would hopefully be readily understandable by users as well.
>it need not be directly usable from a cad program, I was expecting something
>along the line of a tool you feed scripts into and it spits out models...
>
There is going to be a set of trade-offs between several things involved here.
For starters, you have compactness vs readability/parsability but note that
even these are not necessarily traded-off directly. Robustness is going to
come mostly from simplicity and transparency, but the way you approach
extensibility can kill the robustness (among other things.) Also, simplicity
can kill extensibility. It is like one multi-variable equation with all of
the variables unknown.
>I am feeling like the only way to get a good idea of how it might work might
>be to try to design it, but quite possibly others have done similar
>allready...
>
Sure. VRML, HTML, PostScript, IGES, STEP. All of these are declarative
minilanguages. They give a set of instructions for how things fit together.
It is left up to an interpreter to parse-through the language and put it
together into something on-screen.
Right. So, if we already have all of these textual formats (VRML, IGES, and
STEP are just the tip of the iceberg,) why don't we have this amazing
interoperability and bazaar-style programming going on in geometry/
engineering? I think it is because of a lack of mindshare which comes from a
lack of incentive to stray from the straight-serialized data format. It is
much easier to design your own file-format which basically mirrors your
internal data structures. I'm know that there is more to it than just this,
but maybe Bruno and Massimiliano have more to say on this, since they have
each independently put together prototypes for possible solutions.
So, how do we get this thing rolling? We've had a few attempts to startup a
formalized specification coming just out of this mailing list, but I don't
think any of them have made it very far. I think a prototype implementation
or two would be the best approach (and have even begun this sort of effort
within the back-ends of CAD::Drawing.) Maybe if we can get Massimiliano's
xdraft and Bruno's (is it called "Draft"?) app to track on the standard as it
is developed, then I can parallel with Perl while you work in C? Might be
just as good to merge the Perl versions (mine and Bruno's) and the C/C++
versions. If we really want to make the new standard for interoperability,
what better way to do it than to have two implementations tracking on it?
I'm interested in what happens when we make the solid modeler and the
drafting programs use the same format. Maybe we can even get Art Haas to
work on PythonCAD in the same way?
--Eric
Other related posts:
