World: r3wp

(DO first tries to LOAD the decompressed string.)

The decompressed string was identical to the original string. The 
compression/decompression has nothing to do with it. The problem 
is in loading a string of code copied straight from an editor or 
somewhere. If that code had been MOLDed first it would have been 
OK.
>> mold #"^M"

== {#"^^M"}        ;<--------- note the double escape, this string 
loads properly.

I think rebol doesn't load #"^M" and #"^J" because they are CR (ascii 
13) and LF (ascii 10).  In rebol, these are molded to #"^M" and #"^/".....

.... mmm that may explain LF because it has an alternate representation 
#"^/", which is by default molded by rebol, but that doesn't explain 
#"^M"...  Anyway, it seems to be a bug. I vaguely remember it was 
found before.

^M and ^J are newline characters. The syntax of REBOL doesn't allow 
direct newline characters in strings surrounded by " characters. 
In the example you use, the string is read twice - first in the console, 
and then next in the load. Each time the string is read it is unescaped 
(the effects of the ^ char is applied). Since you are unescaping 
twice, you need two ^ characters, the first to escape the second.

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!