AltME groups: search

yep, programmatically binding the engine is what I plan to do... 
especially since it will allows us to rebuild the binding at any 
moment just by flicking a switch and update it without any user-intervention.

so far, my options are:

 -a direct wrapper generator coded in REBOL using C++ sources, with 
 an advanced  C++ declaration to R3 Extension converter, 
	-I try out SWIG build an R3 extension output module for it, 

 -I use another language binding as the one to base mine with, and 
 make a specific tool to convert it to an R3 extension.

 -do a manual (and painfull) convertion, using a few generic scene 
 interaction commands.


One thing I'd like, is to add some way for the OGRE extension to 
be able to call REBOL code directly via callbacks, using their Extensive 
hooks throughout the api.


Although this will be slower than if the callbacks where in C, obviously, 
some parts of REBOL are swift enough (like series management) that 
they just might make the cut for REAL time rendering hooks.  Well 
implemented, they would be fast enough for common GUI interaction 
events for sure.

I try to keep this as short as possible.

Imagine you have this file, called %test.r:

==file==

REBOL[
    Title: {Simple extension test}
	Name: ext-test
	Type: extension
	Exports: []
]

map-words: command []{
    word_ids = RXI_MAP_WORDS(RXA_SERIES(frm, 1));
    return RXR_TRUE;
}

fibc: command[
    len [integer!]
]{
    RXA_TYPE(frm, 1) = RXT_INTEGER;

    i64 o = 0;
    i64 l = RXA_INT64(frm, 1);
    i64 i;

    for (i = 0; i <= l; i++)
        o = o + i;

    RXA_INT64(frm, 1) = o;

    return RXR_VALUE;
}

add5: command [
    a [integer!]
][
    a: a + 5
    return a
]

==end of file==


And now imagine that in R3 console you are in the directory where 
you have the file %test.r .
Now you type:

>> compile %test.r
>> import %test.dll
>> fibc 10
== 55
>> add5 5
== 10

And that's all.


If you want to try it, you need to have TCC (TinyC Compiler) - get 
it from http://download.savannah.nongnu.org/releases/tinycc/tcc-0.9.25-win32-bin.zip
The script expects it instaled to %/c/tcc/ but it can be changed.
Then go to r3 console and type:

>> do http://box.lebeda.ws/~rebolek/rebol/srec.rip
>> cd %srec/
>> do %srec.r


Then you can try COMPILE etc. (see above). %test.r is included in 
the archive.

SREC is shortcut for Simple REBOL Extension Compiler.
    
Enjoy! (if it works ;)

This uniton gives a warning/error with mingw:

typedef union rxi_arg_val {

	i64 int64;

	double dec64;

	REBYTE bytes[8];

	struct {

		i32 int32a;

		i32 int32b;

	};
	struct {

		u32 index;

		void *series;

	};
	void *handle;

} RXIARG;

I commented the struct part and than it works. So either we need 
to give it a name, which will result in a ->struct_name.series sequence. 
Not sure if this makes any difference instead of just putting the 
members into the union.

Ok, so I've not yet provided everything that you'll need to do it. 
I divided the
 extensions release into a few stages:

1. simple - 
just simple access to commands and args
2. series - access to series 
values of various types
3. objects - access to objects (of all types)
4. 
codecs - support for codecs
5. host-lib - ability to bundle extensions 
with the host-lib itself.

So, I need to get you a bit more... in 
fact along the lines that you mention.

If the c-level side uses UTF-8 strings as well, can I just use the 
Rebol series as is? get_string returns a decoded string.

can I give a guess that the series building part of the request will 
be about 100 times faster now?

// 	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;
}

Has some useful new ext funcs:

	void *(*make_block)(u32 size);
	void *(*make_string)(u32 size, int unicode);
	int (*get_string)(REBSER *series, u32 index, void **str);
	u32 (*map_word)(REBYTE *string);
	u32 *(*map_words)(REBSER *series);
	REBYTE *(*word_string)(u32 word);
	u32 (*find_word)(u32 *words, u32 word);
	int (*series_info)(REBSER *series, REBCNT what);
	int (*get_char)(REBSER *series, u32 index);
	u32 (*set_char)(REBSER *series, u32 index, u32 chr);
	int (*get_value)(REBSER *series, u32 index, RXIARG *val);

 int (*set_value)(REBSER *series, u32 index, RXIARG val, int type);
	u32 *(*words_of_object)(REBSER *obj);
	int (*get_field)(REBSER *obj, u32 word, RXIARG *val);
	int (*set_field)(REBSER *obj, u32 word, RXIARG val, int type);

if the core where based on copy on set then it would be pretty safe, 
but alas, we have mutable series.

internally that can work, but the issue arises when two threads share 
a series. if they write at the same time, even with a copy, things 
like indexes might not update atomically to the copy operation.

The advantage to the thread-like tasking model is that the built-in 
functions and data structures can be made copy-on-write, or copy-on-UNPROTECT. 
Protectecd series can be sharable.

Only if the series and other data structures in its code block are 
marked copy-on-write.

PeterWoo - you talk nonsense, which belongs in advocacy group :-) 
If you work for 35 years in enterprise, then tell me, if you met 
spread there. The messaging is done by so called middlewares. IBM 
has MQ series, SAP has XI. Those engines use the so called connectors. 
Everybody went the web-services route, hence having ability to talk 
SOAP might be more important for REBOL. I never argued against having 
as much libraries as possible wrapped to REBOL, the only thing I 
argued against is eventual 200KB library inclusion in REBOL, just 
to do IPC between REBOL tasks ...

My personal summary for the extensions API:

- A100 is basically the same as the previous extensions-only API 
release (A77).

- A101 adds map_word, word_of_string, words_of_object, get_field, 
set_field

- A102 adds make_image and gc_protect, renames the constants used 
for series_info from RXI_INFO_* to RXI_SER_* and adds RXI_SER_DATA

That MAP-WORDS command only does:

	word_ids = RXI_MAP_WORDS(RXA_SERIES(frm, 1));
	return RXR_TRUE;

Using external extensions with a104, I get an error when using these 
series macros :

RL_SERIES_INFO(ser, RXI_SER_TAIL) ,  RL_GET_CHAR(ser, idx) , and 
RL_MAKE_STRING. Did someone noticed this ?

With the sample2.c example I have problem with undefined RXI_SERIES_INFO 
and RXI_GET_CHAR

I think RXI_SERIES_INFO is now RL_SERIES

i think you could also replace RXI_GET_CHAR by first obtaining a 
pointer using RL_SERIES(ser, RXI_SER_DATA) and then just indexing 
into this directly

Andreas, so I must copy all series to REBOL's one as you did in the 
zlib example? I guess I will need to put images into REBOL in pure 
binaries at this moment, right?

//I want: char **MagickQueryConfigureOptions(const char *pattern, 
unsigned long *number_options)
//I have:
            unsigned long *number_options;
            char *item;

            char **list = MagickQueryConfigureOptions("*",number_options);
      
            REBSER *b = RL_MAKE_BLOCK(*number_options);
            RXA_SERIES(frm, 1) = b;
            RXA_INDEX(frm, 1) = 0;
            RXA_TYPE(frm, 1) = RXT_BLOCK;

            int i,j;
            for(i=0; i<*number_options; ++i)    {
                item = list[i];
                REBSER *s = RL_MAKE_STRING(strlen(item), 0);
                for (j = 0; j < strlen(item); ++j)
                    RL_SET_CHAR(s, j, item[i]);
                RL_SET_VALUE(b, i, s, RXT_STRING);
            }

this is what carl will be adding to the next host-kit.... 


//------------------
//-    #RXV_xxx
//
// REBOL EXTENSION GET Macros
//
// provide direct RXIARG access macros
// with these macros, the single argument should be an RXIARG *
//

// this is usefull when the RXIARG is NOT being used from an argument 
frame

// but as a single value, like when we use RL_Get_Field() or RL_Get_Value()
//
// if the argument is dynamically allocated, ex:
//    RXIARG arg = OS_MAKE(sizeof(RXIARG)); 
// then use the macros like so:
//     RXV_WORD(*(arg));
//------------------
#define RXV_INT64(a)		(a.int64)
#define RXV_INT32(a)		(i32)(a.int64)
#define RXV_INTEGER(a)	(a.int64) // maps to RXT_INTEGER
#define RXV_DEC64(a)		(a.dec64)
#define RXV_DECIMAL(a)	(a.dec64) // maps to RXT_DECIMAL
#define RXV_LOGIC(a)		(a.int32a)
#define RXV_CHAR(a)		(a.int32a)
#define RXV_TIME(a)		(a.int64)
#define RXV_DATE(a)		(a.int32a)
#define RXV_WORD(a)		(a.int32a)
#define RXV_PAIR(a)		(a.pair)
#define RXV_TUPLE(a)		(a.bytes)
#define RXV_SERIES(a)		(a.series)
#define RXV_BLOCK(a)		(a.series)
#define RXV_INDEX(a)		(a.index)
#define RXV_OBJECT(a)	(a.addr)
#define RXV_MODULE(a)	(a.addr)
#define RXV_HANDLE(a)	(a.addr)
#define RXV_IMAGE(a)		(a.image)
#define RXV_GOB(a)		(a.addr)

oh... sorry... posting this I just saw that the series don't use 
  .addr    but    .series

so you exxample would be:

//I want: char **MagickQueryConfigureOptions(const char *pattern, 
unsigned long *number_options)
//I have:
            unsigned long *number_options;
            char *item;

            char **list = MagickQueryConfigureOptions("*",number_options);
      
            REBSER *b = RL_MAKE_BLOCK(*number_options);
            RXA_SERIES(frm, 1) = b;
            RXA_INDEX(frm, 1) = 0;
            RXA_TYPE(frm, 1) = RXT_BLOCK;

            int i,j;
            for(i=0; i<*number_options; ++i)    {
                RXIARG arg;
                item = list[i];
                REBSER *s = RL_MAKE_STRING(strlen(item), 0);
                for (j = 0; j < strlen(item); ++j)
                    RL_SET_CHAR(s, j, item[i]);
                RL_SET_VALUE(b, i, arg, RXT_STRING);
            }

//I want: char **MagickQueryConfigureOptions(const char *pattern, 
unsigned long *number_options)
//I have:
            unsigned long *number_options;
            char *item;

            char **list = MagickQueryConfigureOptions("*",number_options);
      
            REBSER *b = RL_MAKE_BLOCK(*number_options);
            RXA_SERIES(frm, 1) = b;
            RXA_INDEX(frm, 1) = 0;
            RXA_TYPE(frm, 1) = RXT_BLOCK;

            int i,j;
            for(i=0; i<*number_options; ++i)    {
                RXIARG arg;
                item = list[i];
                REBSER *s = RL_MAKE_STRING(strlen(item), 0);
                arg.series = s;
                for (j = 0; j < strlen(item); ++j)
                    RL_SET_CHAR(s, j, item[i]);
                RL_SET_VALUE(b, i, arg, RXT_STRING);
            }

unsigned long number_options;
            char *item;

            char **list = MagickQueryConfigureOptions("*",&number_options);
      
            REBSER *b = RL_MAKE_BLOCK(number_options);
            RXA_SERIES(frm, 1) = b;
            RXA_INDEX(frm, 1) = 0;
            RXA_TYPE(frm, 1) = RXT_BLOCK;

            int i,j;
            for(i=0; i<number_options; ++i)    {
                RXIARG arg;
                item = list[i];
                REBSER *s = RL_MAKE_STRING(strlen(item), 0);
                arg.series = s;
                for (j = 0; j < strlen(item); ++j)
                    RL_SET_CHAR(s, j, item[i]);
                RL_SET_VALUE(b, i, arg, RXT_STRING);
            }

The remaining bug will be somewhere in the interaction betweein RXIARG, 
arg.series and RL_SET_VALUE.

I think I found the bug.  it could have worked earlier with your 
other memory access issues but will not work anymore.
    RXA_INDEX(frm, 1) = 0;

AFAIK this effectively erases the assignment of:
    RXA_SERIES(frm, 1) = b;

I can say, that the **list is filed correctly because when I for 
example use at the tail:
            REBSER *s = RL_MAKE_STRING(strlen(list[2]), 0);
            for (c = 0;  c< strlen(list[2]); ++c)
                RL_SET_CHAR(s, c, list[2][c]);
            RXA_SERIES(frm, 1) = s;
            RXA_INDEX(frm, 1)  = 0;
            RXA_TYPE(frm, 1)   = RXT_STRING;
            return RXR_VALUE;
I get the correct list[2] value.

using above code as reference...

RXA_SERIES(frm, 1) = b;
RXA_INDEX(frm, 1)  = 0;  // AFAIK this is 0 by default.
RXA_TYPE(frm, 1)   = RXT_BLOCK;
return RXR_VALUE;

str_arg = RXA_SERIES(frm, 1);

sorry..

REBSER * str_arg = RXA_SERIES(frm, 1);

RL_Series(str_arg, RXI_SER_TAIL)

with RL_Series I have this error:  undefined reference to `_imp__RL_Series'

This works:
            REBSER *ser;
            i32 len;
            
            ser = RXA_SERIES(frm, 1);

            len = RL_SERIES (ser, RXI_SER_TAIL) - RXA_INDEX(frm, 1);

            char pattern[len]; 
            for(n = 0; n < len; ++n)   
                pattern[n] = RL_GET_CHAR(ser, n);

So with Cyphre's help I have this function:
char* rebser_to_utf8(REBSER* series) {
    char *uf8str;
    REBCHR* str;
    REBINT result = RL_GET_STRING(series, 0 , (void**)&str);
        
    if (result > 0){
        //unicode string
        int iLen = wcslen(str);
        int oLen = iLen *  sizeof(REBCHR);
        uf8str = malloc(oLen);

        int result = WideCharToMultiByte(CP_UTF8, 0, str, iLen, uf8str, oLen, 
        0, 0);
        if (result == 0) {
            int err = GetLastError();
            RL->print("err: %d\n", err);
        }
    } else if (result < 0) {
        //bytes string (ascii or latin-1)
        uf8str = malloc(strlen((char *)str));
        strcpy(uf8str, (char *)str);
    }
    return uf8str;
}

and I can than use:
..
            char *filename = rebser_to_utf8(RXA_SERIES(frm, 1));
            status=MagickReadImage(current_wand, filename);
            free(filename);
            if (status == MagickFalse) {
                ThrowWandException(current_wand);
            }
            return RXR_TRUE;

This seems to be working:
char* REBSER_to_UTF8(REBSER* series) {
    char *uf8str;
    REBCHR* str;
    REBINT result = RL_GET_STRING(series, 0 , (void**)&str);
        
    if (result > 0){
        //unicode string
        int iLen = wcslen(str);
        //int oLen = iLen *  sizeof(REBCHR);

        int oLen = WideCharToMultiByte( CP_UTF8, 0, str, -1, NULL, 0,  NULL, 
        NULL);
        uf8str = malloc(oLen);

        int result = WideCharToMultiByte(CP_UTF8, 0, str, iLen, uf8str, oLen, 
        0, 0);
        if (result == 0) {
            int err = GetLastError();
            RL->print("err: %d\n", err);
        }
        uf8str[oLen] = 0;
    } else if (result < 0) {
        //bytes string (ascii or latin-1)
        uf8str = strdup((char *)str);
    }
    return uf8str;
}

when I don't need it.. so for example:
            char *filename = rebser_to_utf8(RXA_SERIES(frm, 1));
            status=MagickReadImage(current_wand, filename);
            free(filename);

Again with Cyphre's help, here is a function which converts MultiByte 
(utf-8) string from C side to REBSER used to return the string to 
REBOL side:

REBSER* MultiByteToRebser(char* mbStr) {

    int len = MultiByteToWideChar( CP_UTF8, 0, mbStr, -1, NULL, 0);
    //the len is length of the string + null terminator
    wchar_t *wcStr = malloc(len * sizeof(wchar_t));

    int result = MultiByteToWideChar(CP_UTF8, 0, mbStr, strlen(mbStr), 
    wcStr, len);
    if (result == 0) {
        int err = GetLastError();
        RL->print("ERROR: MultiByteToWideChar -> %d\n", err);
        exit(-1); //how to throw ERROR on REBOL side?
    }
    REBSER *ser = RL_MAKE_STRING(len-1,TRUE);
    REBUNI *dst;

    //hack! - will set the tail to len
    REBINT *s = (REBINT*)ser;
    s[1] = len-1;

    RL_GET_STRING(ser,0,(void**)&dst);
    wcscpy(dst, wcStr);

    free(wcStr);
    wcStr = NULL;
    return ser;
}

I'm not sure how safe it is, but it seems to be working.
To return the string value I use:

RXA_TYPE(frm, 1) = RXT_STRING;
RXA_SERIES(frm, 1) = (REBSER *)MultiByteToRebser(utf8str);
return RXR_VALUE;

with:
case CMD_GRAPHICS_INIT_WORDS:
        //temp hack - will be removed later
        graphics_ext_words = RL_MAP_WORDS(RXA_SERIES(frm,1));
        break;

Using just RXA_SERIES(frm, 1) does not work.

RL_GET_STRING(RXA_SERIES(frm, 1), 0 , (void**)&pixels); doesn't work 
as well... I think we need RL_GET_BINARY macro...

REBYTE *pixels = ((REBYTE *)RL_SERIES((RXA_ARG(frm,7).series), RXI_SER_DATA));

I just would like to know if it's possible for example to change 
the series tail on C side (and to avoid a need to init the series 
on REBOL side).

But I would like to know, if I can just change the provided variable 
without returning it back as a command result. (as it's possible 
with series).

Oldes, the different situation is for series values (string, image, 
block...) though. You can directly modify them and use RL_Protect_GC() 
to make sure GC won't mess with your changes.

And you don't have to worry about the GC collecting a double since 
it will always be in a value slot, so all you have to do is protect 
the series or context it is in.

He was asking about changing the original. The only way to do that 
is to pass a reference to the series or context that contains the 
original value slot.

Brian: actually the values on the 'command frame' are 'free value 
slots' as they are not part of any series...they are just in plain 
fixed size array. But  this is probably just playing with words ;)

This seems to be working, but is this the best solution?
	REBSER* block = RL_MAKE_BLOCK(2);
	RXIARG val;
	RXV_DEC64(val) = mean;
	RL_SET_VALUE(block, 0, val, RXT_DECIMAL);
	RXV_DEC64(val) = standard_deviation;
	RL_SET_VALUE(block, 1, val, RXT_DECIMAL);
	RXA_TYPE(frm, 1) = RXT_BLOCK;
	RXA_SERIES(frm, 1) = block;

RL_Protect_GC protects unreferenced series from disappearing, but 
does it also protect them from being moved?

If not, how can an extension be sure that a pointer to a series is 
still valid?

I don't think the REBOL GC is copying or compacting. Series are only 
moved when they are expanded (a reallocation) so if you don't want 
it to move, preallocate the length you want.

I saw a warning somewhere in the documentation that series can be 
moved, but maybe that is indeed limited to their own isolated memory 
management

I don't understand, though, how the RL_SET_CHAR and RL_SET_VALUE 
functions could extend a series when necessary without ever moving 
it

REBOL must have a global series descriptors registry, much like the 
words registry

I'm using this piece of code to get pointer to binary argument:
            char *srcData;
            REBSER *ser = RXA_SERIES(frm, 1);
            srcLen = - RL_GET_STRING(ser, 0, (void **) &srcData);
But also must do this:
	srcData+=RXA_INDEX(frm,1);

To fix the pointer to correct position if the source binary index 
is > 0.
Is this a bug or is it normal? Should it be reported in CC?

OH... forget it... the correct way is using:

	REBSER *ser = RXA_SERIES(frm, 1);
            char *srcData  = RL_SERIES(ser, RXI_SER_DATA);
            u32 srcLen = RL_SERIES(ser, RXI_SER_SIZE);

Correction... the right result is:

	srcData = RL_SERIES(ser, RXI_SER_DATA) + RXA_INDEX(frm,1);

 srcLen =  RL_SERIES(ser, RXI_SER_SIZE) - RL_SERIES(ser, RXI_SER_LEFT) 
 - RXA_INDEX(frm,1) -1;

so I don't know what is better.

Oldes, AFAIK its normal... in C we always have access to the full 
string.  

we use RL_SERIES to figure out the portion of the string which is 
used by a specific Series reference.

so basically if you call:

a: [1 2 3]
b: next a


and use A or B in the command, you get the same string (logically, 
not physically), but with only the RL_SERIES and RXA_INDEX() which 
are set to different values.

and yes.. it's fine that RL_SERIES(ser, RXI_SER_DATA) returns string 
at it head. Than I would like to have the RXI_SER_LENGTH as a shorthand 
for: RL_SERIES(ser, RXI_SER_SIZE) - RL_SERIES(ser, RXI_SER_LEFT) 
- RXA_INDEX(frm,1) -1 


and the bug is, that the binary is not using wide, but reports it 
and counts the pointer position as wide - as Kay reported.

we needed to know the size of the letters displayed on screen because 
first of all in R2 when you call 2 times a text instruction the rendering 
at piled up at same place and not disposed one after another on the 
X axis with natural spacing... so draw [ text 10X10 "a" text "b"] 
renders a "b" over the "A" and not "A" followed by "B". And it's 
logical ... text instruct was then designed to handle a serie a letter 
or several series of letter organised in distinct block we can call 
words... but you see that concept doesn't fit with the need of having 
an interaction anytime with any letter componing the words.

actually, its other series funcs which close rebol unexpetedly.  
  


WRITE and MOLD both have closed REBOL on that large draw block.... 
though strangely, the file is properly molded and written to disk.

I haven't tried it, and I'm not sure it's a specific size that does 
it, but more a series of events. The testing system is not yet in 
place to do it this way.

Henrik, thanks for posting your db-reactor ideas. Is there a reason 
not to use the standard REBOL series func names for actions. i.e. 
insert/change/remove/select rather than add/update/delete/get? Another 
option would be the names from CRUD. 


What does the underscore in your _data naming convention indicate?


I need to look at your validation design again, to see how things 
work together.

Small status:


The Internet these days seems to be composed of a series of disk 
crashes (instead of tubes). Both Robert and Rebolek are suffering, 
which slows down communications, so no updates lately.

Not unproven. Take REBOL functions for managing series. Are they 
incomplete?

New 'X-mas' release of R3-GUI is available for download at http://www.rm-asset.com/code/downloads/

top-level changes:

-smarter face update mechanism
-improved dynamic panel content handling
-internal optimizations and more system-friendly redesign
-cleanup of obsolete code parts

some more detailed notes:


- panels can now contain normal, VISIBLE faces, HIDDEN faces (just 
invisible, but taking the same space as the visible faces), IGNORED 
faces (invisible, and not taking any space), FIXED (visible, but 
not resizing with the panel, having a fixed position and size)

- the ON-CONTENT actors for all panels (HGROUP, VGROUP, VPANEL, HPANEL) 
now are as much compatible with series function as practical, taking 
an integer index, high-level function can take a gob or a face to 
specify the position as well

- Data optimization: FACES attribute removed to not need to store 
and maintain the same information twice, risking the conflicts (they 
were already present, order of faces was not identical)


You can also download the latest R3.exe from our site which contains 
LOAD-GUI that directly loads the actual release. This way you are 
always using the latest R3GUI codebase.


We'll be updating the 'old' documentation soon to be up-to-date with 
our current R3GUI version. So interested developers can start using 
it for real or participate on the project.

I don't mind '?' being use to indicate a question, but I think the 
"-of" words more accurately reflect what information is being extracted 
FACES?
 - it's like  "huh?" - it's vague, someone's secret language.

(Maximum-of and minimum-of were poorly named; I wanted them changed 
to 'at-maximum(-of)' etc since they return the series at the index.)

How is now R2's face/pane, and earlier face/faces replaced? I can't 
see it in the structure. Is that a gob!?

>> help main-pan
MAIN-PAN is an object of value:
   style           word!     vpanel

   facets          object!   [init-size min-size max-size align valign 
   res...
   state           object!   [mode over value]
   gob             gob!      offset: 3x46 size: 572x503
   options         object!   [content]
   tags            map!      make map! [ panel true ]
   draw-result     block!    length: 45
   intern          none!     none
   name            word!     main-pan
   names           object!   [t1]


I really miss the simple aproach of R2 guys. I wish I had a /pane, 
a simple block of stored subelements, accessible via normal rebol 
series functions, so no need for me to investigate the special purpose 
functions. That's what I call simplicity.

Script: "Include" Version: $Id$ Date: 27-Oct-2010/9:57:54+2:00

** Script error: skip does not allow none! for its series argument

** Where: unless actor all foreach do-style if if actor all foreach 
do-style act

or all foreach do-style actor all foreach do-style either if either 
do-event do-

event either -apply- wake-up loop -apply- wait do-events if view 
catch either ei
ther -apply- do
** Near: unless any [
    not arg/1
    0 >= (pos: arg/1 - parent/sta...

I was pleasantly (but extremely) surprised that the a107 release 
was stable enough to build a new core with. The a1xx series has been 
really experimental, almost as unstable as other people's alpha software.

If you give an index to RL_GET_STRING on a series of single bytes, 
it will return an address computed as if the items are double bytes

Yes, that's not the issue. I'm inversing the length because the series 
is always a BINARY

what's the word to remove one series from another?

there is also a really usefull missing "set" function


duplicates:   returns items in a series present multiple times in 
that series.


without this function, right now there are many missing combinations.

well, AFAIK duplicates is probably the single most frequently re-requested 
series function I've seen in the years.

What should this function be called, and what options does it need?

change-in: funct [key value] [
    either a: find block key [change next a :value][
        repend block [key :value]
    ]
]


It basically implements the a/key: value operation of maps, but for 
series.

SWAP is designed for just this situation, and has been backported 
to R2 as well. Here is the source if you have an old R2 version:
swap: func [
    "Swaps elements of a series. (Modifies)"
    series1 [series!]
    series2 [series!]
][
    unless any [empty? series1 empty? series2] [

        poke series1 1 also pick series2 1 poke series2 1 pick series1 1
    ]
    series1
]

Note that the unless guard above is compatible with the R3 version. 
If either series is empty or at its tail at that position, it's a 
noop, silently.

Yeah, I will. But I expect problems, gob! series support is very 
limited.

Merge sort is for when comparisons are *really* slow, sorting disk 
records slow. You have to have a really heavyweight mezz compare 
function to justify that. The overhead of the second series would 
be pretty high in cases where the speed difference would really matter. 
One of the inplace sorts would be better, as long as it's stable.

Not optimal, but a start:


bubble-to-front: funct [series index] [for i index 2 -1 [swap b: 
at series i back b] series]

swap-sub: funct [series position] [loop (n: length? series) - position 
+ 1 [bubble-to-front series n] series]

If the two series lengths are L1 and L2, I get L1+L2-1 swaps -- at 
most. But there are exceptions, eg:
    [a b c d   1 2]

Needs only 4 swaps....An any [{L1 // L2) = 0 (L2 // L1) = 0] test 
triggers a shortcut.


However .....I also have some edge-case bugs in my code -- so you 
win!!

Now I will rewrite it, with different input parameters, so that it 
can swap sup-parts of larger series.

Steeve, good fun. I came to a swap-sub using modulo as well, but 
it only worked for some series lengths, and I had to sleep before 
figuring out which lengths they were, but they surely included prime 
numbers.

(I used only a single loop). I thought maybe I could detect which 
series lengths could be processed using only a single loop, and other 
cases could be processed using another algorithm.

You said above "so that it can swap sub-parts of larger series". 
Is that what you mean?

Steeve, 

What might be interesting (and possibly even ... useful) is to generalise 
to be able to swap (rotate) any number of sub-series, eg.
for three sub-series in a series [... AAA ... BBBB ... CC ...]
AAA moves to where BBBB is currently,
BBBB moves to where CC is currently, and finally
CC moves to where AAA is currently.

Normally I would like to limit the occasions where an unset! can 
get through without errors triggered (those errors are the whole 
point to the unset! type), but in this case the other series manipulation 
functions accept any-type!, so consistency wins here. +1 any-type!.

>> blk: copy [1]
== [1]
>> blk/1: #[unset!]
** Script error: blk/1: needs a value
>> poke blk 1 #[unset!]
** Script error: poke does not allow unset! for its data argument
>> head insert blk #[unset!]
== [unset! 1]

What other series funcs are you think of Brian?

If any-type! is allowed, should the behavior be like INSERT?

what is purpose to have #[unset!] in a serie

 - well, it was not me who 'introduced' #[unset!] to Rebol series.

So, instead of the R1 approach, Carl 'introduced' #[unset!] into:

*results of Rebol expressions
*values you can set Rebol words to using SET/ANY
*values you can "store" to and "retrieve" from Rebol series

, etc.

This came up in a CC ticket for another series function once, and 
the reasons for the choice made there apply here as well. There are 
two main reasons that you would want series functions to be able 
to handle unset!:

- This gives the error context, so when it is triggered you can get 
an idea of what the conditions were that caused it.

- Your code might be structured to handle errors on output from the 
series instead of input to it.

I'm able to consistently produce this in 2.7.7:

---------------------------
REBOL Error
---------------------------
REBOL Internal Error: Invalid series width 1 was 16 (type 39)

Program terminated abnormally.
This should never happen.
Contact www.REBOL.com with details.
---------------------------
OK   
---------------------------


Will need to dig a little. Not sure if it's an encryption part, debase 
part or what it is yet, but it occurs, when loading enbased, encrypted 
data.

Here's a working version:

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

Which is why just APPENDing a path! to a block! separately appends 
each component of the path, just as for other series:

>> append t: copy [1 2] [3 4]
== [1 2 3 4]
>> append t: copy [1 2] 'a/b
== [1 2 a b]

If you want to append a series as a whole to another, you use the 
/only refinement:

>> append/only t: copy [1 2] [3 4]
== [1 2 [3 4]]
>> append/only t: copy [1 2] 'a/b  
== [1 2 a/b]

I think that the help for append should be corrected from:


/only -- Only insert a block as a single value (not the contents 
of the block)

to


/only -- Only insert series as a single value (not the contents of 
series)