Re: thought on cad...

"Gernot Frisch" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > quite likely my language will be much better for maintaining/working
> > with/rendering the object graph, I will likely do the lowerlevel
> drawing
> > bits in c. I am not sure exactly where the division should be, eg:
> should c
> > just handle poly's, or should my primitive drawing be done in c?...
>
> Do whatever's handy for you and gives faster progress/better results.
>
a problem: right now I lack a specific use for it.
I had gotten discouraged by all the seemingly better programs around (with
better interfaces and a lot more primitives/file-formats...).

> > I am presently viewing my chances of success as low, or at least
> until I can
> > get it at least basically working...
>
> If you start a CAD program, consider the following:
> Write an engine that has a stack with objects (type, data) and each
> command calls som sub-commands like:
> Line:
> [getpoint], [getpoint], [pop k1, pop k2, drawline k1-k2]
>
> This way the user can define own scripts and extend the cad program
> easily. Next, the getpoint command can call a relativepoint command,
> that again asks for a point + 3 delta coordinates and so on. AutoCAD
> uses this technique for a long time now. They force sellers to hide
> this window when presenting to architects, but hey-this is what made
> AutoCAD successful. It's easy to implement and very very extendable
> for newer features.
>
yes, this is a cool idea.

my idea so far for extensibility had been to allow scripts to be written in
my language (a scheme variant, aka: a lisp), which could define new
primitive types, and maybe different file formats and such.
a problem thus far was the lack of a repl, and I have recently been off
working on my compiler/interprer system (then getting distracted by message
passing and threading issues, as opposed to core system and integration
ones...).

at least now it should be possible to integrate the interpreter with
toplevels based on the compiled version, and to dynamically define new
toplevel bindings and such (or at least, a lot of the basic stuff exists,
work will be needed on the interpreter).
another idea is to allow the user to decompile builtin functions (or more
like: look at the attached source for the original),  and to allow them to
reassign top level bindings to new functions (most likely interpreted, thus
causing a bit of a performance hit...).

what I have:
(almost) first class environments for the compiled version.

important things still needed:
closure (function) compatibility;
actually integrating the top levels (needs previous, eg, so interpreted code
can actually work);
integrating the object systems (so compiled and interpreted code can share
objects, as opposed to just primitive data).

for now eval exists as a feature for interpreting code, but eval is limited
and not very efficient...

> BTW. Consider writing a filter for GLBasic 3D .ddd format? Contact me,
> I'll give you the source code for GLBasic .ddd 3D files or write a
> plugin if you want to.
>
ok, I will look for info on this...

my cad is not sufficiently developed thus far to have extensions (unless
they were loaded as dll's or something).
last week I got the easy stuff, for now the compile system is a hard bit,
then it should be easier...