World: r3wp

Yes, and that can only come from docs of some kind.

Or from header files.

I would consider those docs "of some kind". :-)

Robert,  even if you know the function arguments, how do you call 
the function itself?


the extension will be compiled, so we can't create generic function 
calls.   The calling convention is part of a function's compilation 
process, on Windows any DLL may have three different argument passing 
methods simultaneously!!


get the problem is that you have to push arguments on the stack and 
retrieve them.  there are NO C functions which manipulate the stack 
directly.  these are always done via assembly, either inline or libraries.

Ok, I might have missed something. If you want to make it totaly 
dynamic than you are right. My ideas was more like a hybrid soltuion. 
Keeping the R2 structure how to deal with DLLs within R3(so you avoid 
porting code) but get use the R3 extensions model. Well, but you 
need to do the R3 extension. Not what most people would expect...

Here's the place to ask that question, Robert. The answer is that 
there may not be a way to do that until the next (redesigned) host 
kit comes out.

And the associated new extension model.

Don't worry, it's mostly an enhance ment of the existing model, but 
the command! type will be enhanced.

Ah, I was searching for !REBOL3 Extension. Maybe we can rename this 
group.

We can't, but a world master could. !REBOL3 Extensions sounds good.

agreed on the rename ...

How would this than work? What does the COMMAND! stuff do?

The command! type is the function type that you export from extensions 
into REBOL. There are supposed to be many enhancements to the command! 
type in the next host kit, and extensions are supposed to be embeddable 
in the host as well. And DELECT is going to be redone too. With all 
of these changes, more enhancements to the extension model are likely 
as well.

the question is ... when? :-)

The problem with creating blocks from within extensions is synchronizing 
with the R3 internals, which are multitasking (in theory). It's the 
same problem as with callbacks, but worse. In theory you could create 
extension-internal data that would be marshalled into R3 when passed 
back as a return value, but I'm not sure that is what you want.

What I want to do is return a string that is LOADed before being 
returned.

Or DOne.

Sorry, do you mean that you want to return new, non-string REBOL 
data in a block that you make? Right now you can do that (sort-of) 
with a limited set of datatypes supported, and it gets marshalled. 
There may be hacks to create more, but others would have to answer 
that with the current system.

If you really want to return a string that is loaded before being 
returned, the script that is embedded in the extension becomes a 
module that can contain arbitrary REBOL code, including functions 
that massage data that is returned from (possibly internal) command! 
functions.

So return the string to a REBOL function that LOADs or DOes it.

Example: Rebol code sends [a b [c d] [e [f g]] h i] to extension. 
The extension makes a string out of this and stores it. Later the 
extension should take the string and make block out of it, so that 
the script gets a block! and can do result/1, result/b etc.

outer: func [] [load inner]
inner: command []

And you don't have to export the command if you don't want to.

Just export the wrapper function from the extension's inner module 
and the calling code won't have to know the difference.

Up to now I don't have used a Rebol module to wrap the extension. 
The code just loads the extension. Just to be sure I understand your 
proposal: You would create a Rebol module that the user code uses, 
and this modul would deal with the extension?

There is a module inside the extension, and it gets wrapped around 
the extension automatically at LOAD time. That REBOL code in the 
string constant that you return from RX_Init is the module that I 
am talking about.

Ok, I see. I will play around with this.

So, decision made: Serializing BLOCK within in Extensions is a PITA. 
As long as you want to walk a BLOCK and don't have to deal that much 
with nested BLOCKs it's OK.


But it's not possible to make a to-string block! within an extension 
with a simpe to-string call.


Overall I think we need a way to serialize Rebol datatype into a 
char* or void* in a way that it can be stored and brought back into 
Rebol.

Workaround: Catch blocks on the Rebol side, make strings out of it 
and than go to the extension. Same for the other way: Extension devlivers 
string and Rebol code creates Rebol conform datatypes.

Callbacks: Has anyone made any further investigation how to handle 
async callbacks from an extension to Rebol? Or how to send a notification 
to Rebol? Maybe we can send an event! from outside.

In theory that kind of thing is supposed to be handled by R3's device/port 
model, which also will handle synchronization with R3's tasks. In 
practice noone has made a user-defined device yet, though I'm not 
quite sure why. Device extensions have been promised for a while 
now, but not yet delivered.

Maxim did a bit of research into a non-task-safe workaround to create 
callbacks.

There has been some speculation that the new extension and command! 
model that is coming with the next host kit will help solve this 
kind of thing. We shall see.

As mentioned a few times in the past, I don't think that user-defined 
devices are at all possible, with the current hostkit. And yes, I'd 
love to be proven wrong :)

Ok, since we are not sure, I will take a deeper look into the code 
and try to ask Carl.

I agree with Andreas, when I looked into the hostkit code it looks 
that table of 'names' of the devices is hardcoded in the r3.dll at 
the moment. My only idea (workaround) was to try use for example 
'clipboard device name and try to replace the internal code with 
custom one for testing purposes. I haven't tried that though from 
that time yet. Not sure if it is worth the time. Better wait for 
new hostkit ;)

Carl,   what is left to do for the extension model to support view 
as an extension..

I mean, with absolutely no graphics, or view events related code 
within the core ?

The main thing: linear command evaluation blocks. The replacement 
for the delect method.


Once that's done, I'll release View, but only with the windowing/event 
system, not rendering... then, Cyphre can bring the rendering method 
back online as his time allows. (Or, you can do your own in OpenGL 
if you feel so inclined.)

dinner time.

a little question... how will the gui be able to call rebol functions?

http://www.rebol.com/r3/notes/command-blocks.html

has anyone tried to build R3 host as a dll, and use it within R2 
 as a routine?

I have a client which might need R3 parsing but needs to use the 
R2 run-time...

R3 parsing is not totally necessary, R2 parsing can emulate everything

yeah, but some tricks are MUCH easier and probably quite faster to 
do in R3.

we are talking an expert PARSE user, and so far , this would be his 
main reason to move to R3, but then all his prior code isn't upgraded 
so its a bit daunting to just plunge right in the middle of a project.

As far as I remember (but prove me wrong) all of the R3 parsing additions 
have (sometimes complex) R2 equivalents. This means that you could 
compile R3 parse rules to R2 parse rules.

maybe but doing so on several thousand line parse rules is, well, 
more work than probably trying the R3 as a dll  :-D

You are thinking about scale relative to the wrong number. It's not 
a matter of how many lines the parse rules have, it's a matter of 
how many additions there are in R3 parse, and there aren't that many. 
Make the compiler once, and it will compile quickly. It could even 
do so at runtime.

R3 Host-Kit A100 has been uploaded to www.rebol.com.  This release 
can build CORE or VIEW (with externalized graphics lib.)


However, although the graphics lib is there, the DRAW commands are 
still in the process of conversion (Cyphre will be working on that 
part).


It's also an example (and a fairly simple one to learn from) of how 
to build a host-based extension module, including a few scripts that 
show how to process the module source to embed it in the boot.