World: r3wp

32bit integer size?

yep.

Got it. Thought so.

at least it's not negative!

Wouldn't it be possible to get correct decimal number if you get 
negative (overflowed) size as an integer?

(in a limited range:)

and what if the file is 8gb?

Size? is 64 bit -- in theory.  What OS?

(on R3)

he's talking r2

Yep., R2 and then the word that was keeping track of the bytes sent 
exploded so I just changed the progress bar to show activity  and 
skipped trying to track sizes. The main point was to move files from 
one drive to another anyway.

Is this logical?

>> negate 2 - 1
== -1
>> - 2 - 1
== -3


(Notice I put space after the first minus making it a unary minus.)

The above is R2. Unary minus doesn't seem to be implemented in R3.

Yes...
2 - 1 = 1, negate 1 = -1
negative 2 minus 1 = -3

And as for the space:
>> X: 5
== 5
>> -X
** Script Error: -X has no value
** Near: -X
>> - X
== -5

unary minus is Negate (in R3). The R2 case certainly is weird:
- why should binary infix operators behave as prefix?
- why should binary infix - operator become unary prefix?

- why should unary prefix - operator have a different precedence 
than any "normal unary operator in Rebol"?

Only reason to have '-' as unary minus is to be free from having 
to write NEGATE all the time. NEGATE is good though in many cases. 
But having unary minus to have precedence over operators is weird, 
yes. I would be ok with having '-' as unary minus, if it didn't have 
precedence over operators. It should work just like NEGATE. Well, 
design decisions can be hard. :-)

I see it as, the symbol itself, being the binary infix subtraction, 
is what puts it on the same level as operators (not above)...  So 
I still see no contradiction...

And the reasons to not have a prefix minus:

- It's ambiguous with the infix minus, and we don't have a compiler 
to resolve the ambiguity.

- The special case of DWIM for a missing first argument slows down 
DO, and makes user-defined ops not work.

What's the best name for such a function?

f: func[words data][forall words [insert data make set-word! words/1 
 data: skip data 2] make object! head data]

or this one:

f: func[words data][forall words [insert data words/1  data: skip 
data 2] head data]

make-record

Oldes, I have them but in R3.

the first one in an aternative way to make objects.

as-object: func [w d][set w: bind? use w reduce [:first w] d w]

>>as-object [a b c][1 2 3]
== make object! [
    a: 1
    b: 2
	c: 3
]

I named the second one Mixin, with a slightly different code too.

mixin: funco [a [series!] b [series!] /local v][
    parse a: copy a [some [skip if (v: first+ b) insert v] a:]]
    head clear a
]

>>mixin "12345" "abcdefgh"
=="1a2b3c4d5e"

>>mixin [1 2 3 4 5 ] "abcdefgh"
==[1 #"a" 2 #"b" 3 #"c" 4 #"d" 5 #"e"]

I have ALTERNATE and MERGE at the lower levels. The first combines 
two series and returns a new series. The second merges one series 
into another, with a /SKIP refinement. I have TO-SPEC-BLOCK , since 
that's such a useful and common need. I avoided using AS- in the 
past, thinking more standard non-copying coercion funcs would make 
them confusing. Those haven't appeared, so I do use AS- sometimes 
now.

I've just found out from the mailing list that 'exclude creates a 
block of unique items.


so, unique block [block!] is the same as exclude block [block!] [ 
]


So, what's the best way to remove items from a block without making 
the first block unique ?

remove-each x data [find [stuff] x]  ; or whatever other criteria 
you want.

REMOVE-EACH is great. Watch out though - the return type has changed 
from the data block in R2 to the count of removed items in R3. Don't 
know why, Carl wanted the change.

It's modifying though, unlike EXCLUDE.

well, it makes kind of sense, I guess to return something else. returning 
a block from a modifying function seems a little bit like a "round 
circle" to me.

I suppose it's the cheapest thing to return and he thinks it's valuable 
information, so fine. I previously used REMOVE-EACH as a filter though, 
so it means more code for me in some (admittedly rare) circumstances. 
Overall, R3 code tends to be cleaner for most standard code patterns, 
though in some cases the best features are slightly undocumented 
(except in mezzanine code that depends on them).

it's probably a recurring code pattern for him

and now I made a round circle comment :-) (I talk way too much today)

For instance, in R3 (can't check R2 right now on this computer) comparison 
is allowed to unset! and error! values can be done with operators 
if the unset/error value is on the left side of the operator, but 
not on the right. This is because operators redirect to actions, 
and action functions are different depending on their first argument 
(single-dispatch). The comparison actions for unset! and error! can 
compare to other values, but the comparson actions of other types 
don't support comparing to error/unset. The action! function that 
calls the action has a typespec for its first argument that doesn't 
allow error/unset, but the op! redirects to the internal action, 
not the action! function, and it works because it uses a DO trick 
instead of a standard function call.

Arghhhh !!!! My Brain....

Sorry, that was awkwardly phrased. If there was a better way of explaining 
that to newbies that didn't require a full article, it would be in 
the docs.

it's just that your explanation dig out more interesting questions. 
But i'm too tired tonight

Basically, the functions that you see in REBOL aren't necessarily 
the functions that are actually called. For each function type DO 
calls them a little differently, and this eventually gets to the 
actual function code. For most functions the argument spec type checking 
is done by DO, not the function itself. For natives (or mezzanines 
with explicit type checking) there can sometimes be some extra checking. 
Apparently all actions have to do some extra internal type checking 
because the argument compatibility rules are too weird to be expressable 
using the REBOL function spec syntax, so that syntax doesn't tell 
the whole story sometimes - the source of many dismissed documentation 
bug tickets, I'm afraid.

I should start to register some quotes of you an Carl, to be able 
to think about, afterward.

like that one i saw some day ago, about EMPTY? calling TAIL? IIRC

EMPTY? doesn't call TAIL?, they are the same function assigned to 
two different words :)

Are you sure ?

yep tested

But I remember an odd bu

... bug when trying to use EMPTY? as an actor in a scheme

It throwed an error about TAIL?

Port actions are mostly redirected to the scheme, but not (directly) 
the ones that implement the port model itself, afaict.

As for EMPTY? and TAIL?, a function has no way of knowing what it 
is called. That error message generated from within the TAIL? port! 
action guessed wrong.

Oh, it gets trickier (in theory - I've had to do a lot of scientific 
method on the internals, not decompiling). I think that DO does some 
of the function call work, and the function type itself does the 
rest through an internal action. DO handles the evaluation rules 
and builds the stack frame, then passes along that stack frame to 
the function dispatch action of the function type for it to redirect 
to the real code in a type-specific way.


Now it definitely works that way, the only question is whether the 
type-specific dispatch code is built into DO itself, accessed through 
the action dispatch mechanism, or action code called directly without 
going through the action dispatch mechanism. Only Carl or a decompiler 
could say for sure. But really, it doesn't matter because the behavior 
is the same in any case.

Working with schemes, i saw another one thing really disturbing.
Seems that LAST and FIRST use PICK.

But LAST and FIRST are natives and PICK is an action. I always thought 
that ACTIONS may use NATIVES but not the reverse.

Nope, at least not in R3. Natives can call actions, and even call 
function! functions too.

And apparently the type-checking of the left argument of an op! is 
done differently that the type checking of other arguments. Since 
this type checking is apparently done by DO, the type spec of the 
op! or action! function specs is apparently there for documentation, 
not actually used. Instead, DO checks whether the corresponding action 
is supported by the type and goes by that, rather than duplicating 
effort.