World: r3wp

no objects in extensions...  


I was just thinking yesterday that a struct type in R3 could be a 
good idea now that we have extensions.  Carl could wrap it up quickly 
since structs only store and align data, no rebol code.


but I think I'll build a struct <-> block set of tools in C and REBOL 
for extensions in the meantime... this will be handy for sure.

thx for the info pekr & maxim. 

I thought that extensions will easy unlock the power of ready to 
use C libs/sources. 

but building wrappers on wrappers is the same like layers on layers. 
annoying... 

well, I am using rebol exatcly for this reason to escape from this 
paradigm! 

on the other hand there is a good change that I did not understand 
the power 

of extensions right now. building my own libs in C to speed up things 
is fine 

but easy use and access of precompiled libs or open sources (and 
there are many fine pieces out there) 

are much, much more important in my opinion. A swiss knife like rebol 
should be able 

connecting easy to as many other tools and components as possible.

I would wait a bit - maybe someone builds some R2 kind wrapper as 
an extension, so that producing extensions is easier :-)

yes, I will be doing that first thing after my current project is 
done.   I will be looking into SWIG, maybe I could use all of its 
advanced C language parsing capabilities and just add a REBOL export 
module to it  :-)

tombon:  the thing is that rebol has to map its datatypes to the 
basic and static data representations of C and other compiled languages. 
 the R2 tried to do this within rebol, but it ended-up being useless 
for many libs which used types that rebol cannot translate natively... 
like unsigned integers or single precision floats, arrays... etc.


extensions do the rebol datatype conversion in the C side, so that 
it can directly map ANY C code to a form that rebol functions can 
understand directly  and vice versa... so for now we could use blocks 
as an interface for structs, even though R3 doesn't understand anything 
about structs.  :-)  


Its MUCH faster to map in C and makes the lib completely integrated 
into REBOL when used.


So for example, we can use tuples as colors within REBOL, and the 
DLL's functions will be called with a struct  or an array, to map 
the 3 channels.

Does someone know if the R2 /Library (DLL mapping) component will 
be ported to R3, or at least open-sourced?

Some variant of it could in theory be reimplemented on R3, but it 
can't be "ported", so there's no point in the source.

I expect Extension to be a (cool) addition to REBOL, not a replacement 
for the /Library component. Even if limited, /Library is a very useful 
and working feature of R2. /Library allows to interface with most 
of OS API without having to code in C. This is a productivity advantage.

Direct support (including MAKE support) would be difficult without 
user-defined datatypes. You could do something semantically similar 
using extensions, with opaque handles for the types, and accessor 
commands for the rest. The declarations of the R2 version could in 
theory be compiled to extensions if necessary.

The problem with /Library support is that it's actually easier to 
write extensions than it is to write /Library wrappers.

Maxim's SWIG support would be more promising - then extension wrappers 
could be autogenerated.

I always thought that it was easier to write REBOL code than C code. 
Extension would require a C compiler that will generate an additional 
DLL (times the number of OS to support...). I looks to me more like 
a regression compared to R2 if /Library get trashed in R3 (unless 
someone provides a similar interfacing system). 


SWIG is huge compared to /Library. Having to provide the C header 
files is not always convenient compared to just declaring a routine! 
from online API documentations (like e.g. MSDN). I would prefer to 
keep having /Library in R3 for fast and handy OS interfacing, and 
the ability to build my own Extensions for cases where it's not enough.

It is easier to use REBOL code once you've written it (due to compiilers 
and such), but whether it is easier to write it depends on various 
factors. In the case of /Library, the data model was a weird subset 
of a union between the C and REBOL data models, and simply couldn't 
easily handle many C-compatible APIs, and no APIs that weren't C 
compatible (C++, Delphi, Java, Objective C, ...). Extension wrappers 
are actually easier to write than /Library wrappers, and will eventually 
be able to do much more. Of course, once they are written, your criticisms 
apply.

And one day we can create REBOL dialect to create the extension wrappers, 
maybe. :) But I agree with Doc, that it would be shame to loose the 
R2's functionality.

I've been following the difficulties and failures people have had 
over the years getting /Library to work for them. Good riddance, 
imho.

I've never been able to use it myself for anything I've wanted to 
wrap, except for SQLite (which someone else did).

I've used the R2 /library often and a part from mapping a few of 
the simple windows MAPI functions, I've never gotten it to do anything 
usefull and fantastic because there are simply so many discrepancies 
in types... callbacks crash notoriously and things like arrays and 
pointers are fudgy at best.


A part from the suggestions above, it is ALSO possible for us to 
build an extension which does dynamic library binding on the fly. 
 But that will require a bit more research to get working.  basically, 
we could build an extension which mimics and improves the /library 
system.

There are some /Library enhancement proposals from Ladislav in wiki, 
which might make it worthwile to have. If improved, you raise number 
of libraries you can wrap, and as Doc says - very easy to use for 
occassional linkage to the OS API functions here or there ...

maybe we could just implement Anton's COM lib stuff as an extension, 
then we get the full power of DLLs but embeded into Rebol... I haven't 
looked to closely at it, so I might be saying something really stupid... 
but worth investigating as one of the possible solutions.

Benjamin's COM lib

Max said "with callbacks (devices?), there is no need to keep bugging 
Carl about A LOT of things people keep complaining about.  :-)" - 
my question is - how callbacks/devices allow you to plug-in different 
scenarios into REBOL?


Let's take multimedia timers for e.g. AFAIK, events are part of Host 
code, not a device. So how can you e.g. create device, which allows 
you to replace inbuilt timers?


OK, maybe timers are not good example. We have networking being done 
as a device. Can you easily replace REBOL's built in networking device 
with your own one, to try some different networking aproach for e.g.?

Hmm, events seems to be implemented as Device model too? http://www.rebol.net/r3blogs/0084.html

yes... the DLL will trigger code based on how its hooked into the 
OS.... so if you used multimedia timers, they will trigger when you 
ask them to.  if we have callbacks, then Rebol code can be run as 
a consequence of that trigger.


tcp sockets use triggers to tell you when connection, data, etc occurs... 
you could very well use C sockets directly by opening a lib and calling 
its funcs... I don't know if the fact that the rebol task already 
opens up a tcp socket lib would cause some interference, its quite 
possible that it would work.


DB drivers often use callbacks for the "response" aspect of DB requests 
since most well designed DB interfaces should be async.


Events & callbacks simply allow applications to live in the wait... 
and be asynchronous in nature.  its the "better" model since it means 
the task is never busy waiting.  There is a large effort in the linux 
world to make every app behave "properly" in this regard, and its 
a good thing... if every app is silently waiting on triggers, the 
whole system has a significant boost in responsiveness.

the OpenGL,  GLut lib, for example, has its own windowing system. 
 so any application can VERY easily create OpenGL apps which respond 
to keyboard mouse and window events.  its ported on all OS, so your 
code runs just about the same everywhere.


If R3 had callbacks, my OGL GLass engine will be ported to all platforms 
without any extra effort.


GLut might not have all the fancy events (I haven't gone over it 
in detail) but its a good basis to develop, being so easy to use.

callbacks are also required for any serious windows api programming, 
so many systems use them.  timers, gui, disk, low-level gfx.

(oops strike disk from that list)

btw the capacity to open tcp sockets directly in C must be available 
in R3 extensions... I don't see why it would'nt work, but some systems 
require very specific TCP settings... one example is that the various 
buffers used can have drastic effects on performance in some circumstances 
and platforms.

ComLib: Using it quite often to control XLS. I hope to find the time 
to bite-the-bullet and givetti a try with a R3 extension. The current 
ComLib is good but fragile.

Overall R3 should have a /Library interface. IMO adding a way to 
Rebol so that more c-ish datatype can be handled would make life 
a lot easier. And of course, provide a way to handle callbacks. Maybe 
via a proxy stub on the C side that transforms these callbacks to 
TCP socket requests.

yet another possible target for extension integration  :-)

http://www.ogre3d.org/

and its licensing is switching to MIT  :-)

I actually will give this engine a look, its ported to all 3 platforms, 
and can render over OGL OR Direct3D which is pretty nice.

it even has an iphone port  :-) this is starting to be really interesting.

OMG... its HUGE!

(http://www.ogre3d.org/docs/api/html/hierarchy.html)  but extremely 
well documented...

the most interesting feature: "Currently OGRE runs on Windows, Linux 
and Mac OSX using plugins to drive the underlying rendering API (currently 
Direct3D or OpenGL). Applications use OGRE at the abstract level, 
thus ensuring that they automatically operate on all platforms and 
rendering subsystems that OGRE provides without any need for platform 
or API specific code."


and its open source, and the quality of graphics is quite impressive.

Interesting question on R3 Chat - is it possible to transfer opened 
file handle from REBOL to extension, or does file have to be reopened 
in extension and worked on from there?

maxim yeah like the name said it's an ogre

Ogre3D is the probably the best open source 3d rendering engine there 
is .. I followed it's path a long time..  his simpler "follower" 
is irrlicht .. maybe there are some new ones now I am not sure , 
since I am not actively following this area any more

http://www.devmaster.net/engines/

Maybe OpenAL and OpenCL could get extensions too.

like this one ... it seemed very intreresting and with pure c interface 
so it's meant for embedding 

http://www.horde3d.org/

thanks, will look it to it too... although I have anidea for the 
ogre...  using "." for the member separations  :-)

ex: Ogre.FreeImageCodec.startup


all the extension has to do is wrap the call to its proper class 
path.   I would also have to build a struct/class lookup mechanism 
(which is the hard part)

can Extension output e.g. its image/video buffer into View face?

not now, but it will when the image! datatype is supported (in next 
extensions update).  This is the easiest way to integrate image applications 
into rebol, but also the slowest.

for video, I'm not sure... it would have to use callbacks, cause 
the synchronisations and refresh stuff is so complicated.  But maybe 
we could be able to open up ActiveX or other supported OS controls 
which can render directly within window rasters, as long as the host 
code knows how to link them into their windows.

so some changes in the view engine would have to be done for FMV 
to be added natively in its windows AFAIK.

horde doesn't offer all of what I need for the quality.

I'm also thinking that I could build a flat C SDK for Ogre which 
would make its integration into R3 much simpler after... basically 
storing stucts and pointers to things internally and using a few 
simple and fast generic scene query calls.