World: r3wp

gabriele, the gradient is a little boring, but still a good demo. 
:-)

do http://www.rebol.cz/~cyphre/dotflowers.r

cyphre: great stuff

Glad to hear about the vectors!

Any chance of struct! support in /Core? It would seem that it could 
be even more useful in rebcode than in library access...

WOW Cyphre o_0 cool stuff

It seems to me that vectors would be useful to use when implementing 
Unicode support.

Nice, Cyphre :)

try adding a blur or other effect to the image in dotflowers. looks 
really cool :-)

only 20% of CPU on my 2.6 !

eats 45% here... show eats a lot on my machine for some reason

I'm wondering a bit if it's possible to do anything more direct than 
show. simply have a pixel buffer directly to put pixels in without 
the need for show

thanks guys...I agree Rebol should be able to use 'direct blitting' 
mode(bypass the compositing engine)

benjamin is it a celeron or pentium 4?

amd

cyphre, maybe that's why show is heavy? Show is very resolution dependant, 
so if I set the screen area to just 800x600, dotflowers becomes about 
half as fast, no longer smooth. If I go to 1280x960, I get about 
5-7 fps.

screen area = window size, sorry

yes, I have disscussed this with Carl on DevCon05. I hope we find 
a good solution to finally get faster blitting in View.

goodie :-)

Fungus function will fly on this baby

A couple questions:

- Are the exit and return opcodes still implemented with setjump/longjump 
?

- Is there still a plan to enable rebcode procedures to call other 
rebcode procedures, other functions? Or do we just use the do opcode 
for that?

These are questions for later answer, when sensible Americans are 
awake :)

funny that it still eats 45% if I set the wait to 0.01 instead of 
0.001. maybe show is simply waiting for itself to finish before it 
can redraw?

btw - will there be updated documentation for Rebcode?

Just poking around, and found a hint of things to come. There are 
more new (not working yet) data types in addition to rebcode! and 
vector!: percent! and unicode! are there as well. This should be 
fun!

Now if only struct! worked...

:-) do you mean struct in Core? It seems to me that RT is now working 
really fast and working on new nice things ...

cyphre, beautifull. :)

Very nice too !!

Brian: i think exit and return are implemented internally by wrapping 
a TRY around rebcode calls. About calling subroutines, that is planned.

about the rewriting: use the REBCODE-DEFINE function.

rebcode-define [
	my parse rule #==> production .
	my other parse rule #==> other production .
]

example:

context [
    slash: to lit-word! first [ / ]
    res: val: rest: mark1: mark2: op: rv: none
    value: [set val [decimal! | word! | paren!]]

    oper: ['+ (op: 'addd) | '- (op: 'subd) | '* (op: 'muld) | slash (op: 
    'divd)]
    rebcode-define [

        set res set-word! mark1: value some [oper mark2: value] (rest: copy/part 
        mark1 back mark2) #==>
            (res) (rest)

            (either paren? val [compose [rv: (to block! val)]] [ ])
            (op) (to word! res) (either paren? val ['rv] [val])
            .
        set res set-word! value #==> set (to word! res) (val) .
    ]
]

this allows expressions like:

f: rebcode [x y /local res] [
    res: x * x + (y * y)
    sqrt res
    return res
]

note that rewriting can also be used for optimization.

subroutines planned? For later or 1.0 rebcode release?

I guess for completion they will. But are soubroutines necessary? 
we can do everything with macros? dont know hw much overhead passing 
arguments would be.

dunno, just asking :-)

i think for release. but you should ask Carl.

Gabriele - what is the code above? You should not be so cruel to 
us novices - I've got a headache trying to understand, what above 
code does :-)

:-P

That stuff is not for novices. Use REBOL instead. ;)

And if you ever have to use rebcode, make sure you wear protective 
glasses. ;)

8-)

:-))

btw - can I "set-word" with rebcode? I mean - what if I 'protect 
word - does rebcode allow me to change its referenced value? Just 
curious :-)

dunno, i haven't tested. but i guess it does.

I just ran Cyphre's Dotflowers at 1600x1200 and it ran pretty good. 
 it ate 75-99% of my CPU but it worked.  While it was running though 
it messed up the OS's window layering somehow.  When I click on a 
window in the background it does become the active window but is 
not brought to the top of the window stack.

I thing that Cyphre is slowing down your PC intentionally for you 
just to not be blowed-out so imediatelly :-))

Uhm.  The window layering problem has nothing to do with how much 
the script was slowing down my computer because I killed the script 
and windows still isn't layering my windows properly.