World: r3wp

Not an error, sorry.

yesp, it's not a bug as Brian says.

Just an unusual handling because of the way I copy/pasted it..

If you are using /View, try reading from clipboard:// rather than 
pasting - no escaping will happen then.

^M and ^J (in causing the load error) are exceptional in the alphabet 
of A  - Z.  For example:
	>> load {#"^A"}
	== #"^A"

None of the rest require double-escaping. I am trying to think of 
the reason why rebol treats the newline characters differently.

anton: that's not a suprise

>> {#"^A"}
== {#"^A"}
>> {#"^/"}
== {#"
}

see the difference?

the closing " is on a different line. that causes an error.

see also:

>> load {#"^""}
** Syntax Error: Invalid string -- "
** Near: (line 1) #"""

anothe way to look at it is to look at the binary representation:

>> as-binary {#"^A"}
== #{23220122}
>> as-binary {#"^/"}
== #{23220A22}

{#"^/"} - then char-molding is buggy?

is it?

>> mold newline
== {#"^^/"}

i really don't think so :)

Peter: about your ticket -211 about GET... GET has nothing to do 
with that :)

>> print :source
?function?

that's the difference between FORM and MOLD:

>> form :source
== "?function?"
>> mold :source
== {func [
    "Prints the source code for a word."
    'word [word!]
][
    prin join word ": "
    if not value? word [print "u...

oh, misreaded your {#"^/"}. thare are string-parens around.. you 
are right :)

what do you think about http://www.rebol.net/cgi-bin/rambo.r?id=3363&

a number of bugs have been fixed. please check out the "Waiting for 
testing" tickets to see if you favorite bug has been fixed, so that 
you can test it and we can switch to tested. :)

3130 Bug: On Linux, CALL interferes with TCP port wakeup, 3159 Bug: 
Linux: system port interferes with TCP ports

using it for some hours to do remote calls thru tcp, works. did not 
work with older rebol. IMO fixed.

3326 Bug: CALL should accept file! datatype
does it now (linux)

3576 Bug: browse doesnt open web browser (Linux)
and 3455 are the same.

Is there a way to see only the rambo entries one has made ?  I am 
"guest" and hope no body else was guest !

graham: i don't think you can search by submitter currently.

Pity .. I was wondering what the status of my submissions was.

Bug #3099: looks much better although I noticed this:
>> to-integer -2147483648.0
** Math Error: Math or number overflow
** Where: to-integer
** Near: to integer! :value

Bug #3403 Looks good to me on View 1.2.103

Bug #3436 looks good and solid by View 1.2.102

don't know if it's really a bug ...

>> greater-or-equal? 1.2.48.3.1 system/version
== false
>> system/version
== 1.2.102.3.1
>>

if it's a bug it could be cool to patch it too ...

>> help greater-or-equal?
USAGE:
    GREATER-OR-EQUAL? value1 value2

DESCRIPTION:

     Returns TRUE if the first value is greater than or equal to the second 
     value.
     GREATER-OR-EQUAL? is an action value.

ARGUMENTS:
     value1 -- (Type: any)
     value2 -- (Type: any)

So you have to invert arguments :
greater-or-equal? system/version 1.2.48.3.1

RE #3099:

>> to integer! #{80000000}
== -2147483648
>> - to integer! #{80000000}
== -2147483648

about: http://www.rebol.net/cgi-bin/rambo.r?id=3363&do you think 
FIND should stay as it is for compatibility? or it's better to change 
it?

Carl: "On negate bug: looks like a C compiler problem. I may be able 
to fix that with an explicit check for that value, but it will slow 
down the function by a lot. Is that worth it?"

what is that negate-bug? Ladislavs example? thats an overflow. 0 
is "positive", so there is one negative number more. and negative 
numbers count downward, all bits on is highest possible. the conversion 
is: invert all bits, add 1. gives #{7FF..}, + 1 #{800..}

find - hmm. till 'as-string it was handy with big data. now we can 
rewrite it, but detecting that use is tricky. but its surely a surprise. 
maybe we can forbid find without /case for a while with binary? gibing 
some usefull warning.

i have a wish: integrating 'comment in some more dialects. parse, 
layout come to mind. could then be used for embedded documentation. 
what do you think?

I second the request for comment!

Pun aside, of course.

a lot of bugs fixed: http://www.rebol.net/cgi-bin/rambo.r?sort=1&limit=2&cmd=Search&id=&pattern=&subject-only=true

3662 parse/lines second arg: how to split into lines and apply the 
rule to each line?

 a grep:   parse/lines string-with-list-of-file-names [ set file thru 
 ".r" end ( ?? file ) ]

btw, can we discuss auto-dequoting again? maybe together with /all? 
i don't like such surprises:
!>> parse {
a
b
} "^/" 
== "a" "b"

correction, result is == ["a" "b"]
my "do from editor molded /only..