World: r3wp

Steeve, when Reichart posted that photo and you said I looked crazy, 
I was worried that my eye strain from the glare was showing in the 
picture. I couldn't see the picture, as I was in it. Having seen 
it now I should have been more concerned about how loose clothing 
makes me look 30+ pounds heavier. By the way, last week was the first 
time most of the REBOL community had seen me, or any met me.

As for whether or not I am crazy - not in any way that shows :)

Need another Devcon!

I could never afford to go before, but next time I might make it 
:)

Brian you are one of the two under the big wheel, but wich one ?

Carl needs a text guru to finish rich text editing. Anton?

Dide - look at picture name, you will decode it :-) But - BrianH 
is imo the guy similar a bit to the mixture of The Edward Scissorhands 
and Thec Cure singer Robert Smith :-)

Henrik - Anton or Gabriele. Gabriele did text handling for first 
VID prototype, and it was probably more complete, no? But of course, 
Anton is guru here :-)

Gabriele too, of course.

Pekr: thanks. Did not saw it ealier.

Don't forget Romano.

Anton, if he has time?

No, I mean, don't forget Romano's past contributions to early VID.

hmm... will that help anything?

I'm the mildly gothy one with the multicolored hair.

Yes, Brian, Good description !

Pekr one was not bad, especially regardings Robert Smith (but missing 
hair's color) :-)

I think Pekr doesn't see too many goths. I'm pretty conservative-looking 
by their standards :)

Pekr is right, when i saw Brian first, i thought, oh God i hope no 
one will give him a scissor...

I am really very happy and well adjusted, which weirds out my friends 
:)

he's already "cutting" our idea on R3 evolutions, so that he doesn't 
need to be more accurate

;-)

We are on the cutting edge :)

Oldes: Is there something new with Rebcode?


Nothing new, but your requesting it means that you don't remember 
the problems the old rebcode had.

The bad news:

- Rebcode didn't work in R2, it was unstable and frequently crashed 
REBOL, very pre-allpha.

- Carl is unlikely to make a build with rebcode because of the above, 
and because he is focusing on R3.

- R2-style rebcode would be slower in R3 relative to the speed of 
regular R3, partly due to changes in function word lookup.

- Any rebcode dialect for R3 would be incompatible with R2 rebcode 
on a basic semantic level.

The good news:

- R3 has features that will make it relatively easy to add our own 
rebcode-like dialect.

- Even though the R2 semantics wouldn't be good, there are more tricks 
we can do to get more speed.

- The main reason that we don't get as much of a relative speedup 
for R2-style rebcode in R3 is that R3 is faster itself.

BrianH - are you going to bring us Rebcode, JIT, or anything like 
that in the future for R3? :-)

Petr, read carefully... he is saying R3 is so much faster that you 
may not need it.

We will see. I'm not going to test it now as I don't have the latest 
R3 version. But I'm really looking forward to see the new R3 features.

R3 (at least publicly available versions) math is definitely not 
10x faster as rebcode was.

For math maybe we will be able to use C-ish plugins with R3

Maarten - you probably don't believe your own words, righ? Or are 
you going to write pixel manipulation in 'foreach or any other REBOL 
loop? :-)

I think R3 will be fast enough for all things you don't want to code 
in C

I'm looking forward to the reduce/into enhancement. In general we've 
had a lot of clever optimizations through better design, and I'm 
sure there are many more that can go in.

Small status update:

- CureCode is now the official bug tracker for R3.
- Clipboard now supports unicode. This took longer than expected.

- HTTP 1.1 has been degraded to 1.0 due to some problems with 1.1. 
Rebtalk will continue to work as always though. Maarten is looking 
into this.

- Carl is attacking font code (this does not involve altering the 
poor anti-aliasing unfortunately) and text handling, so text areas 
will finally grow up and act like real text areas. This makes Rebtalk 
usable for more than messages. :-)

- Also yesterday, code was added to allow cell based vertical and 
horizontal alignment of faces. It's interesting to see these changes 
in VID3.4: A new feature like this is rarely more than 5-10 lines 
of code, which is a sign of a great design.

- MAX-SIZE won't go away. Instead it might (I'm not sure Carl is 
convinced there is a problem) be split in two. It currently acts 
as both a pressure factor and maximum size for a face, which is the 
cause for most of its problems.

Pekr, making new execution engines for R3 is one of my goals, so 
yes.

Rebolek, math is not REBOL's strong suit, true. The speedup comes 
from other areas.

Maarten: I don't want to code anything in C :)

REBOL's syntax is bad for math - too verbose, too much required whitespace. 
We can do a better dialect than that.

Brian coul you give an example how  to  define a new execution engine 
in R3, i don't see the point

perhaps a work to do in the wiki

I can explain, but not give you code yet because it depends on user-defined 
datatypes and we don't even have the syntax for those yet.

ok i take it

Perhaps you have noticed that in R2 there are 4 function types, 5 
with rebcode builds: function!, native!, action!, routine!. Each 
of these behaves completely differently on the inside, but are called 
the same on the outside. This is because each of these datatypes 
defines a different execution model. R3 will have allow the user 
to create their own datatypes, and that includes function types. 
All a datatype needs to do to be a function type is to act like a 
function on the outside. How it behaves on the inside is up to it.

but in what langage will be writed the inner code of such new functions 
? (rebol, c, ...)

User-defined datatypes (UDT) depend on the R3 plugin model (that's 
not done yet either) and plugins are a REBOL module wrapper around 
native code. UDTs can be defined in REBOL code or a mix of REBOL 
and native.

ok

One thing you are missing is that the input data of the MAKE action 
of a datatype does not have to be the same as what is on the inside 
of the value created. That means that you could pass a block of code 
or string containing another language's syntax to MAKE and the datatype's 
MAKE handler can translate that data to whatever internal format 
it needs. This means we can compile.

this means we could compile some c code in the fly with something 
like tcc

Yes, that is one of my plans.

sounds sweet

The datatype's execution engine deals with the internal data that 
the MAKE handler creates, not the input syntax. This means that the 
internal data could be anything: bytecode, native code, graph structures, 
whatever.

You can't get a reference to the internal data in R3 like you can 
in R2, so no hot patching.