AltME groups: search

Er, no the d function returns the series position

So the issue we discussed about needing to build the map ahead of 
time is taken care of right there.  After this step, G is an ordered 
series of two-element blocks... each with two integers, the coordinate 
pair of where that dot is.

That reuse is what won't be task-safe. Only non-modifiable series 
will be sharable.

It all depends on how sharing of data between tasks is done. It looks 
(currently) like Carl is thinking that PROTECTed series would be 
sharable - this would mean that large swaths of the data in memory 
would be unmodifiable, or duplicated. This makes functional or lock-free 
datastructures even more important for R3.

OK, EQUAL-STATE? is too strict in another way: It also considers 
values that precede the series references. I'm going to figure out 
if it will still work if changed to use the level of equivalence 
expected from EQUAL?. Note:
>> equal? next [a a] next [b a]
== true
>> equal? next [a a] next 'b/a
== false
Not sure about that last one - will it be true in R3?

I'm working with a long time REBOL programmer these days. We discuss 
the language now and then. One thing, we discuss, is how the minimalistic 
syntax can make REBOL hard to read. We can use parenthesis for arguments 
to functions, but we rarely do it. We could write:

insert (back (tail (series))) value

but a REBOL programmer would just write:

insert back tail series value


Even if we use parenthesis, REBOL requre different parenthesis notation 
than other languages. The above code in C would look like:

insert (back (tail (series)), value);

And C programmers often don't write the code this way with functions 
within function calls. They use to write:

void *pointer = tail (series);
pointer = back (pointer);
insert (pointer, value);

or something.

Maybe produce 6.1.2.3.4.5. Tuple has some series things to it:

>> second 12.34.56
== 34

They aren't in series! because they don't have position

What do you mean?

>> t: 11.22.33.44.55.66.77.88.99.00
== 11.22.33.44.55.66.77.88.99.0
>> t/5
== 55
>> third t
== 33

Some series stuff works with tuples, but not all like SKIP.

From the docs:


COPY/types - specify as a typeset the values to be copied. Note that 
you can use /types without /deep, in which case the copy is applied 
only to the top level of values.


COPY/deep - perform the copy recursively on each value. If you use 
/deep without /types, it is assumed that you want to copy all series 
values (any-string!, binary!, and any-block!) but not bitsets, images, 
vectors, maps, functions, or objects.


I'm pretty sure, I won't be able to remember these rules, so I have 
to look it up, every time I use it. Result: I will probably not use 
it, if I don't really really have to.

Also look at my rants in #1223 - call needs some fixes, or it reqires 
you to press enter, once it finishes, as well as it messess console 
output (prompt), as well as call output can't be caught into series 
...

I suggest anyone interested, to read example at: http://www.rebol.net/wiki/Parse_Project#Examples
, to see, how it "feels". AND keyword is like an alien from the outer 
space there, and if there would not be comment at the and of the 
line, stating (after fixig a typo): "Back in the same position as 
before the AND.", you would hardly know, what does have AND (most 
often perceived as logical operation) in common to keeping the position 
at original series index? Why not STAY, KEEP, HOLD?

Or do I understand AND meaning incorrectly?

>> ? split
USAGE:
	SPLIT series dlm /into

DESCRIPTION:

 Split a series into pieces; fixed or variable size, fixed number, 
 or at delimiters

/into is a new refinement for most series. It makes it possible to 
store the result directly in a series without copying. I've been 
watching BrianH jump up and down over this feature a few months ago. 
:-)

Chris, we've been careful to make the interaction model of map! more 
like that of objects than series. You can't parse objects either.

well it's because inside a closure, all series are copied before 
each new run.
it's like having done:

g: make closure! [[/local b s][b: copy [ ] s: copy "" insert b 1 
insert s 1]]

Perhaps we should ask Carl not to copy deep the series when a new 
calling context is created.
Don't know...

Missing something till now.

The sharing of same series is lost when they are serialized. They 
are duplicated instead.

There is missing some internal unique surrogate in the serialized 
format of a serie.
It's why RIF can't be realized until now, i guess...

In all cases, it will be a wast of space for all the small series.

I was thinking about the /into for appending the result to a different 
series.

I think he means both. He just talks about TRUE/FALSE for bitsets:


One possible justification would be if FIND/all is useful for other 
series. For example, a FIND/all on a block might return a block of 
results.

I thought that it would serve to do lookup on multiple different 
targets ("series" switching) ....

That could perhaps be useful. Generally there has been some level 
of index concurrency control with multiple series missing in R2, 
like being able to do a FORALL on multiple series simultaneously. 
I can't remember if R3 solves any of that, because it's been discussed 
quite a long time ago.

so, FORALL is native in R3. that might make it harder to change. 
Otherwise I would suggest, since it uses a word for input series 
to use a block for multiple series:


forall [series1 series2 series3] [print [index? series1 index? series2 
index? series3]]
1 1 1
2 2 2
3 3 3
...

The cases where you have to work on many series of all the same length 
are rare.

I feel, it's a common thing to double sizes of series, when they 
grow. Lua does it too.

Of course, there is a limit, after which the series is grown linearly. 
I don't remember what the limit is.

At least something is usefull to know.

Never initialize the length of an empty serie with a power of 2, 
because twice this length could be really allocated (really annoying 
for large series).
Instead, reduce the length of 1.

ie.
make string! 8 * 1024 (actually, allocates 16 KB, not 8KB)

Instead i will do:
make string! 8 * 1024 - 1 (allocates 8KB, not more)

its a question of taste, in R2 a lot of the series handling stuff 
in some types alienate me more than anything.

** Script Error: copy expected range argument of type: number series 
port pair
** Where: getHTML
** Near: probe as-string copy/part buf find

well, if only the default math operators could accept series of scalars 
by default, it would be incredibly simple and powerful.
It should not be so hard to have that behaviour nativly...
A + [1 2 3 4] == A + 1 + 2 + 3 + 4

There are no series-like ports in R3.

21/9-10:52:50.451-[MTA] New request: [[noreply-:-cheyenne-server-:-org] 
[[gchiu-:-compkarori-:-co-:-nz]] %mlxbgiff 11294044 #[none]]

21/9-10:52:50.452-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'pick
    arg2: 'series

    arg3: [series! pair! event! money! date! time! object! port! tuple! 
    any-function!]
    near: [pick dns-server random length? dns-server]
    where: 'on-init-port
] !

what can be done is to substitute the value directly in the data 
by using change on the series and then moving one step back.  then 
the nnormal parsing will occur and the loaded value's datatype would 
be used normally  :-)

Brian: I'm using mainly FIND, NEXT, BACK, SKIP to navigate in hash! 
values. Hash! type is supposed to be a block! (inheriting all series 
navigation capabilities) with fast lookup times, so I've always used 
it like a block!. That's why I feel like I've lost something with 
map!.

I found a series of problems due to which switching to a non-root 
user and group doesn't work

The testapp script makes this error:

22/6-21:54:04.832205-[RSP] ##RSP Script Error:

        URL  = /show.rsp
        File = /home/henrikmk/sites/testapp/show.rsp


        ** Script Error : empty? expected series argument of type: series 
        port bitset
        ** Where: rsp-script
        ** Near:  [either empty? session/content [
print "<LI>No session variables</LI>"
] [
foreach [name value] session/content [
print [<LI> <B> name ":" </B> mold value </LI>]
]
]]

when I encap embed-demo.r, embed-demo.exe gives this error:

** Script Error: select expected series argument of type: series 
object port
** Where: get-cache
** Near: select cache file


Do I need to do something else? I uncommented "embed" in httpd.cfg.

encapped embed-demo.exe application gives the following error:

** Script Error: select expected series argument of type: series 
object port
** Where: get-cache
** Near: select cache file

When I remove AUTH line from WEBAPP section in httpd.cfg file, the 
browser always returns :ERR_EMPTY_RESPONSE error.
Here is my part of httpd.cfg
	webapp [
		virtual-root "/testapp"
		root-dir %www/testapp/
;		auth "/testapp/login.rsp"
		;debug
	]


in %testapp/  I have test.html and test.rsp they both very simple 
files, I have app-init.r also. But I can never access those files.
In Cheyenne log file I see following error:


10/12-3:11:39.3120-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'second
    arg2: 'series

    arg3: [series! pair! event! money! date! object! port! time! tuple! 
    any-function! struct! event!]
    near: [either url: second pos: find]
    where: 'process-webapp
] !


As a work around I put auth line to a rsp file that just do session/content/login?: 
yes and redirect. 
Do you have any idea? I tested with 0920 and r164.

Gregg, I know your take on optimisation... ;-)


<start rant  ;-) > If I had the same opinion, liquid would still 
be 10 times slower than it is now.   each little part of the changes 
add up and after years it really adds up.  I have some new changes 
which will probably shave off another 5-10% when they are done.  
 It requires several changes (some probably removing  less than a 
%).  its been like that since the begining.  the relative impact 
of any optimisation is always bigger the more you do it.  


the first 1% looks like nothing when you compare it to the original 
100% but after you've removed 25% its now 1.33%... but when your 
app is 10 times faster, that 1% is now 10 % of the new speed.


btw, I'm not trying to justify this specific optimisation, but I'm 
trying to balance the general REBOLer consensus that optimisation 
(in speed, code size and RAM use) isn't important when compared to 
other Reboling tasks... 
 

Have you (using "you" in the general sense, not gregg specifically) 
ever looked at Carl's Code?  its some of the most optimised and dense 
code out there... it hurts the brain... and its very enlightening 
too.  all the little variations in the series handlers often are 
there by  design and all balanced out against the others.  Carl uses 
all of those little variations profusely... to me its in the very 
essence of REBOL to be optimal and constantly be refined, improved, 
and this usually means by shrinking it in all vectors.  

<end of rant  ;-) >

If you are trying to find the largest in a series of not-strictly 
comparable items, then be aware that R2 behaves differently to R3:
     b: reduce [1 none 12-jan-2005 unset 'a copy []]
     last sort b       ;; r2 and r3 agree
     maximum-of  b   ;; r3 has a headache
== [[]]

the main one being that foreach is actually the fastest series iterator!

(probably exponentially faster as the series grows)

but I'm discovering a lot of discrepancies in things like string 
vs block speed of certain loops... 
and a lot of other neat things like:

pick series 1   

is  15% faster  than

not tail? series

profiling almost done... my machine has been looping series and indexes 
non-stop for about 8 hours now  :-)


be ready for the most in-depth analysis on loops ever done for R2 
 ;-)

just for Terry.....


rebol []


feach: func[
	series 
	value
	i "iterations"
	/local result st
][
	prin "feach(): "
	st: now/precise
	x: length? series
	
	while [i > 0][
		prin i
		prin "."
		result: make series 0 

  foreach[s p v] series [if s = value [append result reduce [s p v]]]
		i: i - 1
	]
	prin join " -> " difference now/precise st
	print ["  " (length? result) / 3 "matches found"]
	result 
]


find-fast: func [
	series
	value
	record-length
	i "iterations"
	/local result st s
][
	prin "find-fast(): "
	st: now/precise
	while [i > 0][
		prin i
		prin "."
		result: clear [] ;length? series
		s: head series
		until [
			not all[
				s: find/tail s value
				either 0 =  ( (-2 + index? s ) // record-length) [
					insert tail result copy/part series record-length
					not tail? s: skip s record-length
				][
					not tail? s: next s
				]
			]
		]
		i: i - 1
	]
	
	prin join " -> " difference now/precise st
	print ["  " (length? result) / record-length "matches found"]
	
	head result
]


find-really-fast: func [
	series
	keys
	value
	record-length
	i "iterations"
	/local result st s
][
	prin "find-really-fast(): "
	st: now/precise
	while [i > 0][
		prin i
		prin "."
		result: clear [] ;length? series
		s: head keys
		until [
			not all [
				s: find/tail s value

    insert tail result copy/part at series (record-length * ( -1 + index? 
    s )) record-length
			]
		]
		i: i - 1
	]
	
	prin join " -> " difference now/precise st
	print ["  " (length? result) / record-length "matches found"]
	
	head result
]

test-size: 2000000 ; number of records
iterations: 5
rsize: 3


print "preparing sparse data"
dataset: make block! test-size 
loop test-size [
	; we exclude 9 from dataset
	loop rsize [
		dataset: insert dataset random 8
	]
]
dataset: head dataset
insert at dataset (100 * rsize + 1) 9
insert at dataset (2000 * rsize + 1) 9
insert at dataset (50000 * rsize + 1) 9
insert at dataset (10000 * rsize + 1) 9
insert at dataset (20000 * rsize + 1) 9

probe length? dataset
print "sparse tests:"
feach dataset 9 iterations
print "----------------"
find-fast dataset 9 rsize iterations
print "----------------"
keys: extract dataset rsize
find-really-fast dataset keys 9 rsize iterations
print "----------------"


print "^/dense match with key/value collisions"
dataset: make block! test-size 
loop test-size [
	; we include 9 in the dataset
	loop rsize [
		dataset: insert dataset random 9
	]
]
dataset: head dataset
probe length? dataset
feach dataset 9 iterations
print "----------------"
find-fast dataset 9 rsize iterations
print "----------------"
keys: extract dataset rsize
find-really-fast dataset keys 9 rsize iterations
print "----------------"


print "^/dense match without key/value collisions"
dataset: make block! test-size 
loop test-size [
	; we include 9 in the dataset
	dataset: insert dataset random 9
	loop (rsize - 1) [
		dataset: insert dataset 10 + random 100000 
	]
]
dataset: head dataset
probe length? dataset
feach dataset 9 iterations
print "----------------"
find-fast dataset 9 rsize iterations
print "----------------"
keys: extract dataset rsize
find-really-fast dataset keys 9 rsize iterations
print "----------------"

ask "done"

the series was being skipped one too many (since I'm using /tail 
on the find, as suggested by andreas)

find-fast: func [
	series
	value
	record-length
	i "iterations"
	/local result st s
][
	prin "find-fast(): "
	st: now/precise
	while [i > 0][
		prin i
		prin "."
		result: clear [] ;length? series
		s: head series
		until [
			not all[
				s: find/tail s value
				either 0 =  ( (-2 + index? s ) // record-length) [
					insert tail result copy/part series record-length
					not tail? s: skip s record-length
				][
					not tail? s: next s
				]
			]
		]
		i: i - 1
	]
	
	prin join " -> " difference now/precise st
	print ["  " (length? result) / record-length "matches found"]
	
	head result
]

in the code... 


rsize: 3   is the record size...  like the /skip value in most series 
handlers  

my two funcs will adapt, since you provide it the record size


but ... ehehe, I just realized that find HAS the /skip attribute... 
doh!!! the above can be made MUCH faster still, especially by removing 
the need for the keys (which take a bit of time to generate on large 
lists).

i'll only be generating the initial series rarely, but appending 
/changing/ removing often

here's a better example  

dataset: [ "subject" "predicate" "value" "bob" "fname" "Bob" "bob" 
"age" "42" "Maxim" "age" "unknown" ... ]
so the triple is subject, predicate value  

with the ability to say quickly return   every triple  where "predicate" 
(the second part of the triple)  = "age"


i'm doing this now with MySQL as a triple store, but series should 
be much faster

ultimate-find: func [
	series
	value

 index "field you want to search on, should be (1 <= index <= record-length)"
	record-length
	i "iterations"
	/local s st result
][
	prin "ultimate find(): "
	st: now/precise
	while [i > 0][
		prin i
		prin "."
		result: clear [] ;length? series
		s: at series index
		until [
			not all [
				s: find/skip s value record-length

    insert tail result copy/part skip s (-1 * index + 1) record-length
				s: skip s 3
			]
		]
		i: i - 1
	]
	
	prin join " -> " difference now/precise st
	print ["  " (length? result) / record-length "matches found"]
	
	head result
]

Terry, I think INTERSECT is fine the way it is, and it's easy to 
wrap if you want.

    fold: func [
        series [series!]
        fn     [any-function!]
        /local value
    ][
        value: pick series 1
        foreach item next series [value: fn value item]
    ]

    intersect-all: func [
        series [block!] "A block of series values to intersect"
    ][
        fold series :intersect
    ]

someone had a link the other day which mentioned that the series 
protocol should be available completely

i.e. read on the pop3 port iterates thru all available messages, 
returning an empty series after the last message was read

we can add a series protocol later on

the source avail at http://bolka.at/share/prot-pop3.rcurrently still 
has a series interface

of the series

I don't know what the possible actors are, but I think they're the 
ones related to series.

This is one of those cases where this is an example of errors being 
our friends, rather than that being the rationale. An example of 
errors not being friendly was the R2 bounds checking error on ordinal 
functions, so that condition was redefined as non-erroneous. If you 
need series bounds checking to be erroneous it is quite easy to check 
for that, efficiently (I'd recommend ASSERT). Years of REBOL code 
have shown that this is the less common case though, so R2's behavior 
led to a lot of extra screening code.

Request for help received via REBOL.org's feedback form. If you can 
help, please post here and I'll forward him the URL of the archive:

===============

Using Rebol 3.0 Alpha, 2.100.97.3.1, how can I save the value removed 
from a series when I use the remove function? See example 1 below; 
I would like to be able to save the value "red" in a variable.  Can 
a "parse" statement be used instead of the remove. How would it be 
coded?

See example 2 below. Should'nt the value be "red"

example 1
text: "redblueyellow"
== "redblueyellow"
remove/part text 3
==text: "blueyellow"

Example 2
saved-text: "redblueyellow"
== "redblueyellow"
difference saved-text text
== "d"

I tried this an hour later and got 
== "rd"
===============

Your unblock returns a series of words. You need to have them in 
a series (a block). You can do these:

first reduce [words-of my-object]
or simple
words-of my-object

I can't see, an unblock would be possible.

using clear would imply that an object is a series.

Henrik, the /index option of EXTRACT assumes that there will be something 
there at the index (record length specified is assumed), and that 
the R3-style treatment of series bounds is in effect. That means 
that the programmer is expected to do their own bounds checking, 
or to not care. The none value is a placeholder for missing data.

Does anyone know if these are bugs in R3 or am I missing some new 
feature?

>> append #{} [#{01} #{02} #{03}]
** Script error: invalid argument: [#{01} #{02} #{03}]
** Where: append
** Near: append #{} [#{01} #{02} #{03}]

>> rejoin [#{01} #{02} #{03}]
** Script error: invalid argument: [#{02} #{03}]
** Where: append rejoin
** Near: append either series? first block [copy first block] [
    f...

>> join #{} [#{01} #{02} #{03}]
** Script error: invalid argument: [#{01} #{02} #{03}]
** Where: applier apply repend join
** Near: series reduce :value part length only dup count

Tested under 2.100.97.3.1 version.

binary is a series, and indexes return, like all other series, the 
element which constitutes it at the index you give it.

pekr... here I must say, you really do not know what you are talking 
about.


all the binary changes brought to R3 are due to user responses about 
how fucked up it really was to use binary stuff in R2.   really. 
 I had to build binary data-driven TCP servers in R2, for example, 
and I had to use so many shitty work-arounds and fix up numbers .. 
it was an ordeal.


R3 makes binaries, clean, no hassle and simple.  they are a simple 
series of bytes, nothing more.


they are manipulated from the start to the end in that order.  that's 
all there is to it.

pekr... have you been reading... #{8000} is NOT A NUMBER its a SERIES 
OF BYTES.


you keep refereing to binaries as if they where numbers.  THEY ARE 
NOT

Pekr, I agree with BrianH (as I almost always do).

It seems the confusion is that C or Python's integer representation 
syntax and Rebol's binary datatype look similar, because they both 
use hexadecimal. But 0x8000 in C or Python is really an integer and 
has to fit inside an integer type with some specific size. Rebol's 
binary type is a series type and can be as long or short as you want 
(well, measured in 8-bit chunks, octets), and it doesn't make any 
assumptions as to what the meaning of those octets is.

In Rebol I miss being able to represent integers the way C does, 
it makes translation a bit more difficult.

About remove-each in R3, I dislike the new given output (numbers 
of values removed).
What the point to discard the most powerful feature of Rebol ? 
- Chaining operations on series.

Besides, To count how much values have been removed is trivial to 
do and a very rare use case.

I just use it for series

for me nothing is an empty series or null

actually I would prefer that empty? also is true on a series containing 
spaces only ...

It's good that you have that function then. I prefer to think that 
an empty series or a series full of spaces is something, and that 
none is nothing.

and a series of spaces is not something

Carl just posted this code, to be the new definition of EMPTY?:
empty?: make :tail? [
    [

        {Returns TRUE if empty or NONE, or for series if index is at or beyond 
        its tail.}
        series [series! gob! port! bitset! map! none!]
    ]
]

This means two things, one minor, one major:

- Minor: TAIL? won't take none, so we have an option of triggering 
the error if need be.

- Major: *You can do that kind of thing at all*. This opens a *lot* 
of possibilities :)

Because it has to be rebound, and because inline series data is modifiable.

It seems that the basic series functions all work on Gob!s:

>> until [probe first d d: next d tail? d]
 
make gob! [offset: 0x0 size: 100x100 alpha: 0 text: "gob a"]

make gob! [offset: 0x0 size: 100x100 alpha: 0 text: "gob b"]

make gob! [offset: 0x0 size: 100x100 alpha: 0 text: "gob c"
]
== true

But the "series" action!s have gob! in their spec.

Weird....

>> dp [loop 10000 [change #{00} [2]]]
== make object! [
    timer: 0:00:00.003776
    evals: 30011
    eval-natives: 10004
    eval-functions: 1
    series-made: 1
    series-freed: 0
    series-expanded: 0
    series-bytes: 432
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]

>> dp [loop 10000 [change #{00} 2]]
== make object! [
    timer: 0:00:00.00457
    evals: 30011
    eval-natives: 10004
    eval-functions: 1
    series-made: 10001
    series-freed: 0
    series-expanded: 0
    series-bytes: 40432
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]

(same using 'append, for A98 only)

The baseline:
>> dp []
== make object! [
    timer: 0:00:00.000011
    evals: 8
    eval-natives: 3
    eval-functions: 1
    series-made: 1
    series-freed: 0
    series-expanded: 0
    series-bytes: 432
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]

Example code:
>> dp [change #{00} #{02}]
== make object! [
    timer: 0:00:00.00001
    evals: 11
    eval-natives: 4
    eval-functions: 1
    series-made: 1
    series-freed: 0
    series-expanded: 0
    series-bytes: 432
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]
>> dp [change #{00} 2]
== make object! [
    timer: 0:00:00.00001
    evals: 11
    eval-natives: 4
    eval-functions: 1
    series-made: 2
    series-freed: 0
    series-expanded: 0
    series-bytes: 436
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]
>> dp [change #{00} [2]]
== make object! [
    timer: 0:00:00.000009
    evals: 11
    eval-natives: 4
    eval-functions: 1
    series-made: 1
    series-freed: 0
    series-expanded: 0
    series-bytes: 432
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]


Clearly APPEND, INSERT and CHANGE convert regular values to binary! 
first now (creating a series), then do their inserts. And they don't 
convert first if you use the new block mode. Good to know :)

Seems more obfuscated than a simple binary conversion...

>> abs -432 + get in dp [to binary! 2] 'series-bytes
== 10
>> abs -432 + get in dp [change #{00} 2] 'series-bytes
== 4
>> abs -432 + get in dp [make binary! 3] 'series-bytes
== 4

They have to convert to binary anyways before they can insert it. 
I think that the real bug is that CHANGE binary! block! is *not reporting 
the series it has to create internally*, while CHANGE binary! value! 
*is*. It seems to be a bug in reporting the stats, not a bug in the 
behavior.

PICK and POKE may also do their own conversions using their own buffer 
(it's just a byte). Apparently since CHANGE binary! value has to 
support full TO binary! support, the easiest way would be to actually 
call TO binary!, which would allocate something. Since CHANGE binary! 
block! doesn't need to support full TO binary! support, maybe it 
has its own internal conversion routines that don't call TO binary!, 
and thus don't *report* any temporary series it creates.

Steeve, POKE converts to a binary value, but not a *newly allocated* 
binary value. Instead, it converts directly into place or it converts 
to a buffer (likely a stack-local byte variable or a register) and 
is then put into place. But is *has* to convert to binary, because 
that is what the result is. For CHANGE, APPEND and INSERT, you can't 
use a fixed buffer because you have to be able to support general 
conversions, so you have to allocate a temporary. However, when inserting 
a block you *don't* have to support general conversions, just a few 
specific conversions, so it might in some cases (like integers) be 
able to use the POKE method, or some other preallocated buffer. But 
in some cases, it does allocate a new buffer for the conversion:

>> select dp [change #{00} ["a"]] 'series-made
== 1  ; uses an internal buffer
>> select dp [change #{00} ["abcdefghijklmnop"]] 'series-made
== 2  ; allocates a new buffer

The baseline being:
>> select dp [] 'series-made
== 1

Graham:

If I want to set something to the index of a series, or something 
else if it's not there I have to do this

b: either a: find series var [
	index? a
][ 	default ]

when I'd rather do

 b: any [ index? find series var default ]

So how about letting index? also take none as an argument ?

yeah, but many series and loop funcs aren't natives anyways.

Ladislav, I don't really need to get into the naming mess. I have 
needed the functionality I described for the modifying INCLUDE and 
EXCLUDE for a long time now, especially as modifying set functions 
rather than just single values like ALTER. But I can continue to 
get by without. And it turns out that the set functions often need 
to allocate another series anyways, for hashing, so the modifying 
versions probably don't have enough of a benefit to be worth adding.

When /to is not specified and /skip is, offsets are multiplied by 
the record length, so you are counting in records. This is intentional, 
to allow you to work with fixed records without messing them up. 
If we keep that behavior then the index will be the record index, 
not the series index. It's not a difficult trick, but it should be 
noted.

The source is there already in case you need to use it before the 
next version comes out. The R3 version is:
move: func [
	"Move a value or span of values in a series."
	source [series!] "Source series"
	offset [integer!] "Offset to move by, or index to move to"
	/part "Move part of a series"
	length [integer!] "The length of the part to move"

 /skip "Treat the series as records of fixed size" ;; SKIP redefined
	size [integer!] "Size of each record"

 /to "Move to an index relative to the head of the series" ;; TO redefined
][
	unless length [length: 1]
	if skip [
		if 1 > size [cause-error 'script 'out-of-range size]
		offset: either to [offset - 1 * size + 1] [offset * size]
		length: length * size
	]
	part: take/part source length
	insert either to [at head source offset] [
		system/contexts/exports/skip source offset
	] part
]

does R3 have a mezz called  'LAST?


similar to 'TAIL? I find it usefull... it returns if we are AT last 
item in a series.  

while [not last? series] [.... series: next series]

I just think that 'SINGLE? will hardly ever be used, as it doesn't 
fit well with the naming of all other series handlers.


if LAST? where there, I think we'd use it naturally.  since it fits 
it with TAIL? LAST FIRST, etc.

2.100.99.3.1  the use of  function  at  with negative index simply 
returns the whole series - which reminds me to ask why   at   with 
index 0 doe not return the series atfter the last item i.e. place 
you at the end of the series?  The docs for  at   specify behavior 
for a negative index      "Using a negative index N, you can go N 
values backwards in a series:"   PS   I have relocated to Fredericton, 
NB, Canada.  Lovely, green and interesting.

Interesting. I think that's a bug, as CLEAR's spec is as follows:

clear: make action! [[

    {Removes all values. For series, removes from current index to tail 
    and returns tail.  (Modifies)}
    series [series! port! map! gob! bitset! none!]
]]

The mix of mutating and non-mutating series functions sometimes really 
is maddening. Not to mention the uglyness of the resulting code.

actually difference could handle series .  right now its not used 
on series... or is it?

It treats the series like sets. One of the group with UNIQUE.

Considering that it seems to return "the point of divergence", i.e. 
the position where two series start to diverge.

note that the /library extension will NOT trample or play within 
the R3 memory/GC if I can prevent it.  this is to sidestep the MANY 
stability issues (some incurable) which I have had to deal with when 
using R2 struct! types in lib calls.


the fact that the /library lives outside of the core is a very welcome 
improvement IMHO.  it does mean that we will be duplicating/copying 
RAM... but this happens in other languages as the default for any 
series manipulation... 


we'll see how it evolves, but it may be possible to share some memory 
intensive datatypes, like image!, and vector!... That will depend 
on the evolution of the extensions system itself.