World: r3wp

does this deserve mentioning in RAMBO?

    block: next [1]
    copy/part block -2147483647 ; == [1]
    copy/part block -2147483648 ; == []

not sure... but one more ticket won't kill us :)

Hmm.. I've often considered whether to immediately submit a post 
of dubious importance. It would be nice to reliably delay my submission 
by six months or so. Maybe by that time the submission would become 
irrelevant because of a fix or new rebol version etc, and by not 
posting it I am keeping others free from distraction. But I am not 
using calendar software to remind me. (One of my goals this year 
is to start using calendar software.)

one of goals this year is to start using A calendar... period  ; 
-)

(Well, I currently use a paper-based diary.)

I used a mangled brain with continuous stack overflow...  ;-)

Stack overflow - same here. Not something to be proud of.

just tooo many projects only only coding, but the house, familly 
,etc...

oops first only=not

Lad, I think it is sensible to add to RAMBO. But what is a sensible 
result. For that case?

Jaime: since all other negative values yield [1], it seems like the 
intended result and the least surprise. Any other opinions?

I agree - the least surprise.

Humm. I think it should return []

Since tail? next [1] ;== true and next next [] ;== []

Also, >> copy/part [1 2 3] -1
== []

So I don't see why copy/part next [1] should yield [1]

copy/part is relative
>> copy/part at [1 2 3 4 5] 4 -2
== [2 3]

I think it's not well known.

Anton thats not the issue copy/part is missbehaving when the block 
is at its TAIL position.

You misunderstand - the bug is not because the series index is at 
the TAIL, it is because the copy/part RANGE is -2147483648

To be clear ;  when the copy/part RANGE is *negative* it copies *backwards* 
from the series index.  This is useful, but not well known, I think.

Anton is right:

>> copy/part at [1 2 3 4 5] 4 -3
== [1 2 3]
>> copy/part at [1 2 3 4 5] 4 -2147483647
== [1 2 3]
>> copy/part at [1 2 3 4 5] 4 -2147483648
== []

#4216 is still valid with REBOL/View 2.7.5.3.1 3-Jan-2007
always corrupt datatype:  ..  at 201

Does the message helps my XP wants to send to MS?

not sure, but maybe there is a cache listing ....

imo if it is reproducable, then RT can debug it, even without any 
further info ...

sqlab, I don't get any error on 2.7.5.3.1:
>> get-modes s: open tcp://:87 'port-modes
== [read write binary lines no-wait direct]

hi, did anybody notice, that sometimes

    a-value: make port! http://

works, while sometimes is end up as follows:

** User Error: No network server for HTTP is specified
** Near: a-value: make port! http://

it ends up
 - sorry for spelling

the first result can be obtained e.g. by starting a fresh REBOL console 
first and then type in the expression

the second one can be obtained in Windows by defining a Do action 
for .r files as follows:

    C:\Rebol\sdk-2-6-2\tools\rebview.exe "%1"


and then right-clicking on a file containing just a REBOL header 
and the above mentioned expression and picking the Do command

So does the second way always produce the error ?

I don't seem to have the option to create a Do command in WinXP SP1

ladislav, could it be that the second way skips user.r and thus does 
not set a default network server?

ie. can you verify a set-net is being executed before that?

checking

indeed, Gabriele, if I make sure set-net is executed, the problem 
does not occur

Anton - I am using WinXP SP2, but I am positive that it is possible 
in SP1 too

you can define the action in Windows explorer, check registered file 
types

ok, so it's not really a bug; it's just that when you have a default 
network server, rebol uses that for any protocol. (set net does not 
actually set the smtp server; it sets the default server. since the 
send function does not specify any server, the default server is 
used to send email; that's why the default server is normally set 
to the smtp server)

thanks

what do you think about this:

    0:0:0.1 = 0:0.1 ; == true

doesn't it look strange?

Very, considering 0:0 defaults to hours:minutes -
>> 0:0
== 0:00
>> 0:0.1
== 0:00:00.1

hmm... you can have decimal only for seconds... so i guess rebol 
tries to make sense of 0:0.1 by assuming you meant 0:0:0.1

Maybe it should convert 0:0.1 into 0:0:6 ?  IIRC, Ti calculators 
do that when working with degrees/minutes/seconds...

0:0 is ambiguous. rebol normally takes that as hours:minutes because 
it's the most common case ("it's 10:07 am now"). but when you write 
1:0.7, rebol can see that you probably meant minutes:seconds, so 
it interprets it that way.

if the format was something like 10h12m3s, then you could write 0h0.1m 
and it could be taken as 0:0:6.

anyway, i guess Carl will change it to whatever is the most useful 
for people, so if most people think that 0:0.1 should mean 0:0:6 
he will probably change it.

I'm not sure I'd change the time... the above, as explained by Gabriele 
is what is happening, and its very logical... the dot is consistent. 
and fixes the inconsistency of  0:10:0 and  0:10 being the same thing.

this is a copy of a fresh REBOL interpreter console. Do you think 
it is covered by the documentation, or should I put it to RAMBO?

>> a: make string! 15
== ""
>> insert a "a"
== ""
>> a
== "a"
>> str: make struct! [s [string!]] reduce [a]
>> str/s
== "a"
>> insert/dup tail a "b" 14
== ""
>> a
== "abbbbbbbbbbbbbb"
>> str/s
== "a"
>> recycle
>> str/s
== "¸^D^G^A"

if we wanted to support decimal minutes and hours, I'd suggest that 
time then support using decimal values in all parts of a time like 
so:

0:.1:00
0.2:00
0:0.25:0.124


then we'd be forced to write 0:0:0.124 and the inconsistency would 
disapear.  a part from the above discrepancy in that you don't have 
to supply seconds