World: r3wp

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.

Petr, yes I mean struct! in /Core. I keep on having situations that 
could use struct! when I don't need libraries. For instance, conversions 
from external binary data encodings to internal REBOL values, say 
for file formats, network protocols, and so on. Now rebcode has added 
other forms of strong typing like the type-specific opcodes and the 
vectors. Having structs, their constrained field types, their specific 
data layouts, would be a perfect match for the low level operations 
of rebcode. They would be helpful later when implementing your own 
data types as well.

I've wanted struct! support in /Core for years. I even requested 
it from Feedback, before RAMBO was here. Should I request it from 
RAMBO as well?

Yes please, use RAMBO imo - if you feel it is important, fill it 
in ... also put your question in RT Q & A group here ...

that is why I think that things like timers, structs, image etc. 
datatypes belong in Core too ...

Gabriele, thanks for the info about the rewrite rules. That's an 
interesting way to lay them out - a little more traditional that 
I've come to expect from REBOL, but that #==> is unlikely to be found 
in REBOL code so its use to delimit the parse rules should work nicely. 
I look forward to trying it out!

but then I want tasking maybe and mixing it with timers here :-) 
well, just watching Carl's speach - did he mention plug-ins (language 
plugins)? And IIRC Reichart mentioned modularity ... hmm, hmm, looking 
at RebCode, watching the devcon videos, I think good times are ahead 
:-)

Actually, when I think about it, the flexible function call syntax 
of REBOL would be a bit of a slowdown to implement directly in rebcode. 
All of the operations now are fixed in arity and known ahead of time. 
One way to get that same predictable behavior in rebcode is to put 
the call in a block and assign the result - coincidentally this is 
the syntax of the do opcode.


Another way to do this would be to add something like an APPLY opcode 
with three parameters: A result param (word!), a function param (word! 
| path!) and an arguments param (word! | block!). This opcode would 
pass the arguments to the function (perhaps with refinements) and 
assign the result to the word provided. This would allow the higher 
order programming that would otherwise be awkward - the do opcode 
could be used for traditional function calls. If necessary, the operation 
could be split into two opcodes: APPLY for function values assigned 
to a word, and APPLYP for a path literal or value assigned to a word 
- whether to do this would depend on which was faster.


Another awkward thing to do in rebcode is getting and setting values 
through indirection, like the get and set natives do. Those seem 
like a really basic operations that should have opcodes assigned 
to them rather than having to resort to do blocks. I'm just thinking 
of the basic get/set word assigned to word scenario, not the more 
advanced object/block stuff.

Gabriele, you might want to change the compose/deep call in the rewrite 
rules generated by rebcode-define to compose. The current version 
might trip up makers of rewrite rules, like it does in your first 
example rule above in the (either paren? ...) clause. Let any further 
composition be up to the rule makers, just in case they actually 
need to use parens themselves.

Brian - you may add your 'apply request to RT QA group :-)

Well, I would hope that the RT people implementing rebcode might 
check the rebcode group every once in a while, but sure. I'll have 
to rephrase since it's out of context though.

BUG (possibly): The SETI and SETD opcodes don't work unless the variable 
has already been set to a value of the appropriate data type.

Maybe optimisation?

BUG: The decimal math opcodes can take an integer value in the second 
argument, but if that value is specified literally the syntax checker 
rejects it. The integer! datatype needs to be added as an alternate 
to the second argument.

Volker, that's why I said possibly. If so it should be documented.

REQUEST: I would like the LOG-2 opcode to be added to the existing 
LOG-10 and LOG-E. Log-2 is the only one of those I actually use regularly 
:)