[cad-linux-dev] Re: testing: intro
- From: "cr88192" <cr88192@xxxxxxxxxxx>
- To: <cad-linux-dev@xxxxxxxxxxxxx>
- Date: Fri, 5 Dec 2003 20:51:27 -0800
From: Massimiliano Mirra <mmirra@xxxxxxxxx>
To: cad-linux-dev@xxxxxxxxxxxxx
Date: Sat, 06 Dec 2003 03:42:57 +0100
"cr88192" <cr88192@xxxxxxxxxxx> writes:
> Hey cr88192, glad to have you onboard, I have a vague recollection of
> interesting posts of yours on comp.lang.scheme. (I'm not a Schemer
> yet, but I spent the last 36 hours getting finally acquainted with
> Scheme, in its Gauche incarnation. It's not the fact that I'm seeing
> parentheses everywhere, and wondering how tail-recursive climbing the
> stairs is, that worries me, it's the fact that I seem to like it.
> Hmm.)
>
yes.
I also like scheme, such that my cad is being written in my own version...
> > I had seen some oppinions expressed along the line of using strictly
line
> > based formats. I am unsure of the exact reason (except maybe
ultra-simple
> > parsing and such).
>
> Personally, I favour line based formats because most Unix tools,
> programmers and programming languages are on very friendly terms with
> them. And, as we know, projects where everyone feels immediately at
> home are more likely to get mindshare than others.
>
yes.
this was my original reason for using a text format. after a little while
though, line based formats can get tiring (based largely that they have less
inherent flexibility).
indentation can make a text format editable at least (I don't remember if my
original format allowed indentation or not).
likely for a line based format it would probably be unreasonable in most
cases to expect the tools to obay the 80 char line limit. optimally there
should be no line limit, but practically 1024 should be more than most any
line should consume (then later it is reported that there are virused models
making use of buffer overrun...).
> I know (and love) the flexibility of s-exps, unfortunately it's not
> the way most tools, and programmers and programming languages are used
> to see the world.
>
yes.
I may switch back to a text format in accordance with this.
hmm, I will have to write another parser though, no big deal...
> > or maybe could make it look more like shell commands:
> > poly --xyzst --vecs "(-1 1 0 0 1) (-1 -1 0 0 0) (1 -1 0 1 0) (1 1 0
1
> > 1)" --texture "ex.tga"
>
> Interesting. The boundaries between code and data are already
> blurring... ;-)
>
yes.
maybe we see something, eg: bash-fm (bash, for models...).
combines geometric manipulation with all the joys of shell scripts...
maybe we start seeing models with the first line being something like:
#!/usr/bin/bash-fm
..
> > directory based models:
> > interesting, but I am not sure how practical it is (on most filesystems
it
> > would be quite expensive).
>
> Using the filesystem to me means two things:
>
> - not having to write immediately the part of the system that handles
> the hierarchical organization of objects (traditionally grudge
> work), and being able to skip to the innovative and interesting
> concepts at once;
>
yes, cool.
> - enabling programmers of any language to add their own modules
> easily; no more ``I'd like to contribute to this project but there
> are no bindings for my favourite language or they're not well
> supported'', or worse ``Modules can be written in this language
> only''. The basic requirement is being able to deal with text
> files, and just about every language can do that.
>
agreed.
this is part of my reasoning for text formats. the intent is that "bgbcad"
will primarily be kept as a hopefully simplistic modeling tool, and things
like conversion, rendering, ... will be done with external apps.
I do hope for extensions though, but largely these will be for the things
that are done within the cad...
> Note that I wrote ``not having to write IMMEDIATELY the part...''. In
> fact, it can be written and optimized ad hoc later, and made it so
> that it appears with a filesystem interface. This is limited to
> Linux, so you might not be as interested, but there are nice
> applications already, such as mounting remote filesystems on local
> directories via ftp or ssh, or even accessing P2P spaces such as
> Gnutella's with a filesystem interface:
>
> ,----
> | Package: lufs-utils
> | Description: Linux Userland Filesystem - utilities
> | LUFS is a hybrid userspace filesystem framework supporting an
indefinite
> | number of filesystems (localfs, sshfs, ftpfs, httpfs, socketfs,
freenetfs,
> and
> | nutellafs) transparently for any application. It consists of a kernel
module
> | which interacts with the VFS while the main part of the implementation
is
> done
> | in the userspace.
> `----
>
hmm, this one strikes me as pretty cool...
> ,----
> | Package: shfs-utils
> | Description: (secure) SHell File System mount programs
> | SHFS (sshfs) is a simple and easy to use Linux kernel (2.4/2.6) module
> | which allows you to mount remote filesystems using (secure) shell
> | connection.
> | .
> | This package contains mount/umount utilities for shfs kernel module.
> | You will need that module to make them work, either from a patched
> | kernel or building it from source (see shfs-source package). If you are
> | lucky, the module may already be available, watch out for shfs-module-*
> | packages.
> `----
>
>
> It works as a kernel module that presents the data fetched by a daemon
> running in userspace.
ok.
hmm, now I am thinking what stuff should be where.
it may make sense, eg, to keep things like entities and models in seperate
files.
as an example of quake mapping:
one is using the modeller to create, for example, the primary hull;
additional hull models could be in seperate modellers (these would hopefully
be visible with the main model so you can see where they go...);
yet another tool (or text editor) could be used to manipulate the entities,
and could overlay the entities/sub-hulls on the map (probably needing to be
"refresh capable" to try to keep it synced with the modeller...).
especially cool for game editing would be having an engine that can refresh/
reset the map without expecting you to exit first (or can reload parts of
the world showing changes in real-time...).
cool thoughts maybe?...
all for now.
--
cr88192 at hotmail dot com
http://sourceforge.net/projects/bgb-sys/
http://bgb-sys.sourceforge.net/
Other related posts:
