World: r3wp

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.

the accessor is another approach, but marshaling would have to occur 
anyways, because on the C side we need to extract datatypes dynamically, 
which is what the current API already does.

This idea was borne out of a previous code snippet I was building 
which actually used accessors   :-)


as I was writting it up, it occured to me that I was providing a 
different syntax for the same problem.

another approach would be to access a single attribute at a time, 
but anytime data is exchanged, I think re-using the current frame 
code is ideal... 


it already solves all of the type and memory marshalling, separates 
the external data from the core, solving the issues with the GC and 
stuff like that.


as long as the API copies data when its setting values back in the 
core (which I guess its already doing) then I see no point in inventing 
a second API just for objects.

IMHO, we cannot prevent marshalling without exposing a lot more of 
the core into the extensions, and/or making extensions unsecure (able 
to peek directly within the core datasets).

is anyone tracking all the new extensions being written for R3?

Oops ,, should have been in the humor group

Just curious .. why does the init_block not quote the name ?  It 
does for the titile

There are a number of bad links in the extensions-embedded.html document 
... are they just docs yet to written? Or has the doc been moved 
destroying the links?

I looked at the example ext-test.c and it lacks the extension header 
as specified in the docs

The extensions docs say that dealing with handles is undocumented 
...  but if it's just an integer, can we just pass that back and 
forth between rebol and the extension?

the idea of handles is for an extension to give a key to a script, 
and make sure the script can't play with it.   by key, I mean an 
arbitrary value which makes sense for the extension (pointer, index, 
value, etc).

Quick check in. Hmmm... flooded.

carl... just look above my mock up of object access within extensions... 


does it makes sense to use the current API in given or other format?

I tried to send this on R3 chat but server is down..

Maxim: let's see if I can get you a Reb_Get_Object(obj, word) function. 
That would work ok, right?

one of the reasons I want to use objects directly within extensions 
is that I am noticing GC recycling interruptions while scrolling 
stuff in R2 AGG driven interface.