World: r3wp

The first A is defined inside MY-CODE-A block. And because you do 
not use copy [], it's not rewritten every time you call MY-CODE-A 
block.

OK... it is a quiestion of pointer assignement in some way...

why pointer? by doing my-code: [a: [x x]] I just assign the block 
that is the second in MY-CODE to A

same? a second my-code
== true

It looks to me like everytime you call my-code-a, you assign the 
block defined in my-code-a to the variable a which is globally accessible. 
When you write a: [] outside my-code-a, you assigne another block 
to a... a is a pointer and you swith the adresse it is pointed to.

>> my-code-a: [a: [] append a 'x]
== [a: [] append a 'x]
>> do my-code-a
== [x]
>> a
== [x]
>> a: copy []
== []
>> append a 'y
== [y]
>> a
== [y]
>> do my-code-a
== [x x]
>> a
== [x x]

To explain it even futher, here is yet another example:

>> my-code-c: [a: []]
== [a: []]
>> do my-code-c
== []
>> append a 'x
== [x]
>> my-code-c
== [a: [x]]

hope, it is clear what is going on

just forget about pointers, please

sorry... C bad habits :)

Example prolonged:

>> my-code-c: [a: []]
== [a: []]
>> do my-code-c
== []
>> append a 'x
== [x]
>> my-code-c
== [a: [x]]
>> a: []
== []
>> my-code-c
== [a: [x]]

thanks ladislav... i got it!!!

An even longer one:

>> my-code-c: [a: []]
== [a: []]
>> my-code-d: [a: []]
== [a: []]
>> do my-code-c
== []
>> append a 'a
== [a]
>> my-code-c
== [a: [a]]
>> my-code-d
== [a: []]
>> do my-code-d
== []
>> append a 'c
== [c]
>> my-code-c
== [a: [a]]
>> my-code-d
== [a: [c]]

Why core doesn't support clipboard port?

Oh, I just find it is already in RAMBO.

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}.