World: r3wp

make integer!: asked carl directly.

Gabriele, about detect:  Yes, perhaps the console input is similar 
enough to a network access (a port access ?).   And, amazingly, doing 
from a string after "contamination" does *not* show the problem.

And yet more amazingly, doing from a string in a fresh rebol console 
*does* show the problem at the first VIEW.

Romano, that's not really a workaround if the requirement is to keep 
the window open. :)

Romano, "make integer!", I think if it can't fit all the integer 
digits from the input string into a valid integer, then it should 
throw an invalid argument error. Any digits after a decimal point 
should be discarded.  That would mean MAKE at least understands arbitrary 
length numbers in a string, even if it can't fit them into a rebol 
datatype.

(or throw a math overflow error).

and so "make integer!" should never return a decimal!, in my opinion.

hi all, I found a nasty surprise in alpha async, at least for me 
it is a nasty surprise:


 http://www.rebol.net/cgi-bin/rambo.r?sort=4&limit=1&cmd=Search&id=&pattern=Read+handler


The behaviour I observed is observable in OpenBSD 3.6 too, Gabriele, 
could you add this note to it?

Tom: I don't think .a libraries can be loaded dynamically, but i 
might be wrong.

Thats correct .a libraries are used for static compilation.

Gabriele: this is the response I get:

Chunk no 1
before insert
read handler execution interrupted! response
Chunk no 2
before insert
after insert
after insert

this makes me think it's recursion, rather than interruption. a bit 
strange maybe, though.

aha, so it looks that the handler eventually "returns", fine

then it is a bit better

Gabriele: Carl thought it was a possibility,  and asked me to add 
the request ro rambo so it did not get lost.

ok. maybe it is possible on some OSes.

Re the Read handler issue: I found a way how to make it work in a 
"standard" way - how should I post it there?

is it too big to be posted directly? maybe you could just post a 
link to the code...

it isn't big, but i can't change my post, can I?

your post in RAMBO? you can't. I'll have to change it for you, or 
we can dismiss the old ticket and create a new one.

Regarding async speed: I posted a note in the async group to look 
at that closer.

Just noticed: HIDE stopped minimizing a window face some time after 
1.2.5.3.1, eg:
	view lay: layout [button [hide lay]]
Is that a bug, or intended? (I'll check this out more later.)

i got lately this
dir: %somewhere/
probe  dir/042
== %somewhere/42 ; the 0 is killed
on 1.2.48.4.2

This is the same problem as I reported earlier, with
	dir: %somewhere/
	dir/1.s3m
** Syntax Error: Invalid decimal -- 1.s3m
** Near: (line 1) dir/1.s3m

This happens because the path elements are each evaluated by rebol 
first.

*smackme* right, its turned in a rebol-value..

See http://www.rebol.net/cgi-bin/rambo.r?id=3642&

yup. good trick with the %

Mmm.. yes it works but I don't really like it. The problem is the 
usual way almost always works without errors.

almost always
 - when it is a valid word. :)

On HIDE: sounds like could be a bug. So add to RAMBO if not already 
there. Thanks.

Yep, path requires valid REBOL.  So, use dir/"042" if you need to 
do that.

(Or, % ok too.)

Why couldn't paths do that for us ? ie. to-path "042" becomes a word...

HIDE minimizes window faces up to View 1.2.8.     Does nothing (that 
I can see) in View 1.2.10 and all subsequent versions.

OK, submitted the HIDE bug to rambo.

Anton: that would be quite bad, how could you then use numbers in 
paths? like block/3 to get the third element.

Gabriele, I mean, that a path component should be converted to a 
"string" word only when it can't be parsed into a normal rebol value.

but 042 can be parsed..

ah!  I have to add a bit extra:  ".... which molds back to the original 
path component string."

anton: that doesn't seem to make much sense, does it? :)

I found that there is probably bug in the native DISARM function 
- I'm explaining it in Rambo

Oldes, interesting one.

Gabriele, here is some code which summarizes my idea very well:

load-path: func [str [string!] /local result val][
	result: copy []
	foreach component parse str "/" [
		either any [
			error? try [val: load component] ; loaded doesn't parse it
			component <> mold val ; or it looks a bit different
		][
			append result to-word component ; make a "string" word
		][
			append result val
		]
	]
	to-path result
]

load-path {my/path}
load-path {my/path/042}
load-path {my/path/1.s3m}

Oldes, maybe port handlers are not expecting PRINT to be used when 
they use ATTEMPT ?

I am wrong, it doesn't look like they use ATTEMPT.

Anton: I still don't see why that should be done for paths, and not 
for blocks.

oldes: i don't think it's disarm, it's more likely that you hit a 
GC problem. btw, most of the code in the errors seems to come from 
some handler.

anyway, it's not something easy to reproduce, so it won't be easy 
to fix. also, is that on the betas or on the alphas? if you don't 
get the same results on the alphas the bug might be already fixed.