World: r3wp

switch/all ... always return none. I feel, the R2 behaviour is better.

why I can't do [to word! #issue], while I can do [to word! to string! 
#issue] ?

What's the current situation wrt the host kit for Windows? Is it 
available anywhere?

Only if you have access to Carl's hard drive

I know some people got a hold of it a while back - is it just a matter 
of asking? Actually (I posted about this in chat), I need to do callbacks 
into REBOL so if that's not working yet, I'm out of luck. This is 
in regards to creating an external lexer for the Scintilla based 
editors out there.

Hmm... I think our jokes are better and better recently.

callbacks have always been possible, if you can use the global context.

and don't mixup the hostkit and extension... although they are based 
on the same code, they are separate releases.  AFAIK.

I know I'm a freak  and that most of my asks / comments are shaking 
you in fear but is there any rebol3  dicussion group   in  google 
WAVE ? 



How could such a tool help us  to get a better link with carl or 
maybe on some specific point  get a better help fro the community.


For example i don't feel able to make a whole R3/Vid alone but i 
feel like to contribute apporting ot R3/VID what i do best some widgets 
 and as i'm not alone able of it maybe a goo emulation can be created.

There is a rebol wave .. not sure if it is active still

Carl does not like waves :-)

Max, tell AND show us how you do the callbacks. IMO if you have found 
a way to do it now, we all should know it. It would speed-up R3 extension 
development a lot. And a good base of extensions is mandatory for 
R3 success. So every day we are faster helps us all.

Yes, Max - could you give us a bit more detail on how you would use 
the global context for callbacks?

the simplest solution I found was:


1) make an extensions which has storage for both  Reb_Do_String and 
Reb_Print    

2) add a function which accepts two function pointers and assigns 
them to these (library local) pointers
3) load the library in your host, use the callback setup function
3) call these functions pointers within wrappers.

4) that's it  works  VERY well, very fast, and bug free in my tests. 
 :-)


This works under MSVC , and when I researched the dll memory allocation, 
it was totally safe, by all accounts.

In windows, On dll allocation, each process gets its own library 
memory space. 



exerpts of code I had to screw around to find and make work (should 
be obvious to C coders):


the following was broken up in a few files, again, how to split this 
up will be obvious to those
who really need it.


#define EXPORT __declspec(dllexport)

typedef REBFLG (__cdecl *DoFunc)(REBYTE *text);
typedef void (__cdecl *PrintFunc)(REBYTE *text, ...);


DoFunc Reb_Do_String = 0;
PrintFunc Reb_Print = 0;


void EXPORT SetupCallBacks(DoFunc callback, PrintFunc pcallback){
	Reb_Do_String = callback;
	Reb_Print = pcallback;
}

void EXPORT DoREBOL(REBYTE *text){
	Reb_Do_String(text);
}


void EXPORT PrintREBOL(REBYTE *text){
	Reb_Print(text);
}



//----------------
// call_def.h
//

// don't forget to include this in the host build and extension code
//----------------
extern void SetupCallBacks(DoFunc callback, PrintFunc pcallback);
extern void DoREBOL (REBYTE *text);
extern void PrintREBOL (REBYTE *text);

Thanks, Max. I'm going to ask some probably naive questions if you 
don't mind. Can you confirm that the code you're showing is intended 
to call back into custom code you've added to the host? Would it 
work for calling into native REBOL functions as well? Also, if the 
intent would be to call back into a function defined by a script, 
do you know if RX_Call can take a function! datatype in the frame? 
The docs don't show an RXA_FUNCTION macro, but should this not be 
possible? Then you could call the extension to set up the callback 
into the script with the appropriate function passed in.

actually maybe RXA_HANDLE is intended for this

we can't use or access rebol function! datatypes in the released 
v1.0 extension code, unfortunately.


the above allows you to execute *REBOL*  source code, FROM an extension, 
but you can adapt the above to call other hostkit funcs too, I guess.

do you know if Carl intends to add support for the function! datatype 
in the near future?

Also, what do you mean by REBOL code vs other hostkit funcs? Isn't 
it all REBOL code?

RXA_Handle is used to allocate pointers and provide them to the core, 
without source code being able to tamper with them.  in fact, I don't 
even thing a handle!  can be created from R3 source...  only from 
the core or extensions.   so in general, if you are given a handle! 
type as an argument, you can rely its really some pointer generated 
by some native/extension code.

when you say REBOL source you mean script code?

yes.

so, basically you can do what I was asking for (calling scripts functions), 
but you have the limitation of having to know in advance the signature 
of the script function you're going to call, no?

not really,   Reb_Do_String  just executes a string of REBOL text 
on the global context.

it loads it, binds and runs the do dialect on it.

I was able to trigger button & keyboard events from  a GLut  (OpenGL) 
window,  running arbitrary code like normal view actions.


Nice thing is that the errors do not stop the interpreter, just that 
call to Reb_Do_String() so its like if your code was wrapped within 
an attempt by default  :-)

guess it's fairly flexible, but you're incurring quite a cost for 
this - need to stringify the script call and then this needs to be 
parsed again on the host side - seems wasteful

yep.   but it works.

I was still able to get more than 100fps running with one callback 
creating a small object per refresh IIRC.

sure - it'll have to do for now, in any case. You didn't answer about 
any enhancement to this that Carl might be working on, though - do 
you know if he is?

with view extraction from the coe, he has NO CHOICE in giving us 
a means to execute loaded, bound, code, since all a GUI really does 
is trigger code.
code which is managed by the core.


I also know that vector and image datatypes will definitely be part 
of next extension, its really important.


I am in the process of requesting that the argument frame be increased 
to 15 arguments by default... 7 is ridiculously low, especially if 
you want to use refinements.

so you think he's pretty much there?

wrt the first part

note that with the above callback system,  receiving a result from 
the callback is tricky.  


it has to use one of the extension's commands to store a return value 
there,  and the extension should then look for a return value after 
the callback returns.

there ... as in Done?  not sure...  its a lot of architecture and 
design decisions, probably more thinking than coding is happening 
right now.

its a big deal, it has to be secure i.e.  an extension must not be 
able to hijack the core and get an way in so it would start  probing 
core data, and ultimately go around all the work done to improve 
R3's safe use.

As I mentioned in chat, I'm thinking of implementing an external 
REBOL lexer for the Scintilla based editors. I was thinking that 
one way it could work is if the external lexer was a REBOL extension, 
but thinking about it again, maybe the whole callback thing could 
be avoided by having a custom host that is built as a dll, with the 
additional functions added to satisfy the Scintilla external lexer 
interface. Max, BrianH, do you know if it would be possible to compile 
the host as a dynamic library?

sure, but you'll probably have to tweak the distro, replace the main 
by the appropriate DLL init funcs.

not sure how easy it will be in linux, but on windows, exe and dlls 
actually are the same thing.  the os, just doesn't run main() on 
a dll.

yeah, you're right

do you know if Carl is still giving access to the hostkit if he's 
asked nicely in chat?

if you look at the startup code, its dead simple, so you probably 
just need to remove that and you're done... then use do_string, just 
like the read line loop does.

sure, especially to people with definite goals and cool ideas.  I 
thought it was made public, maybe not.

I wonder what performance you could expect if the host was called 
for evey keystroke in the editor and was passed the complete script 
(with possible included modules) to be parsed  - do you have any 
guess? Of course the host instance would be cahced between invocations.

if all you do is:


rebol_source = "PARSE {.... UTF-8 data from scintilla ...} parse-rules 
";
do_string (rebol_source);


probably very fast, enough for real time,  if script isn't huge :-)

if your app also has an extension which can give data to scintilla, 
then you'd just  add a command to the above string which calls the 
extension's command! with parse results.


the xtensions are very adept at parsing blocks, so converting that 
back to scintilla as native C data is possible there.

the only issue I see is intense RAM juggling, so if you can find 
ways to parse only subsets of current edit and cache the rest, then 
it might even be effective and real-time.

Why the need for the extension? If you already have a customized 
host, why would this be needed?

ah, yes, its possible the host also supports commands... but I'm 
not sure in the official release.  in the next one I think these 
have been built-in.

if you're having to do partial parsing, I'm guessing it can get pretty 
complicated quickly as you'd have to keep track of contexts that 
might be split, no?