World: r3wp

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.

Although Cyphre and I have both been able to build it using Mingw, 
other's have not been able to do so, and we're not sure why as of 
yet.


Therefore, we're not quite ready to distribute the host-kit to everyone, 
because we need more testing on it. However, if you want to actually 
test it (windows only), then ask Henrik for the download URL.

The host kit comes with all files necessary to build itself.  In 
theory, all you need to do is type "make" and it will produce R3/View 
(as r3.exe).  Also, make core will produce a core exe, w/o graphics.

why not just post the url ??

more eyeballs is better

The code includes some new host source files, for example to handle 
windowing and the related events.


Although this release comes with the AGG sources needed to do the 
build, note that these sources are pre-GNU versions, so are a bit 
older.


In addition, I suspect Maxim or someone may want to try creating 
an OpenGL version.


Soon, we plan to take a long look at making PAIR! into a float-based 
point, to allow better control with graphics. This somewhat non-trivial 
due to the assumptions in code that PAIR! is integer only with truncation 
for math operations.

are better

Ok by me, but someone will need to collect the comments and issues. 
 You want to do that?

Can we include our own protocols now ?

Sure .. I'll just add it to my Jira tracker

This secrecy is really over the top ...

so this host kit is only buildable under mingw, not VS?

No, I mean someone needs to digest the issues and fixes, and submit 
them back.

Heck, even if no one digests the issues, nothing is lost.

It's not secrecy...