World: r3wp

I also don't mind if I need to port things to a new system for R3, 
as many things need to be revisited anyway. As long as I can run 
old R2 scripts side-by-side easily. The important thing, then, is 
getting everyone on the same page with regard to the various domains, 
steps, and responsibilities of design, assembly, and deployment.

just call the "missing" function UPSERT and be done with it. will 
also fit nicely, if you add special treament of "keyed" records to 
it (using the usual /skip and /part refinements).

Max, Robert - thanks for offering Carl a help with the Help Kit maintanance. 
If we do it, I buy Android phone to test R3 :-) I was also thinking 
about the Beagle board, etc. Simply I would like to see R3 on ARMs, 
as in mobile sphere, they are - everywhere ...

I am also thinking of buying a beagle board, for robotic experimentation 
with my kids.

Are these more versatile than a plug computer? I guess so if you 
want to use 3D and the other media related IO ports, but otherwise 
how do they compare?

they are motherboards which you can use to make plug computers

they have everything on-board (even a graphic chip IIRC) and standard 
connectors right on the board.

http://en.wikipedia.org/wiki/Beagle_Board

the graphics actually aren't that bad  (10 million polys a second!)

We are registered with Texas Instrumets, and they have new DaVinci 
gfx chip -

 http://focus.ti.com/dsp/docs/dspplatformscontento.tsp?sectionId=2&familyId=1300&tabId=1855&DCMP=dm368_041410_eu&HQS=Other+EM+dm368elp-ee

or this board...$49 - CM-X300 Computer-On-Module http://www.compulab.co.il/x300/html/x300-cm-datasheet.htm?gclid=CPinmdrk3qECFaEN5QodCgu1KA

although you can find Arm based laptops for under $100. You already 
get the keyboard and screen....

too much cool stuff out there  ;-)

What are people actually using R3 for at present?

Internal tools, prtotyping to see how far we can go with it, up-front 
development of necessary libs

Are there anythings you are doing that can't be done with r2?

there will be soon.

I'm looking for the compelling business proposition to shift my apps 
to R3 ...

UNICODE support?

I don't think you should do that yet. Wait 6-12 months and see what 
tools are around. What RM Asset is developing is mostly backend/tools 
stuff, to make sure that developing boring business apps becomes 
a smooth and quick process and some of these things wouldn't work 
well in R2 or would be hampered by various already known showstoppers. 
We have to think forward and build this stuff under R3 now, otherwise 
we will have two things: A fast and poorly supported platform to 
build apps on (R3) and a slow and limited platform to build apps 
on (R2), and we don't want that, do we? Besides, RM Asset already 
has some target apps in mind for R3.


Also given how R3 uses a hostkit, gives everyone much more control 
over how they want certain things done or add special extensions 
to, say, graphics or database capability without having to ask Carl 
to add it.


I think you will appreciate that this stuff is done first, so you 
can build a good app in a few days, rather than spending 2 months 
doing it. It'll save you a good bit of money too. This involves GUI 
test tools, customer feedback mechanisms built into the GUI, quickly 
integrating a GUI with a database, completing the GUI generally, 
various extensions, such as the high speed networking extensions 
needed for xpeers-II.

Customer feedback into the GUI? I am really interested to know, what 
is VID turning into :-) Or is functionality as "customer feedback 
mechanism" an addon?  Maybe it would be helpful to have some high-level 
diagram, about GUI components ...

Will there be anything to test in 1-2 months period? I would be interested 
e.g. in testing new styles you are creating ...

Perhaps something in 2-3 months, but also depending on hostkit. Customer 
feedback is mostly RM Asset related. It doesn't necessarily mean 
direct feedback from customers, but methods to more easily debug 
crashed apps without demanding anything from the user, such as a 
record of which buttons are clicked, replay mechanisms, etc.

Note that the specs document is not updated with these things. We 
have to figure out how they would work first.

What VID is turning into: It's turning into a VID that will be very 
useful. I've personally been missing these features for ages and 
will eliminate many hours of tiresome debugging.

Sounds good, except the timing :-) Well, but we have been waiting 
for new VID for 2 years already, so another 2-3 months are OK. If 
you have anything to test, feel free to ask, I am willing to, and 
I did so  in the past too ...

btw - why is host kit important for you as well? Are you doing also 
some low-level View changes? Which reminds me - hopefully View will 
be able to display Unicode chars? :-)

fixing bugs and getting control over AGG.

The win32 hostkit has been done for A99 .. .why hasn't it been released??

Difficult to say ... it depends on Carl. The bad thing is, that Twitter 
message says: "Where's the A99 host kit source and lib?", which leads 
you to latest blog article, which does not contain any link though. 
Let's hope Carl does just some last minute changes ....

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.