1. Can you tell I'm replying to the whole digest too?
Okay, I'm going to adopt this method of replying, rather than write a whole
bunch of posts. Don't sue me. :)
[Enum and Namespacing]
~~~~~~~~~~~~~~~~~~~
From: Ralf Nieuwenhuijsen
>I'm in for enumeration: (would solve the namespacing problem for most
>constants!)
I like it too. Preprocessor can turn it into constants, but that
doesn't solve the namespacing problem.
My own solution... In the include file I'm currently working on, I
simply don't use globals. The only global symbol is the main procedure.
Everything else is passed as parameters from one function to another. That
means a little extra code to check the length and values of stuff, but not
really too much. Still...that can't always be done, I know.
My next idea is not a solution, but possibly a help. A 'View Globals'
function for the editor. Should show all global constants and variables in
the current file, and indented beneath that, all globals in each included
file (nested down properly). At the click of a mouse (or tap of a key) you
could see whether the global you're about to define will cause a conflict.
Also a mod to the 'View Subs' function so that it works the same way,
showing all routines in the current file as it does now, but with a mark
next to global ones, and indented beneath that, all global routines in
included files.
That's one nice feature my C++ IDE has. Not a full solution, but it'd
help. Speaking of EE here, btw, though it could be done for the other
editors too.
>PS About the moral guide lines in EDOM2, please don't respond on the list
>server, or better yet forget about them
Eh, I don't agree with all of 'em, but they're much better reading than
most licensing agreements. :)
[Euphoria's Strong Suit]
~~~~~~~~~~~~~~~~~
From: Mathew Hounsell
>It's flexibility.
No doubt. And slicing, sorting, and matching capabilities. And the
lack of a need to jump through hoops and trick the compiler (most of the
time).
[SVGA test]
~~~~~~~~~
From: David Cuny
>SVGA modes cause my machine to lock up (I hope someone can
>find Robert a "safe" SVGA test).
I wrote a function awhile back that uses an interrupt to get the video
card manufacturer data and supported SVGA modes... It does that without
actually setting any modes, so it shouldn't crash the system, but right now
it only checks for VESA 2.0 compatibility. I'll clean it up and rework it
though so it steps up from VGA (or CGA?) and returns any available data that
can be gotten without changing any settings.
[Databases]
~~~~~~~~~
From: Irv Mullins
>There are two ways I can think of to solve the problem:
>1. Create fixed-length records on disk, then you can do
> reads and writes of single records (using seek, and
> perhaps sorted index files)
>2. Use doubly-linked lists - but this wouldn't be efficient with
> variable length records, either, come to think of it.
1. Ignores Euphoria's abilities with dynamic data. Useful if you only
need fixed-length data, but no good if you want variable-length graphics or
memo fields in your records.
2. That's as far as I got on my own experiments with dynamic database
file structure.
I realized that if a record in the middle had a string field, and you edited
it, you'd have to rewrite the rest of the file as well as that record, and
recalculate all the offsets. But then...
>Anybody have a better idea?
The PDF file format uses dynamic-length data objects. Instead of a
doubly-linked list, it keeps a crossreference table at the end of the file
listing the offsets to each object in the file, as well as the deleted/in
use status of the object. The cross-reference and the current object are
the only things you have to keep in RAM. If you want to load another
object, you just look it up in the table and seek to it.
To add a new object (record) you simply append it to the end of the
file, then append a new cross-reference entry for it, and the offset of the
last cross-reference table. (The cross-reference is a sort of reverse
linked list, you read it starting from the end) Trouble is, anytime you
edit an object, you have to append it too, and a new cross-reference entry
for the old copy of it marking the old one as deleted. But the old object
stays in the file. This works, and you can undo and redo any edits easily,
but it makes the files grow tremendously if you do a lot of editing.
I think a solution would be to use that method, but rewrite the file
after every x edits/additions only writing 'in-use' objects and their
cross-refs. That's what I'm gonna try to do when I get back around to
working on my database routines.
From: Daniel Berstein
>I'm glad there's another user that's seems to be interested on Euphoria for
>developing non-games apps.
It's evolution in my case. I started out to create a flexible
wargame design kit/engine.
I realized I'd need a flexible database for unit/terrain/weapon system
data. Got frustrated with that one day and decided to take a break from
that and think about how the docs would be done.
Decided hyperlinked PDF would be the best way to go. But I could not
find a PDF editor anywhere on the 'net for download. So I looked up the
file structure and realized that an editor, or at least convertor is quite
doable. And a similar structure would be great for my database, but could
also be useful for a general-purpose database.
I've found some c source to help me with that, so now I'm poised and
almost ready to start working my way back to my goal. I'm in it for the
game, but if that requires routines that can make a decent database and PDF
editor/convertor...hey, that's a bonus.
As Dirk Gently might say, "The interconnectedness of all things in the
universe."
Falkon,
thinking it's time to go get something finished so I can make a contribution
instead of just talking theory..
