World: r3wp

GLUT have many things, we lack currently in REBOL, like key-up events. 
Also some window-handling, mouse-handling, etc. I just suggest GLUT 
as a shortcut to have these things. In the final version, when all 
that C code is found for all platforms, GLUT can be droppen again.

GLUT is just some extra functions, that have same kind of interface 
as OpenGL OpenGL is just only basic graphics, where GLU and GLUT 
add things, that is used in e.g. games ... or in REBOL.

A list of all the functions is found here: http://pyopengl.sourceforge.net/documentation/manual/index.xml
Scroll down to see the GLUT functions.

GLUT also add joystick support to some degree across platforms, so 
for e.g. game writers, GLUT is a good library to use.

OK, thanks for info

You're welcome!

It seems to me, that many things, like keyboard, mouse, etc., will 
simply overlap with current implementation. IMO the question is, 
how well internall View si built already, if things in there are 
"chaotic", or layered/abstracted/isolated.

not very nice description of GLUT's internal state - http://en.wikipedia.org/wiki/OpenGL_Utility_Toolkit

SDL is more generally available than GLUT, and you can put OpenGL 
on top of it

In other words, GLUT provides some of the same functions as SDL, 
but with SDL, 3D is optional

we can link to SDL with Core, no? As others do. We can link to VxWidgets, 
if we wish to, no? View is simply yet another gui engine ....

I am not sure we can easily mix those things? But maybe we could 
use some of SDL code? It all depends upon its license ...

SDL is LGPL, so the R3 object files being available as planned is 
sufficient

AFAIK GLUT is simple wrapper which has been used mainly just to show 
some basic OpenGL demos. I'm not sure if this is a good  for usage 
in some 'real' crossplatform apps.

Regarding the OpenGL version of Rebol: this version is not yet worked 
on but I plan to work on it once the AGG based version is complete 
(as it this will give us much better big picture where the OpenGL 
advantages could be really useful in the visual system).

Cyphre - will there be access to buffer? Or is the OGL the thing, 
which will speed-up blitting, because it uses HW to draw?

IIRC there were planned so called View plug-ins, which would allow 
access to View buffer and plug-in HW accelerated display rather than 
current SW only renderer ...

... I am not strong on gfx, so I might actually confuse things :-)

AFAIK the plug-in interface is not yet finalized so it is too early 
to discuss ho this will be exactly exposed.


But there are more things to consider than the blitting. If you do 
SW redered graphics you need to render into the  backbuffer in the 
main memory then you transfer block(s) sing a blit to the gfx card. 
If you do HW accelerated graphics you need to transfer all bitmaps 
into the gfx card memory first..also you are limited by the OpenGL 
2D functionality (which is not so flexible and pixel perfect as for 
example AGG implemntation). Also setting pixels directly in gfx card 
memory is possible but this is surprisingly the slowest way to dorendering! 
Why? Because fur current PC HW bus architecture is such transfer 
very expensive operation comparing to moving one big block of data.

So as you can see all this (and lot of other issues) needs to be 
considered not to mention that the solution should be as much as 
compatible on most of platforms.

Once the beta is released it will give us good picture how to make 
the gfx system even more optimized and extensible.

(sorry for the typos..writing quickly ...now back to work ;))

There were three level of plug-ins mentioned in the past - browser 
plug-in, language plug-ins (as discussed at DevCon) and View rendering 
plug-ins (loaders/savers etc.) - I was talking about the third one, 
but not sure if those are not the same as language plug-ins ...

Do we need /dup refinement for APPEND, like we have with INSERT?

geomol, already there

Why aren't guys like Geomol already in? I mean - I don't want to 
be there, I was in 3 months testing period in my new job and had 
no time to test etc., but Geomol seems to be actively developing. 
I think such ppl could be there in the next wave ;-)

Pekr, I'm waiting for the beta at least. I'm too busy to be in there 
yet. I have private contact with Carl, so I could just ask him, if 
I wanted to.

ok, did not know that ....

from the outer pov, you seem to be rebolling - re your BASIC dialect 
...

Pekr, yes I'm rebolling quite a lot these days! :-) The BASIC dialect 
is done in my spare time. At work I'm doing a COBOL formatter in 
REBOL as we speak.

COBOL? Gee, who uses COBOL still? :-)

I do remember COBOL on some old CICS systems or so we had at my past 
company :-)

Still one of the most used langauges, if not THE most. Lots of COBOL 
code in big coorporations around the world.

I think a lot of banks use COBOL

Interesting. Because the most dominant ERP is probably SAP, which 
has two containers, ABAP and JAVA, but I think that ABAP is some 
99% .... anyway, probably off-topic here :-)

Yes, probably most banks, insurance, car manufactors, etc etc.

when I hear COBOL, I imagine those old green monochrome display terminals 
:-)

hmm ... REBOL fits the scheme ... the name REBOL sounds like REnewed 
coBOL :-)

:-)

Check some of the success stories from one COBOL solution company:
http://www.acucorp.com/company/success/

You could steal them to REBOL though. Starting with some wrappers, 
doing similar screens as VID skin, etc. :-) That could be good commercial 
enterprise REBOL start :-)

hehe, just reading Alianz success story. Those bank guys don't fear 
risking choosing non-traditional aproach. They chose AcuCobol with 
its own file system as a storage instead of relational database. 
Those IT ppl must be crazy, to run such a big house ... well, without 
SAP and Oracle :-)

Naa, not so crazy. The Vision file system used in AcuCobol is really 
really simple. Not much can go wrong, as with a huge database. And 
it's very fast.

does it have SQL interface to it? :-)

I'm not sure, maybe with Acu4GL (or is that the other way around!?). 
I haven't got experience.

now as REBOL will be there in form of both DLL and .so, we could 
try to "merge" rebol with some technology, to see how it works out. 
Then you could create specific dialects, which could help programmers/users 
life easier. Such a dialect would generate target code ...

Look under "Solutions/Data Access" at  Acus homepage. You'll find 
things like "Acu4GL" and "AcuSQL".

Pekr, good ideas! I'm a free-lancer, so find someone to fund the 
development and then contract me.

And I am the chief of IT of one supplementary pharmacy company :-)

Feel free to contact me in private, if you have contract work to 
be done involving REBOL.

Of course, currently we have primitive portal, home made, IIS, MSSQL 
and plenty of code ... I expect having SAP or WebSphere portal here 
.... I will think about possibility of integration and making life 
easier :-) It is still preliminary though, as having R3 in dll or 
so form is not enough - you have to somehow wrap other rebol-2-OS 
parts, etc.

my PPL never heard of REBOL. My plan is to move them to stronger 
portal, and I hope REBOL takes off in the future. We are currently 
too MS-centric (excluding SAP and Ixtent DMS). But in general - we 
should more think about such aproach with R3. IT has lots of new 
abilities for deployment. The best thing would be to have REBOL-in-JAVA 
imo, although that might be slow, dunno ....

So, very very theoretically, today is the day? :-) If there is no 
release for another let's say 2 - 3 weeks, maybe at least preliminary 
access to docs could be allowed? well, or another VID screenshot? 
:-)

Or maybe i nice security blanket with a REBOL logo? ;-)