World: r3wp

I would like to disagree in this case. Not that it is important, 
but, in my opinion, the expression

    a: []


can be considered "assignment", whatever that means. In that sense, 
the value is "assigned" to a variable.

What is more curious in the "You set the word a to refer to the block 
defined in my-code-a" is the word "defined". The truth is, that MY-CODE-A 
is a block, that is created by the LOAD function at (roughly) the 
same time its contents, including the above mentioned subblock, come 
into existence.

What I wanted to tell was, that while the source string defined the 
subblock, as well as the MY-CODE-A block, the MY-CODE-A block only 
happens to actually contain (refer to) it.

Just spent the last hour searching for the cause of an issue in my 
code. It appears to be a native LOAD bug, as shown by the code below:

>> length? probe load "[<] b [>]"
[<] b [>]
== 1

(I've reduced the use-case to its minimal form)

Seems that there's a shorter form that has the same issue: "[<][>]""[<][>]"

Sorry (paste duplicate), I meant: "[<][>]"

Just added a ticket in RAMBO, now need to find a workaround.

Yeah, I remember that one from a couple years ago. The arrow words 
are special cased, and in R2 the tag type is recognized with higher 
priority unless there is a space afterwards.

Right, this one is working: 
>> load "[< ][>]"
== [[<] [>]
]

It's fixed in R3, so the fix needs to be backported. The main problem 
is that this code is output by MOLD.

>> mold [< ]
== "[<]"

Nasty one.

There are some bugs that are so bad that no backwards compatibility 
rule should apply no matter what.

I wish that the syntax precedence rules could be published so we 
can debug them, but apparently the loader is hand coded. I am trying 
to document them through reverse engineering.

That would help!

I already did this for word syntax for R3, and the process led to 
some bug reports.

That's the second native bug I hit today...This morning while searching 
about an issue in Cheyenne's CGI handling (reported by PeterWood), 
I found out that the REBOL's CGI output in binary-mode is not working 
(it stays in string-mode, so corrupts binary data).


Is this the correct way to switch the CGI output to binary mode?: 
set-modes system/ports/output [binary: true]

I thought CGI required WRITE-IO for binary output.

In R2 at least.

I've tested both with INSERT and WRITE-IO, same result. But I've 
used CALL/OUTPUT on the test CGI script to simulate a call from a 
webserver.

Here's my test script: 
#!c:\dev\sdk\tools\rebol.exe  --cgi
REBOL []

print "Content-Type: application/octet-stream^/"
port: system/ports/output
set-modes port [binary: true]
insert port #{0D}

it's probably the PRINT that is corrupting

If you try to CALL/OUTPUT this script from 2.7.8, it will just freeze 
your REBOL session.

try using `prin rejoin [... crlf crlf]`

Testing that...

i vaguely remember that i had cgis using write-io to send binary 
output working

years ago :)

Was it on Windows?

definitely not

and the print/prin thing obviously won't help with CALL/output crashing 
or freezing

unless some line-ending recoding code in rebol is causing the crash 
:)

Then the error should show up less frequently, it would need #{0D0A} 
in the data to produce a corruption.

Your workaround doesn't work, same result, I'm getting #{0A} instead 
of #{0D}.

what if you set
system/ports/output/state/with: none

Same issue.

and with:
system/ports/output/state/with: "^/"

with: "^/" + write-io is another candidate :)

I was wondering if it could be related to a CALL issue, but my own 
CALL.r implementation in Cheyenne shows the same result. So I guess 
it's definitely an internal CGI handling issue.

Not any better...

Can't find any ticket related to this issue in RAMBO.

I think CGI  should set the line ending to crlf so PRINT  works right 
for the header, even on Linux.

http://www.mail-archive.com/[rebol-list-:-rebol-:-com]/msg14312.html 


Tim said in 2002 in that post that "Is working intermittenly"...I 
wonder if this bug is not hiding there since the begginning (assuming 
that Tim was testing on Windows).

$ rebol --cgi --do "print 'foo" | hd
66 6f 6f 0a

Doesn't WRITE-IO work in binary mode even if the port is in text 
mode?

but even if it would, doc's original print would mix "^/" plus crlf

with: crlf => not working

WRITE-IO in text mode => not working

Ok, weird. I don't know if this is the case, but IMO the --cgi option 
should cause the output port to be in text mode and to convert ^/ 
to crlf, network standard. And then WRITE-IO should not do any conversions, 
and output in binary mode regardless of the text mode of the output 
port.

correction to the above: when actually running as cgi, `print rejoin 
[.. crlf]` seems to work fine