AltME groups: search

I haven't finished it mainly because I'm not a LDAP user, so I'm 
not familiar with most of the LDAP concepts. The protocol itself 
is quite complex due to ASN.1 encoding.

Ashley that overcomes the 'newline" issue with pasting OS X text 
(\n newlines) into AltME which uses MacRoman (\r newlines) but I 
don't think that it overcomes the charcter encoding issues.

Sunanda, note that this is already available in the text encoding 
module: http://www.rebol.it/power-mezz/mezz/text-encoding.html

It applies to for instance not Huffman encoding the names for the 
sheer sake of saving characters.  The abbreviation has to line up 
with the Rebol word in some vaguely reasonable way.

a noter (ds les headers poste ds group Cheyenne) le premier redirect 
envoie:
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
le deuxieme:
Expires: Wed, 19 Aug 2009 21:43:59 GMT
Cache-Control: private, max-age=0
a noter aussi, le premier envoie aussi:
Content-Type: text/html; charset=UTF-8
mais pas de Content-Length
le deuxieme envoie:
Content-Encoding: gzip
Content-Length: 232
et pas de Content-Type

.. un vrai mess.. normalment j'ai confiance en google, ils sont tres 
peeki mais la je comprends pas

While testing now, I've noticed a few issue with send-email/attach: 
header and multipart/form-data encoding. I'll fix them tonight, need 
to go now.

I assumed it only put file data there and still captured the non 
file data into request/content

 => it requires to send data using "multipart/form-data" encoding.

Important notice wrt web sockets : IIRC, all data sent on both sides 
have to be UTF-8 encoded. The current Cheyenne implementation doesn't 
enforce that encoding, so it's up to the developer to send the right 
data format.

This is apply to the so-called "text frames" which Cheyenne supports. 
The other kind of frames (binary frames) doesn't require such encoding 
(not supported by Cheyenne yet).

Not using the default config .. but I get this

26/12-10:17:23.838-[RSP] ##RSP Script Error: 

	URL  = /ws.rsp
	File = www/ws.rsp

	** Script Error : Invalid path value: data 
	** Where: rsp-script 
	** Near:  [prin request/content/data] 


Request  = make object! [

    headers: [Host "localhost:8000" Connection "keep-alive" User-Agent 
    {Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 
    (KHTML, like Gecko) Chrome/4.0.249.43 Safari/532.5} Accept {application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5} 
    Accept-Encoding "gzip,deflate" Accept-Language "en-GB,en-US;q=0.8,en;q=0.6" 
    Accept-Charset "ISO-8859-1,utf-8;q=0.7,*;q=0.3"]
    status-line: #{474554202F77732E72737020485454502F312E310D0A}
    method: 'GET
    url: "/ws.rsp"
    content: none
    path: "/"
    target: "ws.rsp"
    arg: none
    ext: '.rsp
    version: none
    file: %www/ws.rsp
    script-name: none
    ws?: none
]

Binary support / upload: these are 2 different things. Uploading 
files (access to local filesystem) still requires FORM with multipart/form-data 
encoding.

Because those characters are url syntax, and encoding them would 
break the syntax.

This is what I am sending

HTTP/1.1 200 OK
Server: Cheyenne/0.9.20
Date: Thu, 02 Dec 2010 15:33:25 GMT
Content-Length: 475
Content-Type: application/vnd.adobe.xfdf
Connection: Keep-Alive
Content-Encoding: deflate
Set-Cookie: RSPSID=XESYTVZSEFSXPQHCTITGRDQG; path=/md; HttpOnly
Cache-Control: private, max-age=0
Expires: -1


Firefox opens up the PDF referenced in the xfdf file that is downloaded.

Chrome just downloads and saves the content.  So maybe it's just 
Chrome's PDF "plugin" that doesn't understand what to do ...

You can pre-compress it in gzip format, but Cheyenne will need to 
be patched to send the appropriate Content-Encoding header (should 
be part of a dedicated Cheyenne mod, that could also handle the pre-compression 
on disk).

Just something to keep in mind when working on websockets: the transer 
mode used by Cheyenne to reply to clients is "text" mode. This mode 
requires UTF-8 encoding and IIRC, the browser is allowed to reject 
your response and close the connection if the response is wrongly 
encoded.

Chat demo: in fact, it should work ok in all cases, because the UTF-8 
encoding is done by the browser and the chat back-end just broadcast 
it as is to others.

adding a content-type header or content-disposition doesn't change 
anything. encoding base 64 either not.

The problem is that while the scheme might not represent anything 
network-related, the standard for URI syntax is independent of network 
issues. And that standard is pretty strict about hex encoding, regardless 
of the scheme's internal rules. So schemes need to be hex-encoding-aware 
for their specs, whether they are network-related or not.

The standard is very explicit on how encoding should work. Reserver 
characters must never be decoded BEFORE you split the URL into its 
parts (which can only be done if you understand the scheme). Any 
other character may be decoded just like REBOL does.


So, it's not that URL! should never decode, it's that it should never 
decode the reserved characters. Then, the handler for each protocol 
needs to decode the parts separately after splitting. Since the protocols 
we use in REBOL all have the same format basically, you can use a 
single function to handle all of them, eg. like my parse-url.

digital signals work differently.. i'm not sure if they still use 
YCrBr  (luminace, red diff, blue diff) concepts in their encoding.

But <pre> rendering doesn't look that good due to <br> tags insertion. 
I need to make the view encoding rules smarter.

note here that we DON'T wait for the second dispatch to finish, we 
just make sure its got all the frames before  dispatching it.


then you could have a burst config which allocates different number 
of threads based on dispatch labels... maybe there's 4 rendering 
threads and only one encoding thread.

but you could dispatch that  function  too...

render-scene: func [shots][
	foreach shot shots [
		dispatch render-sequence shot/data shot/length
	]
]


so here you just send the whole scene to render, and it would only 
use the allocated number of 'pic-render threads allowed accross all 
shots.  :-)

I have no idea on how date values are stored in C, all that the docs 
say is that date values are 32 bit encoded date and time zone values, 
so I mainly tried with value.int32a but tried other members too. 
I have no idea about how the encoding is done and - as Anton said 
- I really don't want to reverse engineer it.

1.1 didn't work since chunked encoding was broken, so they reverted 
to 1.0. Proper 1.1 support is on the list to fix.

However, chunked encoding needs to be fixed first, before 1.1 support 
can be reenabled.

Only if you aren't using chunked encoding. If you are, then setting 
Content-Length would be a bug.

Chunked encoding is broken, which is why the released version has 
been modded to use http 1.0; error handling is broken (the source 
of most chat errors); no server support; written for an older idea 
of R3 semantics.

I think I read somewhere Brian saying that http had to be modified 
as chunked encoding didn't work or something like that

Ok, that's possible as well. I just wanted to avoid any encoding 
clashes. Will add it. One second.

If you are worried about encoding issues have the web server serve 
.r3 files in binary mode. DO reads the files in binary.

I meant: There shouldn't be any encoding problems to worry about 
even without that unless ...

I put R3 on my host so I could attempt to run some cgi scripts.  
Anyone know why I would get this error:


 12:55-7:00 Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 
 20 Keep-Alive: timeout=10, max=29 Connection: Keep-Alive Content-Type: 
 application/cgi ‹

What is the best way to handle HTTP encoding in R3?  For example 
if I get an email that has been encoded as paul%40tretbase.com?  
How could I convert that easily to [paul-:-tretbase-:-com]?  Not sure if 
I need to build my own decoder or if we already have that capability.

Quite similar in fact, except for the default encoding.

read/write/as solve just encoding, no? Still not abstracted encoder/decoder 
solution anyway .... old discussion :-)

READ or WRITE /as just solves the encoding problem. Which for the 
clipboard:// scheme means chosing which one of several encodings 
is already strored in the clipboard, at least for most modern OSes.

Claude, where is R3 getting the path %/home/ramcla/Téléchargements/ 
? And are you encoding é in Unicode or Latin1?

Here's a low-level function to parse and process script headers, 
which shows how many features are built into the base script model 
in R3:

load-script: funct [
	"Decode a script into [header-obj script-ref body-ref]"

 source [binary! string!] "Source code (string will be UTF-8 encoded)"
	/header "Return the header object only, no script processing"

 ;/check "Calculate checksum and assign it to the header checksum 
 field"
	/original "Use original source for Content header if possible"
] compose [
	data: either string? source [to-binary source] [
		unless find [0 8] tmp: utf? source [ ; Not UTF-8
			cause-error 'script 'no-decode ajoin ["UTF-" abs tmp]
		]
		source
	]

 ; Checksum all the data, even that before the header or outside the 
 block
	;sum: if check [checksum/secure data]  ; saved for later
	
	if tmp: script? data [data: tmp] ; Find the start of the script
	
	; Check for a REBOL header
	set/any [hdr: rst:] transcode/only data
	unless case [
		:hdr = 'rebol [ ; Possible REBOL header
			set/any [hdr rst] transcode/next/error rst
			block? :hdr ; If true, hdr is header spec
		]
		:hdr = [rebol] [ ; Possible script-in-a-block
			set/any [hdr rst] transcode/next/error rst
			if block? :hdr [ ; Is script-in-a-block
				unless header [ ; Don't decode the rest if /header
					data: first transcode/next data
					rst: skip data 2
				]
				true
			] ; If true, hdr is header spec
		]
	] [ ; No REBOL header, use default
		hdr: [] rst: data
	]
	; hdr is the header spec block, rst the position afterwards

 ;assert/type [hdr block! data [binary! block!] rst [binary! block!]]
	;assert [same? head data head rst]
	
	; Make the header object, or fail if we can't

 unless hdr: attempt [construct/with :hdr system/standard/header] 
 [
		cause-error 'syntax 'no-header data
	]
	; hdr is a correct header object! here, or you don't get here

 ;if check [append hdr 'checksum  hdr/checksum: sum]  ; calculated 
 earlier

 ;assert [sum =? select hdr 'checksum]  ; Should hdr/checksum be reserved?
	

 if header [return hdr] ; If /header, no further processing necessary

 ; Note: Some fields may not be final because post-processing is not 
 done.
	
	; Skip any whitespace after the header

 ws: (charset [1 - 32]) ; For whitespace skipping (DEL not included)
	if binary? rst [parse rst [any ws rst:]] ; Skip any whitespace
	
	; Check for compressed data and decompress if necessary
	case [
		; Magic autodetection of compressed binary
		tmp: attempt [decompress rst] [
			data: rst: tmp  ; Use decompressed data (no header source)
			append hdr 'compressed  hdr/compressed: true ; Just in case
		]
		; Else not directly compressed (without encoding)
		(select hdr 'compressed) != true [] ; Not declared, do nothing
		; Else it's declared to be compressed, thus should be
		binary? rst [ ; Regular script, check for encoded binary
			set/any [tmp rst] transcode/next/error rst
			either tmp: attempt [decompress :tmp] [
				data: rst: tmp  ; Use the decoded binary (no header source)
				hdr/compressed: 'script  ; So it saves the same way
				; Anything after the first binary! is ignored
			] [cause-error 'script 'bad-press -3] ; Else failure
		]
		; Else it's a block, check for script-encoded compressed binary
		tmp: attempt [decompress first rst] [

   data: rst: tmp  hdr/compressed: 'script  ; It's binary again now
		]
		; Else declared compressed but not compressed, so fail
		'else [cause-error 'script 'bad-press -3]
	]
	
	; Save the script content in the header if specified
	if :hdr/content = true [
		hdr/content: either original [source] [copy source]
	]
	

 ;assert/type [hdr object! data [binary! block!] rst [binary! block!]]
	;assert [same? head data head rst]

 reduce [hdr data rst]  ; Header object, start of source, start of 
 body
]


Note all the commented assert statements: they are for testing (when 
uncommented) and documentation. Also, I later removed the checksum 
calculation from this code because it was the wrong place to put 
it, at least as far as modules are concerned. However, Carl didn't 
know this because he was working on it while I was offline for a 
few days.

One thing will definitely be easier though: JSON and Javascript define 
that they have Unicode source, but don't have a way to specify the 
encoding (they are text standards, not binary). They can be handled 
easily in R3 once the source is converted to a string though, since 
that conversion will handle the encoding issues. In R2 you'd have 
to either stick to ASCII data or use Gabriele's text codecs and then 
parse the UTF-8.

That sounds both very worrying and a challenge - how big were the 
XML files? Were they utf-8 encoded? Did you verify the utf-8 encoding 
in the XML or could it have contained invalid utf-8 sequences?

Actually, I use bitiwse  XOR and OR to perform arithmetic on characters 
in my string encoding utilities script.

The only function in R3 that operates that way is TRANSCODE, so as 
long as it doesn't choke on overlong combinations

#{c0ae} is an overlong encoding for #"." (#{2e}).

>> invalid-utf? #{c0ae}
== #{C0AE}

>> transcode #{c0ae}
== [® #{}]

>> transcode #{2e}
== [. #{}]

Now this looks completely weird:
>> #"a" + #"b"
== #"A"


Having ordinal values that you wouldn't think of being numbers act 
like numbers seems really weird to me. I can accept that #"a" > #"A", 
but treating them like numbers without explicit conversion seems 
strange to me. I get similarly creeped out by multiplying one money! 
by another; I have to remember that despite the "$", and "money!" 
name, they aren't really money (a measure of quantity), they are 
just another numeric encoding that enables more precise decimal math 
than decimal! (another name that seems off to me, since its values 
are floating-point binary, not decimal).

Sorry, about these delays. I was on on an online session.
So When I  use parse-xml+  on my xml string, I get the following:
[document [version none
        encoding none
        standalone none
        doctype none
        pubid none
        sysid none
        subset none

    ] [["TTL_Status" none ["^/^-" ["INPUT_TTLS" none ["^/^-^-" ["TTL_IN" 
    ["value" "0"] [{

^-^-^-} ["status" ["value" "1"] none] "^/^-^-"]] "^/^-^-" ["TTL_IN" 
["value" "1"] [{

^-^-^-} ["status" ["value" "1"] none] "^/^-^-"]] "^/^-"]] "^/^-" 
["OUTPUT_TTLS" none ["^/^-^-" ["TTL_OUT" ["value" "0"] [{

^-^-^-} ["status" ["value" "0"] none] "^/^-^-"]] "^/^-"]] "^/"]]]]

I know it's not that readable...

Then I run xml-to-object on that block and get:

o: xml-to-object  blk
where block is the output of parse-xml+ above.

probe o


[document: make object! [TTL_Status: make object! [INPUT_TTLS: make 
object! [TTL_IN: make block! reduce [

                    make object! [status: make object! [value?: "" value: "1"] value: 
                    "0"] make object! [status: make object! [value?: "" value
: "1"] value: "1"]

                ]] OUTPUT_TTLS: make object! [TTL_OUT: make object! [status: make 
                object! [value?: "" value: "0"] value: "0"]]] version: none
        encoding: none
        standalone: none
        doctype: none
        pubid: none
        sysid: none
        subset: none
    ]]


So this is where my ignorance leaves me. How do I make "o" into a 
an object where all the nested objects become real objects and don't 
remain as blocks?

I think this is a Graham question. I've been trying to communicate 
with this video encoder. It uses .xml and .cgi files to talk to it:
tmp: http-tools http://192.168.1.62/user/GetTTLStatus.xml[]
and this works fine.


The problem is with he .cgi files. They aren't POST files but they 
only return 

 a: http-tools http://192.168.1.62/user/StorageMediaFiles.cgi[] probe 
 a
make object! [
    HTTP-Response: "<?xml version='1.0' encoding='ISO-8859-1' ?>"
    Date: none
    Server: none
    Last-Modified: none
    Accept-Ranges: none
    Content-Encoding: none
    Content-Type: none
    Content-Length: none
    Location: none
    Expires: none
    Referer: none
    Connection: none
    Set-Cookie: none
]
When you place the url in a browser it works as expected. 
Any ideas on how to get this to work?

And you're right, there is probably something else going on. I am 
at least getting part of the message. A successful .xml call looks 
like this:

a: http-tools http://192.168.1.62/user/StorageEventMode.xml[] probe 
a
make object! [
    HTTP-Response: "HTTP/1.1 200 OK"
    Date: none
    Server: "Mango DSP - HTTP Server (v2.34)"
    Last-Modified: none
    Accept-Ranges: none
    Content-Encoding: none
    Content-Type: "text/xml"
    Content-Length: "270"
    Location: none
    Expires: none
    Referer: none
    Connection: none
    Set-Cookie: none
    Cache-Control: "no-store"
    content: {<?xml version="1.0" encoding="ISO-8859-1" ?>
<?xml-stylesheet type="text/xsl" href="StorageEventMode.xsl"?>
<StorageEventMode>
^-<RecOnNetworkFailure id="RecOnNetworkFailure" checked="true"/>
^-<PreEventBufferTime id="PreEventBufferTime" value="20"/>
</StorageEventMode>
}
]

So what's happening is that the server is not returning an LF/CR 
to separate the contents from response fields so when it gets to 
 parse-header, that function does not know there is any contents. 
In stead of getthing something like:

HTTP-Response: HTTP/1.1 200 OK
Server: Mango DSP - HTTP Server (v2.34)
Content-Type: 
text/xml
Content-Length: 270
Cache-Control: no-store

<?xml version=
1.0" encoding="ISO-8859-1" ?>"

I am getting:

HTTP-Response: <?xml version='1.0' encoding='ISO-8859-1' ?>
<?xml-stylesheet type='text/xsl' href='StorageMediaFiles.xsl'?>
<StorageMediaFiles>
<MediaFile ..."


Placing a LF between the first and second lines fixes it. I am going 
to kludge it for now since I know what routines work and don't.

OK, this is freaky:

>> system/version
== 2.7.8.2.5
>> a: list-env
== [
    "TERM_PROGRAM" "Apple_Terminal" 
    "TERM" "xterm-color" 
    "SHELL" "/bin/bash" 
    "TMPDIR" "/var/folders/6O/6OnXy9XG...
>> help a
A is a block of value: [
    "TERM_PROGRAM" "Apple_Terminal" 
    "TERM" "xterm-color" 
    "SHELL" "/bin/bash" 

    "TMPDIR" "/var/folders/6O/6OnXy9XGEjiDp3wDqfCJo++++TI/-Tmp-/" 
    "Apple_PubSub_Socket_Render" "/tmp/launch-BrITkG/Render" 
    "TERM_PROGRAM_VERSION" "273.1" 
    "USER" "Ash" 
    "COMMAND_MODE" "legacy" 
    "SSH_AUTH_SOCK" "/tmp/launch-HlnoPI/Listeners" 
    "__CF_USER_TEXT_ENCODING" "0x1F5:0:0" 

    "PATH" {/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin} 
    "PWD" "/Users/Ash" 
    "LANG" "en_AU.UTF-8" 
    "SHLVL" "1" 
    "HOME" "/Users/Ash" 
    "LOGNAME" "Ash" 
    "DISPLAY" "/tmp/launch-U0Gaqw/org.x:0" 
    "_" "/Users/Ash/REBOL/rebol"
]
>> length? a    
== 18
>> select a "USER"
== "Ash"
>> select a "HOME"
== none

I can imagine length? on char! value in unicode context - it could 
return number of bytes needed to store the char with the utf-8 encoding:) 
But I'm sure I can live without it. It would just add overheat to 
the length! action.

I need to extract the data from an image file so it does not include 
the "64#" header and I just have the 64 bit encoding: 

64#{
/9j/4faARXhpZgAATU0AKgAAAAgABwEPAAIAAAAESFRDAAEQAAIAAAAIAAAAYgEa
AAUAAAABAAAAagEbAAUAAAABAAAAcgEoAAMAAAABAAIAAAITAAMAAAABAAEAAIdp
is3eIoxUdG7n/9k=
}


I just wnat the stuff between the quotes but as its a binary I can't 
seem to parse it or extract it with other methods like a text file.

Anyone knows of a simple way to get to the binary encoding of a decimal! 
using just REBOL/Core (i.e. no struct!, no /library)?

Shad, typed variables with type inference handles the readability/maintenance 
problem pretty well, which is why several statically typed languages 
have been retrofiting type inference into them recently. Fortunately, 
Red is planned around that from the start.


Your "predictable type variable" proposal (I don't know the standard 
term either) sounds useful. Many languages do this through reflection 
facilities, but that kind of thing requires dynamically typed variables 
at least as an option if you are going to use the reflection facilities 
of the language you are interfacing with - this is necessary for 
C++ at least because there isn't a shared standard for encoding that 
information in a static way. It would be more useful for integrating 
with .NET or CORBA objects, since direct field access is prohibited 
anyways for those so there's no extra overhead in the field access 
itself, just in the runtime discovery, and ahead-of-time static compilation 
has shared rules that work on a binary standard.

Anyone knows where to find exhaustive lists of invalid UTF-8 encoding 
ranges?

I am also unsure of the valid range of the 2nd byte in the four-bytes 
encoding.

The policy on overlong combinations was set by R3, where there isn't 
as much need to flag them. Overlong combinations are a problem in 
UTF-8 for code that works on the binary encoding directly, instead 
of translating to Unicode first. The only function in R3 that operates 
that way is TRANSCODE, so as long as it doesn't choke on overlong 
combinations there is no problem with them being allowed. It might 
be good to add a /strict option to INVALID-UTF? though to make it 
check for them.

As long as they are interpreted exactly the same as the short encoding 
of the value, no problems.

Interesting, but I guess that a specific data encoding would be more 
appropriate than plain REBOL or C? Something like the Golf dialect 
(wrote by hostilefork?).

REBOL code is interpreted, but not its source. The slow part of a 
source interpreter is parsing the source into the intermediate code, 
the AST. REBOL is an AST evaluator. The advantage to that relative 
to a bytecode VM is that you can extend the runtime with more fast 
operations without breaking the bytecode encoding, but the disadvantage 
is that the interpreter overhead is larger so if you want your operations 
to be efficient you have to use larger ones. This is why C-like code 
is slow in REBOL, but high-level code can be fast.


If you want to get the advantages of a bytecode VM with the extensibility 
advantages of REBOL's model you could go with an address-threaded 
interpreter. Address-threaded interpreters have more data going through 
the processor than bytecode interpreters do, but it you need to support 
higher-level operations they are more efficient overall. However, 
if you don't need to support higher-level operations and only need 
to support a tiny number of low-level operations then bytecode can 
be encoded in a much smaller amount of space. If your language is, 
for instance, a spreadsheet formula evaluator then you might even 
be able to have 4-bit bytecodes, with two operations per byte, and 
have an interpreter that fits entirely in the instruction cache of 
a processor. Bytecodes can be much faster then.


Still, Lua's bytecode VM, as efficient as it is, has been running 
into performance limits as well. Fortunately, a bytecode model that 
maps well enough to the native code model (remember what I said earlier 
about C-like bytecode VMs?) can have the bytecodes translated to 
native code at runtime and then execute the native code. For C-like 
code that is usually even faster than address-threading. This is 
why LuaJIT has been doing so well when compared to Lua's bytecode 
VM.


World being Lua-like means that it can improve using methods similar 
to the ones that Lua has been using to improve. That's definitely 
a good thing, since it means that Geomol doesn't have to work from 
scratch :)

That's cool, Brian! :)

A note about KWATZ!, you suggest it to be text!, but it's not quite. 
It sure can be e.g. UTF-8 data:


(Setting my Terminal program to character encoding Unicode (UTF-8) 
and trying to load 3 ASCII letters, 3 danish letters and 3 greek 
letters)

w> load "abc ?????? ??????"
== [abc #{C3A6C3B8C3A5} #{CEB1CEB2CEB3}]


(Notice World isn't prepared to unicode yet, but can load it, as 
it can just be seen as bytes.)


But beside text, KWATZ! can also handle all other data, like escape 
codes or any binary format maybe combined with more understandable 
data, you wanna load.

The escape decoding gets done too early. The decoding should not 
be done after until the URI structure has been parsed. If you do 
the escape decoding too early, characters that are escaped so that 
they won't be treated as syntax characters (like /) are treated as 
syntax characters erroneously. This is a bad problem for schemes 
like HTTP or FTP that can use usernames and passwords, because the 
passwords in particular either get corrupted or have inappropriately 
restricted character sets. IDN encoding should be put off until the 
last minute too, once we add support for Unicode to the url handlers 
of HTTP, plus any others that should support that standard.

Worse than being a huge mess, R2 and R3 have different messes. R2 
MOLD fails to encode the % character properly. R3 chokes on the ^ 
character in unquoted mode, and allows both ^ and % escaping in quoted 
mode, and MOLDs the ^ character without encoding it (a problem because 
it chokes on that character). Overall the R2 MOLD problem is worse 
than all of the R3 problems put together because % is a more common 
character in filenames than ^, but both need fixing. I wish it just 
did one escaping method for files, % escaping, or did only % escaping 
for unquoted files and only ^ escaping for quoted files. % escaping 
doesn't support Unicode characters over 255, but no characters like 
that need to be escaped anyways - they can be written directly.