World: r3wp

And that of course doesn't work. The datastructure has to be like 
this in REBOL:

vdata: [	
	[- X 0.0 Z] [X 0.0 Z] [- X 0.0 (- Z)] [X 0.0 (- Z)]	
	[0.0 Z X] [0.0 Z (- X)] [0.0 (- Z) X] [0.0 (- Z) (- X)]	
	[Z X 0.0] [(- Z) X 0.0] [Z (- X) 0.0] [(- Z) (- X) 0.0]
]


Maybe it's time to make a new group about this. I'm not home the 
rest of the day (beer festival going on), but I should have something 
for others to try out tomorrow (those who's interested).

enblock (reduce deblock data) 3

Some meazzines i use sometimes. But they are meazzines, if speed 
reeally is  an issue..

I could use NEGATE in stead of unary minus though. hmm

Volker, I've solved the reduce problem, and it makes sense now. The 
C function glVertex3fv takes a pointer to it's data as a parameter. 
I do the same thing in REBOL (using a block), and I then reduce it 
inside the REBOL function glVertex3fv itself.

Good idea. Also lazy, if you have lots of unused data its only reduced 
if needed.

That way the block can hold variables, that'll change, and only when 
the function is called, the block is reduced to values.

But make sure the datadoes not change in the meantime. The 'x etc.

Well, if the programmer wants it to change, that'll work too. :-)

Or that way around :)

heh, it works now. I get a icosahedron drawn. :-)

Congrats :)

Is there a way to mix it with the 3d-engine from the contests? So 
plain rebol could be used as 3d-editor?

YOu would get  a robot for free :)

Thanks! Actually I map from the pointer function glVertex3fv to glVertex3f, 
which takes it parameters as values, but that should be no problem. 
(I can't send a pointer to another task over tcp.)

What contests? What 3d-engine? :)

with /viewtop: rebol/contest/i-rebot.r

(I suddenly have name-blackouts) That great tutotial-writer has a 
little demo how to use the  engine IIRC.

http://musiclessonz.com/rebol_tutorial.html#section-21.9

Yes, it should be possible to call my OpenGL functions from an engine 
like that. That's the sort of things, I'm going to use this for. 
Only thing is, that the OpenGL window is inside a C execute, so you 
can't put REBOL controls (view stuff) in there. But you can then 
just have 2 windows.

One window with OpenGL output and another window with REBOL buttons 
etc. to control the thing.

I thought to use it for rendering too. Two modes rebol only with 
controls, or without 3d-card. and textures etc with real gl.

I think of a world ingl, with lots of models. and for editing a model 
can be picket into the rebol-window. (much smaller, rebol can handle 
that.) But maybe overkill and better concentrate on gl-integration?

We'll see, how fast this thing I'm building will be. I hope to be 
able to use it like you think of - having a world with lots of 3D 
stuff and be able to walk around and change things.

... all controlled from REBOL.

like in Jurassic Park!

I have just managed to patch FTP handler so it creates subdirectories 
recursively as needed. So code like this, which would fail before 
if the directory didn't exist, now works:
write ftp://user:[pass-:-server-:-dom]/my-dir/test "hello"

I'm announcing this because it took me a bloody long time.

You could fairly easily do your own recursive make-dir at the usual 
rebol level, but since the recursive mkdir is done inside the handler, 
the overhead of opening/closing/initializing ports is avoided.
Phew!  I'll publish that after some more cleaning and testing.

Isn't this a bit funny?

>> "x" = "X"
== true
>> #"x" = #"X"
== false

But luckily it works in e.g. SWITCH:

>> switch #"x" [#"X" [print "x found"]]
x found

Maybe
#"x" = #"X"
should be true in REBOL3?

SWITCH is implemented using SELECT without the /case refinement, 
therefore it's case insensitive.

It's possible to add a /case refinement to the SWITCH....

Makes sense, but should #"x" = #"X" be true? Comparing strings like 
"abc" = "AbC" is true.

Ah, maybe not. E.g. #"a" = 97 is true. #"A" = 97 is false. I suppose, 
this is the best behaviour.

Yes, char! is more close to integer....

Note:
>> "x" == "X"
== false

That's the more strict-equal, which turns off the case-insensitive 
equality of strings.

I would expect chars to compare like strings, but maybe that breaks 
things now.

mixing case/no-case comparisons can give surprises, and till now 
i nevernoticed that extra rules. good to know.

Better to keep the simple behaviour we have now with char equality, 
I think.

Anyone processing strings from different code-pages would be driven 
crazy by case-insensitive char compare.

Look at this ticket, "'select with a char! is not consistent":
http://www.rebol.net/cgi-bin/rambo.r?id=4046&

its not about simple, its about expected. a char is a char is no-case 
by default evrywhere, "=", 'parse, 'find, to-char - no wait.

(parse converts chars to strings internally..)

I dont look into the internallies all the time ;) On some occasions 
i am lazy and expect similar things to work similar.

But you could be right. At least there is scope for moving the simple 
equality test to strict-equal ==

Well, now is the time to lobby for such changes in Rebol 3.

That's a pretty fundamental operation, so we want to fix that in 
place pretty early.

Agreed.

What is the best way to distingisch text/binary files? list of suffixes 
for "is text, everything else binary", "is binary, evwerything else 
text"? Other ideas?

- Read a part of the file. If every byte is ASCII (or 8-bit), it's 
text, else it's binary. This is only a good guess, of course!

- Many types of files have some header information right at the start 
of the file. Make a list of those headers. (I think, this is the 
way, many datatypes works in Amiga OS.)

Good ideas.