World: r3wp

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 :)

I'm sure I don't want VID improvements before of rebcode.... I want 
CORE with rebcode first... And I really hope that some release  will 
not be postponed just because there is no  new tree-list GUI or something 
else

exactly - Core is the infrastructure - let us play with kernel first 
...

Oldes - but maybe RT has real concern here. You can imagine there 
will be many requests for furhter improvements, bug fixes, etc., 
so that we can "steal" time from RT's resources and hence View could 
get even more postponed ... dunno ...

yes, I know... i'm very patient...

core with rebcode is a different thing from core with all the rebcode 
improvements that have been proposed.

there is so many proposed improvements? I thought that Brian requested 
few opcodes?

.... remembering when rebcode was introduced, Carl seemed to implement 
improvements in light speed :-)

even if there are only a few... it's still some time subtracted from 
other stuff. so i can't promise anything about that, especially since 
i don't know the details of everything.

Carl might be able to give you a much better answer...

Carl would have to visit us here from time to time, to get us a better 
answer :-)

The old versions are still out there, Windows only.
Not true!
rebview1350024 from 16-Oct-2005 is for OSX incl. rebcode.

My guess is, rebview1350042 from 14-Oct-2005 include rebcode too. 
Haven't tried it out though.

It's the first version of rebcode, you'll find in those. A later 
version was released for Windows, yes.

Geomol - does codebase for RPaint still exist? Will you resurrect 
the app once new compositing enigne with R3 is inplace, along with 
rebcode?

Pekr, yes and yes, I plan to complete RPaint, when I can.

Confirmed !! Linux REBCODE version is rebview1350042.tar.gz...Thanks 
  verify with 'print system/internal/rebcodes'

Now i only need the webpages [Opcode Reference] and [DEMOS] anyone 
has those cached?

Aaaaaiiiii that 1350042 version is a real old one ..but it has Rebcode.....

Geomol, those OS X versions predate the Great Renaming, so most of 
the opcodes are different.

Ditto with the Linux version, Rebolinth.

The Great Renaming happened with 1.3.60 - look for versions later 
than that.

yes i spotted that...but linux does not go further then December 
2006 unfortuneatly.. I think i have to deal with Rebcode thats limited 
on linux..at least I have someting that does assembly ;-)

Yeah, the OSX version, I use (which must be very close to the Linux 
version), is mainly for testing performance and playing around. Not 
for serious work.

o

why this code not work on linux  ?

f: rebcode [][apply j make [ image! 0x0] insert j 1 256 return j 
]

i use rebol2650042

micha, what exactly does it do? I don' t have access to that version 
right here.

Mich; I'm not real up on rebcode, but I don't think apply can't be 
applied to make.  Apply can't evaluate action! or op! types.  So 
for that part you'd want    m: does [make image! 0x0]  f: rebcode 
[] [apply j m [] return j]


Then; I've never got the series opcodes to work.  insert, change 
... none of those.  mold system/internal/rebcodes/insert makes it 
look like they are not implemented.


So I would    f: rebcode [] [apply j m []  do j [insert j 1]  return 
j]  to get your to work, but with the do it's not going to be rebcode 
speedy.