World: r3wp

on all
 should read "compiled for"

there is a big difference in how flash and AGG render their stuff.... 
it seems to me that AGG is actually more scalable in sheer quantity 
of strokes, whereas flash seems to be much better at handling textures 
and bigger screens... have you noticed the same reactions... having 
much more in depth knowledge of flash, I'm curious as to your observations....

The problem with TTF is, that in most cases the fonts are copyrighted, 
so zou cannot give them with the app. You can embed glyphs you need 
into Flash, but the the font is not TTF anymore so nobody can use 
it in other apps.

ah yess I see the nuance.  so font authors are wary of allowing re-distributable 
licenses?

I don't know AGG well so I'am not able to compare these. AGG can 
use same rasterization as Flash (which is more optimized for speed 
I guess). At least that's what Cyphre told me.

Cyphre has thought that we might switch to "compound rasterizer" 
of AGG, which would be more similar to Flash. But we might be slightly 
off-topic here :-)

I wish all those decisions where available to the programmers... 
often I have been bitten by these decisions in REBOL...  I plan to 
allow as much control to the Low-level stuff as possible with my 
OGL extension, even with the toolsets I'll build using it, I still 
want to allow the capacity to edit quality & quantity based-decisions, 
probably by providing a standard gfx setup requestor available to 
all applications of rogle.

this way developpers won't have to build their own, its going to 
be built-in and not require a "restart" of the application.

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.