World: r3wp

After adding MinGW\bin and msys\1.0\bin to the windows command path 
and also copying rebol.exe to msys\1.0\bin folder, I was able to 
build it from a normal command window without modifying the makefile.

Carl: in any case, I don't care much about CMake. Just shipping the 
hostkit with your make-build.r instead of a pre-built makefile would 
most likely do just fine for getting an integrated cross-platrform 
build working. (Plus, of course, bundling the libraries and sources 
for all platforms in the hostkit.)

I see go.r can be use as test.

And just in case: _THANKS_ a million for the new hostkit code drop, 
Carl (and everyone else who helped make it happen)!

echo that

yes thanks to everyone who worked on making it happen.  :-)

we now have a domain ( thanks Andreas ) for the tracker http://jira.rebolsource.net:8080/secure/Dashboard.jspa

and now is probably as good a time as any to move this discussion 
to !REBOL3 Host Kit

+1 Thank you!

Apart from Win, OS-X, Linux, BSD, the next most important platform 
is really imo an ARM plus Android.

Put Arm before BSD

BSD is well serviced by R2

I agree - for R3 to gain traction, mobile support should be a priority.

Jira: Why a new tracker? Isn't CureCode still be used? No information 
fragmentation please.

Priorities: Before getting new platforms up & running I see feature 
completion to be more critical. Otherwise we have a moving target 
that takes to much effort to keep in sync.

I agree about the completness-first  argument ...

Robert, if you read above, Carl did not want to make a public release 
unless someone gathered all the comments ... and Andreas & I volunteered.

The curecode tracker does not have a hostkit project ... so I used 
my new Jira tracker.  Simple as that.

Most of the host kit problems are R3 problems as well. We have categories 
in R3's Curecode project, and we can add a Host-Kit category if needed 
(I will do so right now). Multiple trackers are not a good idea, 
in general. We'll see if they become a problem in this specific case.

Done.

Thanks

Could you add an A100 version as well, please?

Done. As with all new versions added, be careful to set that field 
when you write up a new ticket. But we should be careful with that, 
because in general we haven't had prereleases. We may end up with 
problems reported for a100 that will be fixed in a100 :)

I consider the current hostkit drop to be hostkit version A100. The 
next hostkit to be released should (and hopefully will) be A101 or 
later.

Anyone know how to compile in one's own protocols ??

The "current hostkit drop" is not a release, it's a prerelease.

This is getting increasingly off topic.

Carl calls it a release, so I consider it a release. And yes, should 
be in R3 Host Kit

I too vote for an  A101 numbering the next time a package is released... 
its going to be MUCH easier to follow for everyone.   IIRC the A97 
created this strange pre-release condition too and it had to be specified 
each time we talked about what we downloaded.

Robert, did you ever upload your macros stuff that you mentioned 
in Jan?  I looked in the extensions group and didn't see anything

And your sqlite3 extension?

jocko .. your TTS extension still works under A100

No, sorry. Need to bundel all this so it can be used. But it's all 
still to much in flux, not fully-done etc.

I was wanting to see examples .. doesn't have to be functional, but 
I thought you said sqlite3 was working well??

thanks for the test and the feedback, Graham

Jocko, you need to do more :)

Lack of time, but I'm also waiting for more specs for the extensions 
(image datatype, callbacks ...)

You did yours in C++ .. is that because windows api/com needs this?

yes

Here are two functions I created to handle strings a bit simpler:

// 	string to convert to R3 string
//  R3 frame to add string too
REBSER* RXI_Make_String(const char *string){
		// build string
		int string_len = string == NULL ? 0 : strlen(string);

  odprintf("RXI_Make_String with length = %d, string = %s", string_len, 
  string);
		REBSER *s = RXI_MAKE_STRING(string_len, 0);
		if(string_len == 0) return s;

		// and set single chars if there are some
		for(int x=0; (*(string+x)) != '\0'; x++){
			RXI_SET_CHAR(s, x, *(string+x));
		}

		odprintf("RXI_Make_String: done");
		return s;
}


void RXI_Return_String(const char *string, RXIFRM *frm, int frm_position) 
{
		REBSER *s = RXI_Make_String(string);

		// set parameter 1 (=return value?) to constructed string
		// set index to 0
		// set type to string
		RXA_SERIES(frm, frm_position) = s;
		RXA_INDEX(frm, frm_position)  = 0;
		RXA_TYPE(frm, frm_position)   = RXT_STRING;
}

What is the best IDE to use with GCC under Windosw ?

Eclipse, probably.

Code:Blocks isn't bad.

Code::Blocks

http://www.codeblocks.org/

continuing Request for object lookup within host/extensions here....



Here is a proposal (using example C code) for OBJECT access within 
extensions  this uses the EXACT same API as commands, and with just 
a little bit of work on the extensions API by Carl and a single hook 
within the r3core, we could allow callbacks within objects.


the advantage is that we re-use the same safe sand box as commands, 
and don't require to do much coding to enable it, AFAICT.


since object lookup is performed on demand, we can very rapidly supply 
an object to the command, and it doesn't cause any heavy-handed conversion 
at each command call if the object isn't needed.  more fine-grained 
control could be added so we don't need to frame the whole object, 
but it would be usefull as-is already.

RXIEXT int RX_Call(int cmd, RXIFRM *frm) {
	i64 i;
	
	// objects are frames, exactly like command arguments.
	RXIFRM *obj;
	

 // return values are also frames (with one argument), for type-checking 
 purposes.
	RXIFRM *rval;
	
	if (cmd == 1) {
		// ask the core for a frame which represents object.
		// attributes are returned in order they appear in object
		//

  // the command frame doesn't include the object frame, only a handle 
  to the

  // object which the core can understand. we then ask for the object 
  frame on-demand.
		obj = RXA_OBJ(frm, 1);
		
		switch (RXA_TYPE(obj, 1)) {
			case RXT_INTEGER:
	            i = RXA_INT64(obj, 1);
				break;
			
			// we could build a frame for supplying arguments to the eval
			case RXT_FUNCTION:
				rval = RXA_EVAL(obj, 1);
				if (RXA_TYPE(rval, 1) == RXT_INTEGER){
	            	i = RXA_INT64(rval, 1);
				} else {
					// return error
				}
				break;
			
			// wrong type
			default:
				// return error
				break;
		}
		
		// do something with the value
		my-native-function(i);

	}
}

so what do you guys think?

Command arguments have limits on how many are passed. Those same 
limits would apply to object fields with your approach.

7 args isn't it?

So objects with more than 7 fields wouldn't be supported? Command 
frames are marshaled, remember, they are not references to stack 
frames. If you want to pass an object and get access to its fields 
perhaps passing it as some kind of handle and getting access to the 
fields through accessor funcs would be better. Unless I misunderstood 
your code and you are doing this already.

the frame size is an artificial limit. 


the frame is just an array, there is no real reason for it to be 
limited to only 7 items, its just an initial limitation, (probably 
to simply the macros and support code).

Yes, but it would still be marshalled, which I thought you were trying 
to avoid.