World: r3wp

picki/pokei: dunno. seems related to int/binary conversion to me 
though. i have reposted requests anyway.

Well yes, they could be used for that, but there are other cases 
where integers are used to store packed byte values in binary data, 
and these operations can be translated to single machine instructions 
instead of the 3+ required by their arithmetic equivalents. Carl 
will of course use his own judgement.

is this a known bug??: 

>> a-list: make list! 30'000
>> repeat n 200 [insert a-list n]
>> a-list: head a-list   ;;;  without this line no error is threw
>> clear a-list
>> repeat n 200 [insert a-list n]
** Script Error: Out of range or past end
** Near: insert a-list n

The error isn't threw with hash! nor block! datatypes

ok, I saw Jaime has reported the bug....

so... it seems some spammer has found his way into the bug database 
:-(

yep. but luckily we need to approve each post. :)

Bug 3486 has status PENDING but seems to be already fixed. Maybe 
other bugs are fixed too, but RAMBO says otherwise. Adding comments 
to RAMBO should be really great.

Yep, looks like that one was fixed, i don't know exactly in what 
version though.

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 ?

Try this:

view/new layout [button 233x233]

load read-net http://www.userfriendly.org/cartoons/archives/97nov/uf13b471.gif

Now try this...:

view/new layout [button 233x232]

load read-net http://www.userfriendly.org/cartoons/archives/97nov/uf13b471.gif

oh well.... that button size may vary in needed size, because it 
did crash in both cases now in the console

Doesn't crash here. Using REBOL/View 1.3.51.3.1 28-Oct-2005 Core 
2.7.0

crashes 100% reliably with 1.3.1 under windows

try making a very big button

doesn't crash under 1.3.61 though

nope... must've been fixed somehow

Crashes in both cases with view 1.3.61.
But my problem is not connected to View. I want a stable core.

Can't dupe the crash here under 1.3.61. Can you provide more system 
details?

did not crash but did lock up had 2 ctrl-alt-del to end,using View/pro 
1.3.1.3.1

It crashes with Windows XP or Win2000 server
e.g 

Microsoft Windows XP Professional
Version	5.1.2600 Service Pack 2 Build 2600

Prozessors	x86 Family 15 Model 2 Stepping 9 GenuineIntel ~2807 Mhz
Memory from 512 to 1024 MB

Windows 2000 Server
Version 5.0.2196 Service Pack 4 Build 2195

2 Processors X86 Family 15 Model 2 Stepping 7 Genuine Intel ~2399MHz

a.s.o.

the most simple client causing the receiving sever to crash

forever [
	con: open/binary/direct/no-wait tcp://receiver:13011
	insert con "a"
	wait con
	if not copy con [break]
	close con
]

what do you think about

>> parse "" [to 5 (print 1)]
1
== true

:-)

can't decode it s meaning:-)

no secret meaning, but i think, this is a bug.

what does to 5 mean in this case when you parse string? To fifth 
char?

Five times the next rule...

>> parse "aaaaa" [5 #"a"]
== true

but there is 'to in there ...

Ah right --[ to 5 ]-- doesn't work, any more than --[ to some ]-- 
or --[ to any ]-- would.

And integers are specificly used as part of the parse rule:
>> parse [5][5]
== false

is the last case correct returning false?

parse "12345" [copy a to 2 copy b to 3 copy c to 4 copy d to 5 copy 
e to 6]
== true
>> a
== "1"
>> b
== "2"
>> c
== "3"
>> d
== "4"
>> e
== "5"

>> parse "abcde" [to 4 #"e"]
== false
>> parse "abcde" [to 5 #"e"]
== true

Interesting...

copy e to 6? Should be false imo!

that is imo bug :-)

hmm, so it means to fifth char?

Unless it is to an index position...

from sqlabs example it seems to be index position, otherwise if it 
counted num of chars, it would not start from the beginning of the 
string each time ...

so 6 in his example is equal tail ... index? tail "abcde" = 6

>> parse "abcde" [to 6 mk: (probe index? mk) to 1 mk: (probe head? 
mk) to 6]
6
true
== true

This may be painfully obvious, I'd never noticed it before...

I would say that sqlab's example was a bug, except that it is consistent 
with:
>> skip "" 5
== ""

>> head? skip "" 5
== true

>> parse "54321" [to 2 mk: (print mk)]
4321
== false
>> parse "54321" [to "2" mk: (print mk)]
21
== false

I didn't know that either. Good to learn something new. :-)

>> parse "54321" [to 5 mk: (print mk)]
1
== false
>> parse "54321" [to 4 mk: (print mk)]
21
== false
>> parse "54321" [to 3 mk: (print mk)]
321
== false
>> parse "54321" [to 2 mk: (print mk)]
4321
== false
>> parse "54321" [to 1 mk: (print mk)]
54321
== false

that would be the position in the string, not the actual digit in 
the string...

Exactly!

Also works with thru:
>> parse "abcde" [to 2 mk: (print mk)]
bcde
== false
>> parse "abcde" [thru 2 mk: (print mk)]
cde
== false