[cad-linux-dev] Re: format as a mini-language
- From: "cr88192" <cr88192@xxxxxxxxxxx>
- To: <cad-linux-dev@xxxxxxxxxxxxx>
- Date: Sun, 7 Dec 2003 11:25:14 -0800
----- Original Message -----
From: "Eric Wilhelm" <ewilhelm@xxxxxxxxxxxxx>
To: <cad-linux-dev@xxxxxxxxxxxxx>
Sent: Sunday, December 07, 2003 9:53 AM
Subject: [cad-linux-dev] Re: format as a mini-language
> > 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.)
>
I didn't mean complete expansion, or that the expanded form will actually
"replace" the unexpanded form, but more like:
ok, this program will take the input and decompose it into triangle meshes;
this one will take it and expand it to a certain set of primitives;
this one to polyhedral structures;
another one to a set of drawing commands;
..
thus, some level of abstraction will be needed between the language and the
final form...
> >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.
>
understood.
I don't think I am that bad with my design intuition...
> >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.
>
eww, I dislike vrml...
html is ugly but ok.
postscript I thought was pretty cool.
iges, step, I don't know of these...
> 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.
>
yes, maybe.
> 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?
>
hmm, maybe I can try to handle both 2d and 3d cases (however, quite likely
the scripts will be vreating either one or the other...).
I am torn between a few possible general designs:
a lispy core (at least syntax, general model, typesystem, ...);
I have had good sucesses designing things based on this before, including a
few linguistics related things (eg: scripts that are run through programs
and generate text in specific languages, or at least sort of...);
this would require others trying to implement it to also implement a similar
core;
the evaluation semantics would likely signifigantly differ from lisp.
maybe I could use my (somewhat incomplete) "BGF 0.4" format as a starting
point...
I could use a different core design, ex, something more resembling shell
scripting (eg: more like implicit imperative operations on a background
state...). again, I could use a lispy syntax or a different one.
this could cost a lot more work.
I am less sure of the model I should base things on, so I will probably
start at least with the concepts of macros and sets...
oh yes, I now have it so that at least I can model basic stuff.
here is a dump of something I was able to model in it (basically a box,
formatting adjusted a little):
(bgf "0.4")
(cube origin: #(-0.010746 14.060932 0.010746)
min: #(-16.032238 -2.017948 -12.010746)
max: #(16.032238 2.017948 12.010746))
(cube origin: #(-0.010746 -13.921120 0.010746)
min: #(-16.032238 -1.957017 -12.010746)
max: #(16.032238 1.957017 12.010746))
(cube origin: #(-14.014289 -0.121863 0.010746)
min: #(-1.957017 -12.071677 -12.010746)
max: #(1.957017 12.071677 12.010746))
(cube origin: #(14.063159 -0.060932 0.056948)
min: #(-2.009403 -12.132609 -11.950686)
max: #(2.009403 12.132609 11.950686))
(cube origin: #(0.032846 -0.109488 -9.972505)
min: #(-12.054744 -12.082239 -2.045661)
max: #(12.054744 12.082239 2.045661))
(cube origin: #(0.036983 -0.082644 10.008678)
min: #(-12.054339 -12.100000 -2.008678)
max: #(12.054339 12.100000 2.008678))
this is just what it spits out thus far, later I want ot use a different
structure (eg: everything in unions...).
notice, my cad at present lacks a "snap to grid" feature...
oh yes, as opposed to strict formal arguments I was thinking of having it
operate in terms of properties, eg, all arguments are properly named.
I was thinking of using a system where, lacking specific definition, default
values are assumed for properties (and some can be required).
a line based format, though maybe easier to use for tools, would require a
lot more work to be done (at present I am relying on more general facilities
of my language for reading/writing models...).
all for now.
Other related posts:
