World: r3wp

For example, vectors will let you create an optimal array of integers 
(unlike blocks).

Mostly useful for specific algorithms and use in rebcode VM.

But, note, not currently functional.

link is broken

rebcode8.zip (there's a typo above)... but, wait, we found a couple 
bugs ;)

New REBCODE release: www.rebol.net/builds/031/rebcode9.zip

;you can try:
do http://www.colellachiara.com/soft/Misc/julia.r

Carl:for some reason IE can not open/save rebcode9.zip-the page just 
gives me a blank icon ? But Firefox does work ! :)

Very nice Gabriele :)

Thanks for the answers to some of my questions! In summary:

- The set-word notation for setting variables doesn't seem to work 
any more, and the reason for the change to the set* opcodes is increased 
speed.

- BRAW is computed goto, but it is yet unclear what the value of 
the word is supposed to be. I'll test.

After testing and some guesses I figured out that the rebcode dialect 
is statement-based, although it can be converted from expression-based 
by the aforementioned rewrite rules. Also, the | in the declaration 
of opcode syntax refers to alternate data types, so that:
    skip: [word! integer! | word!]

means that skip takes a word! as its first argument and an integer! 
or a word! in its second argument.

After some digging, it seems that the inner block goto label problem 
has been solved. I'm not sure where Gabriele's user defined rewrite 
rules are to be set, but I'm still looking.

The syntax check in Gabriele's assembler seems solid at first glance 
- it seems to be automatically generated from the system/internal/rebcodes 
object, or both generated from the same source data.

There may still be ways to crash the VM using semantic errors (type 
mismatch and such). Testing...

So far, argument words with the wrong type of values assigned to 
them just seem to cause the opcodes to be skipped without complaint. 
Certainly better than crashing, but it could lead to the kind of 
errors that would be difficult to find without extensive unit testing 
or a type inferencer. Still, I'm pleased.

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.