World: r3wp

Q: anyone tried playing around with vector! datatype in extensions?

not yet ...

I haven't either

I may look at vectors in extension later to produce some sound streams, 
but have no time right now

for 3D they might be the perfect datasets for transformation matrixes 
and stuff like that...

Sound streams ... Rebolek - vectors are one thing, but sound subsystem 
is another one. Is there sound in R3 View at all?

Someone requested multi-dimension vectors or something like that 
some time ago. Is that already implemented? Would it be usefull?

with extensions we can possibly use other timers, precise timers, 
and include that in the C code.  so if you open the sound ports in 
the extension and do the timing there... it could work... but its 
blocking right now... no async... so no real way to mix sound with 
other events... until async extension model is shared.

Pekr no sound yet, but can be written using extensions probalby. 
I was thinking more in twerms of creating the soundstream for later 
use than actually playing it from R3 (at least right now, as a first 
step)

Max - this is interesting - I wonder where is the main event loop? 
Core dll, or Host code? I think host, so yes, it is replaceable. 
I still try to push Carl to switch to multimedia timers - would work 
much better.... I have good article on that, and Carl liked it.

yes I read the article...

in theory, you could replace the main loop if you want, if we have 
callbacks in extensions, the main loop can be handled from an extension. 
although its not like having it close to the core, where it can be 
smarter...


but if a callback can see if some events are waiting on a list of 
event ports (something like event: wait [ port 0] ), then we could 
use whatever timer/window events and fire from there....  the rogle 
extension includes GLut which already has its own (precise?) timer 
internally, but it can't trigger rebol code *yet*. so right now I 
have to handle all events in the C side :-(

Where's the event port? Core or Host?

There are some good open-source event libraries, but last I asked 
I've heard that R3 event code is new, and should be fast enough ...

brian, can we expect work to be done on improving the Extensions 
API for next release?

Sounds like a good idea to me. I would get devices working asap...

The question should be raised on R3 Chat, in order for Carl to see 
we request that ....

My first attempt with extensions failed quickly.  I tried:
>> secure [extension allow]
>> import %libwmp3.dll

and got this error:

** access error: cannot open: %libwmp3.dll reason: none


libwmp3.dll is available at http://www.inet.hr/~zcindori/libwmp3/index.html
, an
d I've gotten it working in REBOL2

Any suggestions?


PS - that fact that we need to include "secure [extension allow]" 
should really

be included at http://rebol.com/r3/docs/concepts/extensions-using.html
!

extensions aren't like this.

they are REBOL plugins.  you must map the libwmp3.dll  or libwmp3.lib 
 inside of the extension...

and then you can call the commands inside the dll using rebol values 
natively.  its the plugin in C which does the mapping... look at 
the docs, you'll see that its quite easy to setup.

(http://rebol.com/r3/docs/concepts/extensions-making.html)

knowing how smart you are this shouldn't take you more than a few 
hours the first time... and then a few minutes for following libs 
 :-)

the advantage is that you are able to use the dlls in their native 
and have access to ALL of their code (C++ isn't working as-is yet, 
but is theoretically possible, with a few tweaks to the extensions.h 
stuff)

Thanks Maxim - I'll break out my old C compiler and see what I can 
figure out :)

the examples make it very easy to understant  :-)

any one here ever used SWIG?


I am seriously thinking of building an Extensions module for it, 
including the mapping of all supported datatypes.

is there any example creating a extension connecting to  a external 
system library? , e.g. using api calls with nested structures, pointers 
etc.?

I think not yet. All it is about is to be able to call DLL functions 
from C level. There should be some examples around the web. Once 
you work-it-out, connecting it to the REBOL side should not be so 
much problematic ...

you can simply do a block to struct conversion within the C layer.


the extensions docs show how to read and create new blocks, with 
working examples... you just need to continue from there on.


googling how to connect to a dll in real time will give you examples 
in C, but many dll's which are distributed as tools also come with 
their equivalent static .lib files so you might not need to do a 
run-time link to the dll.  OpenGL, for example came with both.

hmm, wouldn't REBOL's object better represent a struct? Do we have 
API to access object btw? The trouble is, that the object member 
might be for e.g. a function, but maybe it is not problem at all? 
:-)

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.