World: r3wp

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

and write-io with 2.7.8 on linux actually running as cgi works fine 
as well

#!/usr/local/bin/rebol278 --cgi
REBOL []
print rejoin ["Content-type: application/octet-stream" crlf]
write-io system/ports/output data: #{610d620a63} length? data

`curl ... | hd` gives me `61 0d 62 0a 63` as desired

No conversion issues on linux: 


rebol --cgi --do "print 'foo p: system/ports/output set-modes p [binary: 
true] insert p #{0D0A}" | hd
00000000  66 6f 6f 0a 0d 0a

Launching the script with CALL on linux (using /Core 2.7.6) shows 
something interesting at the end :-))

>> s: "" call/output "rebol -c test.cgi" s
== 0
>> probe s                                
foo^/^/^M

Ok, no it's my mistake

Works flawlessly on linux.

I came across the issue as I was trying to run REBOL/Services under 
Cheyenne in GCI mode. I have found that 0x0D bytes get changed to 
0x0A, it doesn't matter what they are preceded or followed by.

I also found that 0x0D0D gets converted to a single 0x0A.

I suspect that the problem is more likely to be with 'call than REBOL 
in CGI mode as REBOL/Services  runs as a CGI under Xitami on Windows.

The problem does not occur on OS X.

I have run a test which seems to show that the problem lies with 
'call.

First I ran a small command line pgm:

Will post the results later ....

This is the console output from the command line pgm:

C:\REBOLServicesTest>cr
)haracter 13 is enclosed in the parentheses (


I then checked that the command line pgm could be successfully called 
with the following two lines of Ruby:

	puts %x{cr}
	print %x{cr}.dump

Which gave the following output:
C:\REBOLServicesTest>ruby call_test.rb
)haracter 13 is enclosed in the parentheses (
Character 13 is enclosed in the parentheses (\r)

I then called the command line pgm from a REBOL Console session:

>> call/console "cr"
Character 13 is enclosed in the parentheses (
)== 0
>> print to-binary {Character 13 is enclosed in the parentheses (
{    )}
#{
43686172616374657220313320697320656E636C6F73656420696E2074686520
706172656E74686573657320280A29
}
>> buffer: make string! 256
== ""
>> call/output "cr" buffer
== 0
>> probe buffer
Character 13 is enclosed in the parentheses (^/)
== "Character 13 is enclosed in the parentheses (^/)"
>> print to-binary buffer
#{
43686172616374657220313320697320656E636C6F73656420696E2074686520
706172656E74686573657320280A29
}


As you can see both call/console and call/output turned the 0x0D 
into a 0x0A.

I've added this to RAMBO.

I concur, it's a CALL issue and not a --cgi one. I did more tests 
with my own CALL/OUTPUT implementation and it doesn't show any newline 
alteration in the binary CGI output.

are there known bugs where DECOMPRESS works on certain data in one 
OS (OSX here), but not in another (Windows XP)?

hmm.. never mind. seems to be a memory problem.

I guess this is a bug in R2's lexer:
>> 2#
== ##
>> 4#foo
== ##foo
>> 456457#foo
== #56457#foo

IMHO it should return a syntax error

That must have changed in later version. I tested such things deeply 
1-2 years ago and wrote a document, that I sent to Carl. Back then 
I noticed:

>> 2.2#
** Syntax error: Invalid "integer" -- "2.2#"


, and I suggested, it should be an invalid decimal, not invalid integer. 
Today I get:

>> 2.2#
== #.2#

There are many such situations.

trying to get info on a file via ftp using to long version of teh 
port spec as my user name is an email address:

fport: [
    scheme: 'FTP
    host: "ftp.example.com"
    target: %/file.txt
    user: "bill@ example.com"
    pass: "vbs"
]

I can read it with "read fport"

but I can not get other info from it like:

print modified? fport

Whats the method here?

Have you tried applying this patch?


net-utils/url-parser/user-char: union net-utils/url-parser/user-char 
make bitset! #"@"

many sites don't provide that information I've found

Gregg,

Thanks! That works great....never saw this before!

Sometimes depending on a flag you might want to call a function with 
a refinement or not.

So:

either flag [ test/refinement ][ test ]


Is there a simpler way this could be done without passing a parameter?

test/(either flag [ refinement ][none] )
looks ugly

It doesn't work either.

no :)  I was just thinking of what syntax could be used !

how about making a refinement of none always legal??

I guess someone would say it adds unnecessary overhead

You could always add a refinement of /none in the function spec.

I'm not sure if it would affect anyother use of none inside the function 
though.
>> test: func [/refinement /none] [if none [print "yes"]] 
>> test/none
yes
>>

I guess so :)

Interestingly that turns none into true

>> test: func [/none ][ ?? none ]
>> test
none: none
== none
>> test/none
none: true
== true

so redefining none is not what I had in mind!

APPLY. Try this: apply :test [flag]

R2 has a mezzanine APPLY, R3 has a native one.

We use it a lot in R3 for wrapper functions that forward refinements 
to the functions they call. The names can even be different because 
APPLY is positional. It is a little slow in R2 for small numbers 
of refinements when compared to the conditional code, but really 
easy to use, which makes the difference.