[cad-linux-dev] Re: format as a mini-language
- From: "cr88192" <cr88192@xxxxxxxxxxx>
- To: <cad-linux-dev@xxxxxxxxxxxxx>
- Date: Sun, 7 Dec 2003 17:17:18 -0800
----- Original Message -----
From: "Janek Kozicki" <janek_listy@xxxxx>
To: <cad-linux-dev@xxxxxxxxxxxxx>
Sent: Sunday, December 07, 2003 12:18 PM
Subject: [cad-linux-dev] Re: format as a mini-language
> cr88192 said: (by the date of Sun, 7 Dec 2003 11:25:14 -0800)
>
>
> interesting discussion is going on here.
> I have small side note:
>
> > 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...
>
> I think, that when using directory data format, where each file holds
> separate information - and where one of these files holds 'geometry'
> information about certain objects (like the box above) we could:
>
> develop separate, non-depending on each other programs. Each of those
> programs can be written in different language (presumably the language
> most suitable for the thing that this program does). And those programs
> will be used to do-things on the data.
>
yes. there is then the difficulty of association of the data between
programs...
if one program builds the model and the other figures the physics, then it
is not so streightforward to tie them together (unless one relies on the
maintanence of "keys" between the files, eg, apparently the idea of "names"
mentioned by Eric so often...).
> One of those programs will "snap to grid", look how simple this program
> would be:
>
> $ snap_to_grid <grid_spacing> <geometry_file>
> or
> $ snap_to_grid [grid_x_spacing] [grid_y_spacing] [grid_z_spacing]
<geometry_file>
>
> it would just read the file and will round the values it reads to the
> given spacing. We don't even need to worry about accidental destroying
> all data, since whole textual data-directory is meant to be hold by some
> version control system (like CVS)
>
yes, maybe.
another possibility is a large (likely non-relational) database type
structure...
it can probably be argued that the fs and cvs can do similar (which they
can, though less straightforwardly), but I also (in my bag of
experiences...) have had experience tweaking out (and attempting to write my
own) database engines. the reason I call it "attempt" right now, is that I
never did get fully past loading/saving text files to contain all the
databases' contents, so my expierence actually writing code to manage large
sums of data, logging, transactions, ... is a bit on the "scarce" (closer to
non-existant) side...
> or if for some reason we want to square (take to the power of two) all
> coordinates in a drawing - it would be even simpler than "snap to grid".
>
> now. isn't that powerful?
>
yes, maybe.
sadly, I am feeling a bit burnt out and I still have crap I need to do...
Other related posts:
