World: r3wp

How to waste his time ? Get ladislav's mergesort working in-place.
--> done

Is it faster that way?

Slower, the algorithm more complex, lot of swap.
If it was compiled, maybe...

I wonder, whether the majority of users prefer POKE to stay as-is, 
or would welcome it to accept any-type DATA argument?

I don't use POKE.. what I remeber.. maybe just in some rare cases.

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.

Steeve, did you finish the swap-sub yet? Curious.

It was already, I just changed the inputs for other purposes.

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

yeah, i just had to pass an extra parameter to set the length of 
the added sub-parts, instead of calculate it.
But the algorithm remains the same.

Ok, easy.

Ladislav, does not POKE DATA parameter already accept argument of 
any type ?  ( I checked only Rebol3 alpha 76 (not most recent) and 
Rebol2.7.7).

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.

(but not tonight, for me..)

Should not be that hard with a recursive approach

(I did not say that I will do it)

REBOL 3.0 A110 2-Nov-2010/3:56:20

>> source poke
poke: make action! [[

    {Returns value after changing its data at the given index. (Modifies)}
    value [series! port! map! gob! bitset!]
    index {Index offset, symbol, or other value to use as index}
    data "New value"
]]
>> poke [1] 1 #[unset!]
** Script error: poke does not allow unset! for its data argument

So, I was curious, what the user preferences are. Current poll state:


any-type! DATA : any DATA = 1:0 (counting just myself, no other response 
obtained)

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!.

anyone did anything with Rebol and JVM (Java) integr/cooper-ation. 
I need functionality of some big java lib ("server side") in rebol. 
What would you do or use?

add a port to communicate with the java app?

Ladislav, oh I see. Yep, +1 any-type!

Steeve, would need to convert to iterative to stay memory safe.

>> 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?

I'm not saying it's a useless requirement, but what is purpose to 
have #[unset!] in a serie, instead of anything else working, for 
instance, #[none!].
Just asking...

(#[none], not #[none!])

I was thinking of APPEND and CHANGE too - they both also allow any-type!.

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

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

Steeve, triggering an error is the point of unset!. The none! type 
is for when non-values aren't an error.

nevertheless, since:


change at [1 2 3] 2 #[unset!] works, my opinion is, that poke [1 
2 3] 2 #[unset!] should work as well

In my opinion, there are certain simple and useful states, that we 
can choose from. One of the states might be, that #[unset!] is not 
a Rebol value at all. That approach was chosen for the #[end!] value 
as far as I can tell. Moreover, that approach was chosen even for 
#[unset!] for R1, but, for some reason, Carl declined from it, choosing 
a different approach.

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.

In my opinion, to 'allow' INSERT, APPEND and CHANGE handle #[unset!] 
makes 'disallowing' POKE to do the same uncomfortable.

That is why allowing it for POKE is a good idea.

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.

Does R2/Forward contain fixes to TO-LOCAL-FILE? There are some rather 
significant differences in functionality between the R2 and R3 version.

As a rule, R2/Forward hasn't had any changes to native functions 
in R2, mostly for performance and compatibility reasons. It is intended 
to have an extended version later that attempts to backport as many 
native changes as possible, but that won't be the default because 
it would break a lot of the same R2 code that R3 breaks.

However, TO-LOCAL-FILE? and TO-REBOL-FILE? aren't really that fundamental, 
and were originally written in REBOL, so it might be OK to change 
them if it can be done without breaking code. What are the specific 
differences you have found between the R3 and R2 versions?

Got it: the /full option.

R2:

>> to-local-file to-file "/test"
== "t:\st"

R3:

>> to-local-file to-file "/test"
== "\\test"

Oh, nice. Yes, that's worth doing, and fits within the rules. For 
that matter, it's worth adding to the R2 bug list.

I agree on POKE supporting unset! to match CHANGE and INSERT.

Henrik, that fix is scheduled for 2.7.8, but not the /full option.

yay... the fact that we couldn't support writing out UNC paths easily 
has bitten me at a high-profile client in the past :-)

nice to have that fixed.

It was scheduled for 2.7.8 but didn't make the deadline. So now it's 
still pending.

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.

ok.... it apparently happens when LOADing certain DECLOAKed data, 
but only under specific circumstances.

Does it happen in 2.7.8?

I am unable to test this, as 2.7.7 is heavily integrated into RM 
Asset's build system for the NLPP program