World: r3wp

shadwolf, it certainly is frustrating, but I'm sure Gabriele knows 
what other things he can do in the meantime. I have my hands full 
at this time, so I don't have to sit around and wait. It suits me 
fine schedule-wise that VID3.4 is delayed.

Don't hold back Brian.

yeah btu as the intregartor and the main coder is Carl he always 
will have the last word and we will be always pending for him to 
release the new things

So we DO need more Carl's.

shadwolf, that's why we need to find autonomous projects, such as 
protocols.

It just seems that R3 develpment dances from one area to another 
- never quite finishing one before moving on.

R3 will eventually need them anyway. Why not get them written now?

you can propose as many code from non Carl since Carl don't do the 
integration the VM  don't advance faster

That's why I took over DevBase, for the most part :)


Of course we see how that turned out - I got even more overworked 
than Carl and DevBase development stopped.

shadwolf, no, but there will be less work afterwards on protocols. 
There will be enough work to do for about 50-100 developers afterwards. 
Or man-years or however you measure it.

ICarii yes but that always been the case hihihihihi .... I remember 
rebo 1.3 .... Mwuhahahaha  full amator dev .... oups sorry. So it 
first start as 1.3 is only solving the loooooooooooooot of bugs posted 
on rambo by the community then it turns to Ho and how about adding 
AGG  to ViD ? and then it was Hey I  have a big new thing REbSERVICE 
!!!! and ASync  .... Bhuuuuuuuuuuuuuuuuu

What exactly do you see that we need another Carl for? IMO his greatest 
gift to REBOL is language design vision and wisdom. That is not exactly 
the kind of thing you can cloud-source.

at the end it took  1  year of dev when originally we where expecting 
a 2 month dev ....

R2 isn't even half saturated in what can be developed for it. If 
we wanted to, we could produce a whole lot more for rebol.org than 
the few scripts that are put there. R3 will be far harder to saturate.

but who can deny that AGG or async or rebservice are cool stuffs

afk, 30 mins

Things i would like to see completed in R3:
1. AGG/Draw and richtext fixed.
2. Ports/async working 100% reliably.
3. Object system global/local completed.

unfortunately all these areas are currently a black box scenario.

I love AGG. but seems we don't do enough.  Like why not REBCODE integrated 
with the latest release?

rebcode is too unstable apparently

Also too slow. It needs some semantic redesign.

AGG/Draw in R3 is very powerful - but view limitations (transparent 
surfaces etc) seem to hold it back.  Again - rendering to an OpenGL 
surface might solve some of these issues?

It would be nice to get a 20 - 50x speedup from OpenGL :)

I think Opengl Is alliased T___T and unstable on unix/ linux (basicly 
because of the lack of ground constructor really optimised drivers 
and upto date ...)

OpenGL works great on Ubuntu for me

Opengl is too big for using 98% of the time 2D things

when you compare the size of OpenGL to win32 GDI.. you wont find 
a lot of size difference - only feature difference

ICarii Ubuntu don't even handle X windows on my Nvidia 6800 GTS etc.... 
Xserv just not start ...

Isn't OpenGl more comparable to DIRECTX?

yes the later versions 9+

ICarii that not on the DLL size that's on the memory RAM size used 
that's where the faty hides hihihihihi

I saw I project of a VM  based on OPENGL  for 3D interface it's name 
was IO  or something like that I stopped it as soon i downloaded 
it the helloworld was bigger in memory than in rebol

It just makes sense to have your compositing done on a video card 
rather than in CPU - and you will notice Vista / OSX both take this 
approach

but on the side way yes you can do filp the hello world over all 
axis  ^^

That's why X/OSX/Vista has been trying to centralize the OpenGL/DirectX 
rendering, to share the load.

the thing that OPenGL  is not rendering on screen anything It mainly 
offers matrix handling routines and GLUT does the rendering on screen 
...

its like having a toolbox ful of tools but refusing to use anything 
except the hammer in case of compatibility problems or bloat :P

i dont use GLUT with OpenGL - but rather call it direct - ive found 
GLUT is slow.

the other problem with rebol -> opengl is the data formating .... 
and all try to link opengl encounter that issue

but were getting a little OT from R3 here ;)

R3 could hook into the display list feature of OpenGL for compositing

not really rebol with 3D content was one of my first consern when 
i started coding in rebol 4 years ago

and to return to the main topic having an independant REBOL clone 
project can give us the opportunity to hum dig all those silly ideas 
we have  ^^

most of the ideas tho are outside core areas anyway and could interface 
back into R3

seems to be very much like OS design

all we are lacking in an internal messaging system for the messaging 
language's components ;)

It will be even more fun to work within the R3 framework. Did you 
know that user defined datatypes are planned to include support for 
user defined function types? You could write your own rebcode as 
a plugin.

You could retrofit R3 with another VM that would integrate with the 
existing VM.

Perhaps that sort of thing needs to be finished before even THINKING 
about view/vid/protocols..

having a rebol clone strong project can give us more skills and maybe 
lead carl to trust us more and open too alternative things like for 
example working on a new way to hook DLL  to extend rebol

we shouldnt need to hook dll :P Rebol is a messaging language - it 
should have interface handling built in :)