World: r3wp

Consistency between OS platforms. On platforms other than Windows, 
/Core doesn't need X or any other kind of GUI, and so doesn't require 
the libraries (good for headless servers). When there is no GUI, 
there is no clipboard. The Windows version of R2 just inherited this.

you assign the block defined in my-code-a to the variable a


In addition to not thinking in terms of pointers, the REBOLish view 
of the above would be "You set the word a to refer to the block defined 
in my-code-a"; words refer to values, values are not assigned to 
words. An important distinction.

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