World: r3wp

<man my keyboard is rusty>

It didn't even make it as far as 1.3.3, let alone 2.7.

Yes pitty..well lets hope they have some surprices for us in R3 ;-)

I've been on the bench related to rebcode for a year, and I was its 
most avid tester. Waiting for R3...

MMmm pitty... i realy liked to kick some asm code around in rebol.. 
it all looked realy orgenized at the time..

and fast for what ive seen then..

well lets wait ...

R3 became a higher priority, particularly when it became apparent 
that the new runtime would make rebcode even better.

Im realy currious to see what comes out ;-)

Me too!
Must work, later...

cya..

BrianH: why you think R3 kernel will make rebcode even better?

BrianH, I remember talking about optimized functions for graphics 
output. I hope they get in.

Petr, in particular I was thinking of vectors, the new objects and 
a better security model. Hopefully better structs too, with rebcode 
support.

I'm hoping for better apply support too - rebcode's apply is so slow 
I found myself inlining functions by hand.

I also wanted support for more datatypes. I was looking at rebcode 
as a compilation target. It never mattered to me how it looked since 
I was only rarely going to write it out - most of my code will be 
generated.

I'm looking forward to the "BRIAN" NEW rebcode. : )

Brian - that sounds cool. Please bug Carl and Gabriele about Rebcode 
improvements ;-)

no need to bug me, i already want all that stuff. i guess it'll be 
3.1 rather than 3.0 though. remember 3.0 is only a couple months 
away...

3.1? sniff :'-(

the new stuff. basic rebcode will probably be in 3.0. but guys, we 
have priorities. you want vid improvements before of rebcode, don't 
you?

:)

Gabriele - NOOOOOOO - no VID improvements ....

I don't believe it can be complete, so let's forget VID, it has so 
many defficiencies, so it should be either completly redesigned (you 
can't easily just to "improve" VID), or forgot ....

we had this discussion during devcon (me, carl, nenad, cyphre, rebolek, 
max, etc.)

but I suspect typical scenario. There is imo no VID+ group active. 
It will be cooked behind the closed door, and then you will complain, 
that I will complain :-)

ah, and what is the result ...

?

my idea was: let's write something from scratch that uses all the 
good ideas from vid, glayout, rebgui, liquid and so on.

carl answer was, we need this RSN... no time for this. (others agreed, 
sort of)

btw - as you are close to RT - what happened (or will happen) to 
rebol's security schema? IIRC Josh was working on some document - 
was it only regarding plug-in, or did it influence also general rebol 
interpreter, rebcode, etc.?

so my answer was, well, let's improve vid, and at the same time develop 
the new system, so that we have vid (with resizing, liquid-alike 
stuff, more styles etc.) for 3.0 (or at worst 3.1) and we can have 
the new system later on.

With RebGUI state, although VID my be more free-form, I refuse to 
even touch the thing, which does not have scrollers with area, list-box 
is not indexed and it hilites two the same values, and tonnes of 
other problems ...

but there was no real agreement about what the new system should 
be. so... well, it's too early to say anything about it now. what 
we now is that we need something like vid for r3 too.

ok - different pov - do you expect current VID scripts to run with 
View 1.3? Will you "emulate" face aproach, etc.?

ah, with View 3.0

probably most will run... but it's hard to say at this point. it 
depends on the amount of time we have. keep in mind reichart is taking 
my and richard's time too.

ah, ok, there is a Reichart to blame. Reichart - where are you?! 
:-)

Gabriele, are you planning to follow up on the design document you 
posted when we talked R3 GUI design?

I wouldn't mind VID for 3.0. All my programs are VID anyway

I have heard Gabriele proposed to use rebservices for the 'feel part, 
which is imo insane idea :-) (would be slow imo :-)

i do plan on that - but only as long as carl agrees to that, and 
i need to show him some prototype to convince him it's not going 
to be too complicated.

what was Carl's reaction to glayout and liquid?

not rebservices directly, but just "messages" for events, so you 
can also send them thru rebservices.

ah, that makes more sense ...

he likes it a lot (liquidgl), but it's too big, so max will need 
to "distill" it a bit :)

that is, my idea (which carl agreed on, and i think others too), 
is that the app does not get a mouse click event, it gets a "button 
pressed" event. (not sure if the explanation is clear)

hmm, maybe we could use kind of devices for that, no? Events could 
be queued etc. :-)

chatting in wrong group once again .... :-)

yep, please move :)