World: r3wp

Anton, i have the same rate problem in a program of mine! I was not 
able to reduce the problem to a simple example.

There is a workaround: call unview, then rate restarts to stop :-)

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.