AltME groups: search

Quick comment in support of Gregg's last announcement: I've tried 
introducing a number of folks to REBOL/AltME, and they were deterred 
from using it because of the high amount of noise and the feeling 
that they were "intruding" on a series of private conversations. 
So my feeling on the matter is that wide ranging discussions are 
all well and fine for folks who are *already* here but could deter 
some folks who come to the REBOL world thinking it might be a purely 
technical / support forum.

2.4 Ghz with 2400 series. We will have in about a two months the 
5800 series which operates at 5.8Ghz, possibly at 4.9Ghz too.

Some people can break anything !!! Sorry 


** Script Error: find expected series argument of type: series port 
bitset
** Where: on-release
** Near: if find choice "/top" [
    face/stack/valve/top face/stack glob
    face/redraw
]

hi Chris, I am afraid, that the main objection Carl had was, that 
he didn't like the fact, that the keywords were in fact string-like 
series. (so no symbols) This does not change, if we switch from issues 
to URLs, unfortunately

dont have access to rambo could someone submit an error in the word 
brower for me.  in the find box a down arrow errors with: ** Script 
Error: index? expected series argument
 of type: series port
** Where: pick-next
** Near: sync-funcs-list index? f
show-word first

regarding #3912

The newest Rebol version displays a different error message

***Panic (should not happen) -Invalid series width 1 was 16 (type 
44)

How near is RT to a fix ?

I would say that you can't do *anything* safely on a series reference.

Ladislav, yes, these inconsistencies hold back rebol's reflection 
somewhat.

Maybe it's excusable for ports, though, because they are kind of 
"custom series datatypes"... have to think carefully about that.

can I propose this for R3?

fill: func [
	"Fills a series to a fixed length"
	data "series to fill, any non series is converted to string!"
	len [integer!] "length of resulting string"
	/with val "replace default space char"
	/right "right justify fill"
	/truncate "will truncate input data if its larger than len"
	/local buffer
][
	unless series? data [
		data: to-string data
	]
	val: any [
		val " " ; default value
	]
	buffer: head insert/dup make type? data none val len
	either right [
		reverse data
		change buffer data
		reverse buffer
	][
		change buffer data
	]
	if truncate [
		clear next at buffer len
	]
	buffer
]

I think I was more concerned with the fill function itself and its 
range of arguments... I agree that the reverse stuff is not optimal. 
  could 'FILL itself (a faster implementation) be considered for 
2.7 ?  I've had to implement this kind of func so often...?  it handles 
all series, and transforms non series automatically...  so you can 
easily fill any value:

fill 1 3
== "1  "

also:

zfill: func [i len][fill/with/right i len 0]
zfill 1 3
== "001"


/right might be /left depending on POV  I prefer /right in the sense 
where the output is right justified... a /center could also be added 
pretty easily.

but when you found nothing, there is no index. 0 would give syntactically 
valid results, letting the rest of the program run. just doing wrong 
things. none will at least led to trapping it.

thinking about it, when using series instead of indices, it bails 
out on using, not immediate too. maybe index? pasing none is k.

I vote to leave it like it is.  It makes the most sense to have Index? 
fail on a non-series value.  I've found ANY to be a very handy function 
for handling things like that.  I initially just used it with EITHER 
and IF but its starting to show up in a lot of places in my code 
because it is just nice and concise. ;-)

Jaime: for INDEX? used alone, that may be true. But asking the position 
of a value in a series and asking the index of a value in a series 
are, IMHO, the same question.

pos: find series value

idx: index? find series value

as gabriele says, we have the same problem with series. can be none 
too and fail then.

since i rarely use index when i can use series, i don't know how 
important thatis.

The only time I've found it useful to use index is when using values 
in one series as a key to values in another series. Kind of rare 
when you have select/skip, but sometimes you don't want to modify 
the data series. All right, since RAMBO says that there are problems 
with select/skip right now, maybe not so rare.

thats one way to see it, which i partly share.

but with series its the same kind of exception, and Gabriele argues 
we could deal with it like we do with series: give none and trap 
on access.

and the "flow" in such cases is to use the patterns i showed, with 
'if or 'any. and not forcing an extra assignment.

Which of the other series functions also work on none, instead of 
just returning it?

Well, if you consider index? find to be another way of saying find/index 
(if such a thing existed) then I can see why you would let it accept 
none. If you consider index? to be a seperate function, then accepting 
none would just be propagating an erroneous condition. Remove should 
definitely accept none because it's not much of a stretch to change 
its meaning from "remove here" to "remove here if there is something 
to remove, no-op if inapplicable", the same behavior it has as in 
 remove tail series.

But Remove Tail Series is programatically different than Remove None 
as Tail returns an apparently empty series, not none.

with blocks, I don't think that'll work with match, because it searches 
for the full element in a series, thus you need to search in two 
levels...

Regarding the question on the mailing list on extracting a series 
of duplicates, I wonder why Rebol doesn't allow us to subtract one 
series from another.  If we are allowed to append one series to another, 
why not allow us to subtract?
But I guess the problem then is sameness.

CHANGE series value

Change seem to have destination first aswell. Didn't Carl write a 
blog about it at some time?

Brock: where I am tempted to use 'copy, I'm often try and think of 
any potential benefits of using series modifiers instead.  Depends 
on the situation I suppose...

An important aspect of dialects, for me, is that they *don't* look 
like a series of function calls; there is often "implied state" which 
I think is powerful, but messes you up if you think in terms of functional 
programming.

Wait a minute ! MOLD handles any value, while MOLD-CSV-STRING only 
handles series at the moment... hang on.

Anton,  What do you think of this approach -- I'm just thinking it 
through and am not sure if I have covered all the bases.

Since my input can contain any number of symbols, commas, single 
and double quotes, and rarely, but possibly braces, what if I attack 
the problem a different way.  Whenever an embedded comma, or double 
quote or something like that occurs within an spreadsheet cell, it 
will require some kind of "extra" formatting like two quotes or the 
like.  It may even be that there are unique combinations of such 
symbols, rare as that would be, to have complex formatting of an 
input block for rebol to convert it properly for CSV.


What if I shift gears and look at a TAB delimited file instead.  
I know that I will never have TAB embedded in my cells, and that 
I deal with the entire block as a series instead.  I could embed 
TAB wherever needed to separate the columns and leave the remaining 
string the way it is.  Would that work, or would I still need to 
do some formatting to handle it.  I think I'll open an excel spreadsheet, 
and work in reverse to see what it needs for TAB delimited file. 
 Any comments?

I don't , but let's see how close this gets us. First, here is a 
support func for building delimited series. In addition, you'll need 
my COLLECT func from REBOL.org, or something similar.

delimit: func [
        "Insert a delimiter between series values."
        series [series!] "Series to delimit. Will be modified."
        value            "The delimiter to insert between items."

        /skip   ;<-- be sure to use system/words/skip in this func

            size [integer!] "The number of items between delimiters. Default 
            is 1."
    ][
        ; By default, delimiters go between each item.
        ; MAX catches zero and negative sizes.
        size: max 1 any [size 1]

        ; If we aren't going to insert any delimiters, just return the series.

        ; This check means FORSKIP should always give us a series result,
        ; rather than NONE, so we can safely inline HEAD with it.
        if size + 1 > length? series [return series]
        ; We don't want a delimiter at the beginning.
        series: system/words/skip series size

        ; Use size+n because we're inserting a delimiter on each pass,

        ; and need to skip over that as well. If we're inserting a

        ; series into a string, we have to skip the length of that

        ; series. i.e. the delimiter value is more than a single item
        ; we need to skip.
        size: size + any [

            all [list? series  0] ; lists behave differently; no need to skip 
            dlm.

            all [any-string? series  series? value  length? value]
            all [any-string? series  length? form value]
            1
        ]
        head forskip series size [insert/only series value]
    ]

;One tip if you are new like me
  save %hist_001.r system/console/history
; then in user.r
  system/console/history: load %hist_001.r
: when you have materials worth reviewing as you learn ....


; PS  I meant 'former' as model, i.e, "Little Schemer"  "Seasoned 
Schemer" "Reasoned Schemer"

Prolog has the 'Art of .. ' 'Craft of ' and 'Practice of Prolog' 
series

; tutorials  on series and find/part

; I may be alone in thinking that without experimenting, a newbie 
will miss this ...  here is my experiment

; the docs say part will accept a 'range' but give no clear indication 
what a 'range' is in 2.x
text: {
    Tested this before.
    Then test these.
}

start: find text "this"
end: find start newline
item: find/part start "this" end
print item

index? find text "this"
index? start
length? start
index? end
length? end
head start
head end
index? item
head item

; by now you get that Ah-Hah experience or Eureka! or 'hot-damn!' 
as the case may be ...

; the docs say
/part - Limits the search to a given length or position. 

range - The range argument. (must be: number series port) 


; but it is not clear how to pass in that range argument as a 'position' 
let alone a series or port

; the only sign of something going wrong other than an error is that 
the 'end' is simply spit back out at the console, i.e., no error 
but bogus 'result''

The simple thing to state would be that the 'range' option in question 
is precisly that same series, albeit with the current position shifted 
out further.
>> item: find/part start "this" 24
>> item: find/part start "this" (find start newline)
; range as port ( I have not yet seen this )

ditto for copy/part

As Newbie I have to realize that the 'series' mentioned in the HELP 
is that self-same series.

I would have my tutorial read:
	some series S at some position
	that same series S at some further position

And: think of 'find' as 'try to reposition current index in the series'

Without seeing the source for FIND, I have no idea yet how to explain 
that 'range' must be that very same series.  Chalk it up to lack 
of imagination...

What I'm getting at is there are limitations in the default handling 
of paths.  But paths are series and you can evaluate them however 
you want to.

Once there are only subblocks it becomes trivial;  I have been trying 
to augment a path! series which starts with a block in which a tagged-word 
is bound to a block .  By augment the path I mean to return a path, 
not the result of evaluating the path
  t1: [ a-word-with-no-value-functor "one" ]

  t2: [ functor t1 ]  ; t1 is a word, not a block, but is bound to 
  a block at the time the path is extended into it ( if possible without 
  t2 being an object! )
  t2: context [ functor t1] ; also trivial

Yes I've only used it for my licence creator applet - I't's one of 
the core items I need to master. At the moment I'm trying to get 
blocks/series to fit into recursions I have created in legacy apps

btw, about your append question... no, append does not need to allocate 
memory at each call. each series has some space free, and when that's 
up, a bigger space is allocated, usually with 2x increments (until 
a certain size, then it's linear). however, the whole series needs 
to be copied when that happens. so, if you append 1000 times, it 
may happen just 2 or 3 times, but still, if you know the final size 
already, you can save a lot by just preallocating it.

join always returns a string unless the first value is of type? series.
>> join 1 2
== "12"
Try
   source join
to see the actual code.

The end game is to create a series of routines that will cut a full 
install of XP from Approx 1.5 gig installed to approx 212 mb's specifically 
geared for diagnostics and repair.

you'd use  var: 0  since 0 (an integer!)  is not a series type of 
data.

Thanks for the tips, so either exactly replaces if/else

and I need to initalise series types with var: copy [] but not other 
types.   

These tips are great.. I just need to study it more & I shoud find 
my own bugs (and probably remember them too)  Thanks very much

And so if you specifically want to keep a series from being changed 
by some operation, you must copy it.

ah. so this is for variables containing series types only? numbers 
get passed as values (which is in effect a copy?)

Series, yes. You can also reference objects this way.


Another trap is that series within series are also reused. This is 
why COPY/DEEP exists.

If you know when REBOL reuses series, you can make quite memory efficient 
and fast code.

If you don't know, then you can get some strange bugs. If a series 
changes without an apparent reason, then it's likely due to whether 
it's copied or not.

Because the contents of a function is really a context, and once 
that function is created, it doesn't disappear, including the blocks 
and series that are existing in that function. (We have to be careful 
here about using the word "context" to describe what we say, and 
the concept of "contexts" in REBOL. Don't mix it up.)

It is initially confusing, because the apparent strange behaviour 
is limited to series, not (not sure what the official term is) numbers.

If you try this:
f: func [a /local b c] [b: [] c: 0 append b a c: c + a]
f 1
f 2
source f


You can see that (quite literally, in a metaphorical sense) the in-memory 
copy of function f has been changed:
f: func [a /local b c] [b: [] c: 0 append b a c: c + a]
f 1
f 2
source f


To not have it change in that way (or to re-initialise b, if you 
like):
f: func [a /local b c] [b: COPY [] c: 0 append b a c: c + a]
f 1
f 2
source f

But 'c has not changed in either case:
  c: 0
means exactly what it says.

mike: the best tip I can give you is to picture a cursor in your 
head when you type your rules.  parse really is about iterating over 
a series on byte at a time and matching the next expected characetr.

set words within parse rules are set to the point in the series that 
the parser IS , AT that exact moment.

REBOL []

do %include.r
include %file-list.r


flash-wnd: flash "Finding test files..."

if file: request-file/only [
    files: read first split-path file
]
if none? file [halt]

items: collect/only item [
    foreach file files [item: reduce [file none]]
]

unview/only flash-wnd



;-------------------------------------------------------------------------------
;-- Generic functions

call*: func [cmd] [
    either find first :call /show [call/show cmd] [call cmd]
]

change-each: func [
    [throw]

    "Change each value in the series by applying a function to it"

    'word   [word!] "Word or block of words to set each time (will be 
    local)"
    series  [series!] "The series to traverse"

    body    [block!] "Block to evaluate. Return value to change current 
    item to."
    /local do-body
][
    do-body: func reduce [[throw] word] body
    forall series [change/only series do-body series/1]

    ; The newer FORALL doesn't return the series at the tail like the 
    old one

    ; did, but it will return the result of the block, which is CHANGE's 
    result,
    ; so we need to explicitly return the series here.
    series
]

collect: func [
    "Collects block evaluations." [throw]
    'word
    block [block!] "Block to evaluate."
    /into dest [block!] "Where to append results"
    /only "Insert series results as series"

    /local fn code marker at-marker? marker* mark replace-marker rules
][
    block: copy/deep block
    dest: any [dest make block! []]

    fn: func [val] compose [(pick [insert insert/only] not only) tail 
    dest get/any 'val

        get/any 'val
    ]
    code: 'fn
    marker: to set-word! word
    at-marker?: does [mark/1 = marker]
    replace-marker: does [change/part mark code 1]
    marker*: [mark: set-word! (if at-marker? [replace-marker])]
    parse block rules: [any [marker* | into rules | skip]]
    do block
    head :dest
]

edit-file: func [file] [
    ;print mold file

    call* join "notepad.exe " to-local-file file ;join test-file-dir 
    file
]

flatten: func [block [any-block!]][
    parse block [

        any [block: any-block! (change/part block first block 1) :block | 
        skip]
    ]
    head block
]

logic-to-words: func [block] [

    change-each val block [either logic? val [to word! form val] [:val]]
]

standardize: func [

    "Make sure a block contains standard key-value pairs, using a template 
    block"
    block    [block!] "Block to standardize"
    template [block!] "Key value template pairs"
][
    foreach [key val] template [
        if not found? find/skip block key 2 [
            repend block [key val]
        ]
    ]
]

tally: func [

    "Counts values in the series; returns a block of [value count] sub-blocks."
    series [series!]
    /local result blk
][
    result: make block! length? unique series

    foreach value unique series [repend result [value reduce [value 0]]]
    foreach value series [
        blk: first next find/skip result value 2
        blk/2: blk/2 + 1
    ]
    extract next result 2
]


;-------------------------------------------------------------------------------

counts: none

refresh: has [i] [
    reset-counts
    i: 0
    foreach item items [
        i: i + 1
        set-status reform ["Testing" mold item/1]
        item/2: random/only reduce [true false]
        show main-lst
        set-face f-prog i / length? items
        wait .25
    ]
    update-counts
    set-status mold counts
]

reset-counts: does [counts: copy [total 0 passed 0 failed 0]]

set-status: func [value] [set-face status form value]

update-counts: has [pass-fail] [
    counts/total: length? items

    pass-fail: logic-to-words flatten tally collect res [foreach item 
    items [res: item/2]]
    ;result (e.g.): [true 2012 false 232]
    standardize pass-fail [true 0 false 0]
    counts/passed: pass-fail/true
    counts/failed: pass-fail/false
]

;---------------------------------------------------------------


main-lst: sld: ; The list and slider faces
c-1:           ; A face we use for some sizing calculations
    none
ml-cnt:        ; Used to track the result list slider value.
visible-rows:  ; How many result items are visible at one time.
    0

lay: layout [
    origin 5x5
    space 1x0
    across

    style col-hdr text 100 center black mint - 20

    text 600 navy bold {

        This is a sample using file-list and updating progress as files are
        processed. 
    }
    return
    pad 0x10

    col-hdr "Result"  col-hdr 400 "File" col-hdr 100
    return
    pad -2x0

    ; The first block for a LIST specifies the sub-layout of a "row",

    ; which can be any valid layout, not just a simple "line" of data.

    ; The SUPPLY block for a list is the code that gets called to display

    ; data, in this case as the list is scrolled. Here COUNT tells us

    ; which ~visible~ row data is being requested for. We add that to 
    the

    ; offset (ML-CNT) set as the slider is moved. INDEX tells us which
    ; ~face~ in the sub-layout the data is going to.

    ; COUNT is defined in the list style itself, as a local variable 
    in
    ; the 'pane function.
    main-lst: list 607x300 [
        across space 1x0 origin 0x0
        style cell text 100x20 black mint + 25 center middle
        c-1: cell  cell 400 left   cell [edit-file item/1]
    ] supply [
        count: count + ml-cnt
        item: pick items count
        face/text: either item [
            switch index [
                1 [

                    face/color: switch item/2 reduce [none [gray] false [red] true [green]]
                    item/2
                ]
                2 [mold item/1]
                3 ["Edit"]
            ]
        ] [none]
    ]

    sld: scroller 16x298 [ ; use SLIDER for older versions of View

        if ml-cnt <> (val: to-integer value * subtract length? items visible-rows) 
        [
            ml-cnt: val
            show main-lst
        ]
    ]
    return
    pad 0x20
    f-prog: progress 600x16
    return
    status: text 500 return
    button 200 "Run" [refresh  show lay]
    pad 200
    button "Quit" #"^q" [quit]
]

visible-rows: to integer! (main-lst/size/y / c-1/size/y)

either visible-rows >= length? items [
    sld/step: 0
    sld/redrag 1
][
    sld/step: 1 / ((length? items) - visible-rows)
    sld/redrag (max 1 visible-rows) / length? items
]

view lay

I would like to see a rewrite that lets it work on a series of text 
documents, build a TOC an link to subdocuments, like the HTML REBOL/Core 
manual.

I have the same makedoc version 2.5.7 and view 1.3.2.3.1. I've tried 
that exact example as well though with verbose on I am seeing an 
error:

** Script Error: copy expected range argument of type: number series 
port pair
** Where: debug
** Near: copy/part here find here newline

search for a series of capitalised words and strong them

I guess it can't be otherwise we wouldn't need to use 'copy on series

The series copy thing is something different.

firsttime?: true 
parse [1 2 3 4 5][
	any [
		set v integer! 
		p:   ; <-- set P to the current parse position.

       ; (This is the input series with the series index at the current 
       position.)
		
		(
			; Here inside the paren is normal rebol code 
			
			prin v 
			if all [firsttime? v = 4][

    p: skip p -2   ; <-- move the index of the series referred to by 
    P
				firsttime?: false
			]
		) 
		
		:p   ; <-- set the current parse position to P
	]
]

; Try against this, the forskip code with the skip part taken out
forall: func [
    "Evaluates a block for every value in a series."
    [catch throw]

    'word [word!] {Word set to each position in series and changed as 
    a result}
    body [block!] "Block to evaluate each time"
    /local orig result
][
    if not any [
        series? get word
        port? get word

    ] [throw make error! {forall expected word argument to refer to a 
    series or port!}]
    orig: get word
    while [any [not tail? get word (set word orig false)]] [
        set/any 'result do body
        set word next get word
        get/any 'result
    ]
]

except that this code is wrong for series with repeting characters 
like "AABCC"

moreover , i just  don't want parse simple series like "ABC"

I'm doing something like this:

view layout [

 b: box effect [draw [pen red fill-pen red line-width 2 shape [line 
 0x0 40x0 40x40 0x40]
	]
	]

 btn "append draw" [append b/effect/draw compose ['pen green 'fill-pen 
 green 'shape ['line 5x0 30x5 5x25 0x20]]show b]
	]

Its much more complicated as I'm painting highlights on a series 
of faces in a panel. I go back and highlight in another color where 
a specified word is found. The hi-lite shows if its on a section 
of text not yet painted but not if it falls on painted text.

The above example works!

so it must be some where else in my app...

Thanks. I'll look it over...

I'm not quite sure how to pan this out.  Also, the 'name rule doesn't 
have any set words, it is operating on an unnamed series.  I think 
I want this type of rule to match the content.  In that if [string! 
string!] does not exactly describe the content, 'name throws a bad-format 
error.

Sunanda: I feel from my experience with parse that it's the sort 
of thing that can, if it fits your problem, help you a great deal... 
but it often seems to be just short of the needed functionality. 
 I feel if your task does not depend on knowing the true/false result 
of matching, then series operations are often better.  I've been 
thinking "if you don't use the boolean result of parse, you probably 
aren't working on a task that needs parse."

(or Did Bill Buckner Lose the 1986 World Series)

probably specific series of distros. some distros use different ways 
of handling configuration, installation and some distros are changing 
the library versions constantly.

sorry ...
benchmark building table:0:00:00.14

** Script Error: find expected series argument of type: series port 
bitset
** Where: switch
** Near: find picked (buffer/:mark)

benchmark building table:0:00:00.14

** Script Error: find expected series argument of type: series port 
bitset
** Where: switch
** Near: find picked (buffer/:mark)

Need some help...Can't seem to get Uniserv working on my XP laptop. 
 This is my first try...so I don't have enough experience to see 
what is happening.  Do I have the wrong version of core?

>> uniserve/boot
[uniserve] Async Protocol Admin loaded
[uniserve] Async Protocol DNS loaded
[uniserve] Async Protocol FastCGI loaded
[uniserve] Async Protocol HTTP loaded

** Script Error: change expected series argument of type: series 
port
** Where: install-plugin
** Near: change pos/2 new
>>

I figured out how to stop the service tying up the 80 port , When 
i run this is what I get: >> do %/c/temp/rebol/uniserve/uni-engine.r
== true
>> uniserve/boot
[uniserve] Async Protocol Admin loaded
[uniserve] Async Protocol DNS loaded
[uniserve] Async Protocol FastCGI loaded
[uniserve] Async Protocol HTTP loaded

** Script Error: change expected series argument of type: series 
port
** Where: install-plugin
** Near: change pos/2 new

i and o could be series parameters

Here are some initial comments on the recently posted rebcode documentation 
draft:

- It has been suggested on the list that since the assembler's rewrite 
engine is a mezzanine, it might not be included in the final version, 
in favor of (to promote?) user-made rewrite engines. If not, you 
would need to change the documentation to match, especially section 
1.4.

- It needs to be made clear somewhere in the initial description 
of the rebcode dialect that rebcode is a statement-based language, 
not an expression-based language like the do dialect. Opcodes perform 
actions, but don't return anything per-se. The 2.1 or 2.3 sections 
would be a good place for this explanation to be.

- In the "Branches are always relative" note at the end of 2.6, there 
is a sentence "The branches are always relative to the current block." 
that could be removed. The whole note should probably be renamed 
to "Branches are always local" because the note doesn't really cover 
that they are also relative. Also the phrase "use a branch opcode 
to" could be replaced with "branch to" and be less awkward.

- A common mistake in specifying literal branch offsets is to miscalculate 
what location the offsets are relative to. This mistake would be 
less likely if the third paragraph of 2.8 were changed to "The argument 
to the branch opcodes is an integer value, representing how much 
of an offset you want the branch to perform. Branch offsets are always 
relative to the location after the branch statement, not the absolute 
offset within the block. Positive values branch forward; negative, 
backward. The branch target must always fall within the current code 
block." as this is the actual branch behavior (and more clear).

- The sentence in 2.8 "The brab opcode allows computed branch offsets 
to be created." isn't really true right now, at least in any practical 
way. The current behavior is more like "The brab opcode allows you 
to branch to an offset selected at runtime by an index.".

- The paragraph at the end of 2.8 "There is also a special case of 
operation. If the block argument to BRAB is an integer (created from 
a label), then the branch is made to that relative location plus 
the value of the index argument." would be a good idea to be implemented 
(I've submitted it to RAMBO), but is rather awkwardly phrased. This 
could be rephrased once the behavior is implemented, or left alone 
if you don't want most rebcode users to use this behavior.

- In section 2.9, the sentence "Result then refers to the value returned 
from the function." may be better said as "The word result is then 
assigned the value returned from the function.".

- 4.1.*: The phrasing of many of these entries is awkward. Also, 
remember that opcodes don't return anything, they modify operands.

- 4.1.1: I'm not sure "integral" means "the integer part of" as it 
is used here; the word may be more related to integrate than integer.

- 4.1.4: Lowercase the "Tail" word to be consistent. Otherwise, well 
phrased.

- 4.1.5: The descriptions of change, copy and insert don't describe 
how their amount parameter is used. You could describe change as 
"Changes part of a series at the current position to that part of 
a value (-1 for the whole value).", copy as "Set the operand to a 
partial copy of the series (-1 for all) from the current position.", 
and insert as "Inserts part of one series (-1 for all) into another 
at the current position.". Or, you could provide further explanation 
in some new 2.* section.

- 4.1.6: In the description of index?, change "Returns the" to "Set 
the operand to".

- 4.1.7: Does not reflect the renaming of the opcode get to getw 
and the addition of setw. Also, instances of "Result modified" should 
be changed to "Set result" or "Set operand to result".
- 4.3.3: The braw opcode has been removed.

The variables swapping over are yp and sev - yp is an integer and 
sev is a series..

yes but combining operations need more tests so it will decrease 
overall performance. i do'nt see how i can do that without consumming 
more times to compile series of opcodes

rebcode can only handle byte series

i could handle 16 bit registers directly in binary series

that could be faster if 16 bits register was handled internally as 
binary series

M6replay is a VOD website to replay the series or emitions from the 
M6 TV channel wich is supposed to be view by a large number of people

I like  2.7.6 is the last of the 2.x series.  Brian may release a 
library containing updated mezzanines and patches.

ports - the basic idea is that ports stay as series abstraction, 
and we add device! for things that are not series (think of them 
as AmigaOS devices). no more details are available and this is still 
subject to change so don't take my words as an announcement.

IMHO, more importantly this should happen when used with series: 

f: func [/blk = [] ] [append blk "a" probe blk]
f
==> ["a"]
f
==> ["a"]

Peter, ok idea, and I'm all for that. There just shouldn't be a limit, 
and we have to use integers to reach later parts of a vector ... 
like with series.

if pair will be extended it overloads 16 byte limit for slot and 
become a series datatype, something complety different. there can 
be only 10 bytes per value ( I don't know exacly but tuples can have 
only 10 bytes not more)

its consistency.  and although its not english, its damn easier to 
remember that way.  they all use the same "SERIES first" approach.

probably because having series first means all arguments treating 
data follow it.

instead of having the series jump around in one function to another.

don't closures also help with the copy problem?  where each time 
you run the closure, a series is indeed new?

well I didn't say "solve"  ;-)  but by what I understand of closures 
(and I have been reading a lot lately) if 'closure does a deep copy 
without empty series optimisation, then we could rely on it.


actually, NOT copying empty series would make closures bugged, since 
all generated closures would referrence the same empty block from 
the context of the closure's definition.  which is in direct contradiction 
to the concept no?

Personally, I've never really considered the "copy problem" a problem. 
When you don't copy something it doesn't get copied. When you do 
it does. Series aren't immediate values, they are reference values. 
Same for objects. Every language design choice could be considered 
a bug or a feature - it all depends on how you use it. I've found 
more advantages to the way that REBOL functions work now.


The only real problem I've run into is functions keeping references 
to their temporary data after they return, at least until they are 
run again (a memory hole). The closure example above with the adders 
stops being a problem when you realise that FUNC is a function that 
does something when passed a  couple blocks - it's not syntax. You 
didn't copy the block, so it gets reused, go figure. You are building 
functions - is it such a stretch to build code blocks?

make-adder: func [n] [func [x] compose [x + (n)]]

Henrik, good suggestion with the loop working on more than one series 
(in your reply to Carl's blog). That must be possible with a function 
definition. But it should probably be part of REBOL, at least a mezzanine.

If the inserting is the problem, then I might be able to fix that 
with copy to another series in stead. Problem with insert is, when 
you have large series, it has to move the content down the memory.

Ah, what wonders a few hours of rest can work.  I just need to produce 
a plug that takes a series of inputs and converts it into an object. 
 I was overcomplicating things (again...)  When I get back from work 
I'll take another shot at it and this time I think I'll go with a 
dialected approach.

an obvious example is a setup where you have a series of inputs, 
which are all linked to one plug which compiles them as an object.

I'm thinking this is not a good error to get ..

Script: "Untitled" (none)
## Error in [task-handler] : Make object! [
    code: 316
    type: 'script
    id: 'no-memory
    arg1: none
    arg2: none
    arg3: none
    near: [insert tail series :value]
    where: 'append
] !
/

Oldes, thanks, I've made a minimal url-encode function (due to lack 
of time). I'll wrote a better one for the next release. Not sure 
what approach is faster, changing the argument series or building 
a new one...will test that.

Yes. Any series containing characters only.

Functions that support series usually support binary!, but usually 
not functions that are specific to strings.