World: r3wp

Win32+Opera. Just enter usually gives:
   unicode:undefined char:

But it works sometimes and gives a new console line.

Sunanda, does it work in Opera here:

http://tryruby.sophrinix.com/

BBL, shopping.

There is problem with one FF setting - "find as you type". If it 
is allowed, after first char is being written in console, then find-as-you-type 
functionality jumps-in, and you start to enter your chars into specific 
search field ...

Ruby console does not suffer from this problem ....

From Linux and Firefox and spanish keyboard. Every shift 0-9 works 
ok, but shift 7 open the "Quiick search of firefox". I think this 
is not a error. I read this is the Firefox default for shift-7

console is going to be down for a bit while I do a rewrite of the 
console code.

thanks for testing, everyone

I am trying to do simple CGI tests, using Cheyenne, and in reference 
to following blog: http://www.rebol.net/r3blogs/0182.html

For: http://localhost/show.cgi?test- I do get:

Content-type GE te 127.0 


Why always only 2 bytes? Is that actually two bytes? I would say 
- two "elements"

The code is:

#!c:\!rebol\altme\worlds\r3-gui\files\rebdev\view.exe -q

REBOL [
    Title:      "show"
    File:       %show.cgi
]

print "Content-type: text/html^/"
print get-env "REQUEST_METHOD"
print get-env "QUERY_STRING"
print get-env "REMOTE_ADDR"
print newline

Is that R3 problem, or Cheyenne problem?

First thing I wonder about is - when you use function 'usage, it 
reports --cgi is available. Is it internally utilised at all?

Hmm, using no command line option, I do get:

Checking for rebol.r file in /c/!reb Evaluating: Content-type GE 
te 127.0 


The output is strangerly stripped too ... like R3 print output would 
be stripped ...

You should start your kernel with --cgi in order to activate CGI 
related processing. I don't know if it is supported by R3 alphas 
yet.

it does just the same as -q option, as per above blog article. If 
I provide no command option, I get strange output :-)


Checking for rebol.r file in /c/!reb Evaluating: Content-type make 
object! [ request-method: "GET" que

I think --cgi option won't be needed in R3 since the I/O seems to 
be much closer to the shell and get-env actually is available, removing 
the need for the cgi handling by the script on launch.

... Maybe BrianH will know, what is going on ....

Max - correct, but why the output is stripped. And using no command 
line option - what about above debugging info? Why is R3 telling 
me, it looks for rebol.r file? :-)

you should be able to redirect only the std err which shouldn't dumped 
to console... this is why std error exists.  works in R2 IIRC, don't 
know if the std err is accessible directly in R3 though.

probably because it spits out unicode which has 0 bytes in them.

might want to try converting the strings to binary before printing.

optionally encoding them in ascii first... http headers are ascii.

0 bytes meaning, bytes with the value "0". which act as null terminators 
in C land.

Issue reproduced here, it seems related to unicode strings output 
by your script.

hmm, strange. What can I do about it? IE displays chars correctly, 
the output in FF is weird, and I can't correct it by changing charset 
to any other setting ...

11/9-16:01:10.375-[uniserve] Output =>
{C^@o^@n^@t^@e^@n^@t^@-^@t^@y^@p^@e^@
G^@E
n^@o^@
1^@2^@7^@.^@0


}

C?o?n?t?e?n?t?-?t?y?p?e? m?a?k?e? ?o?b?j?e?c?t?!? ?[? ? ? ? ? ?r?e?q?u?e?s?t?-?m?e?t?h?o?d?:? 
?"?G?E?T?"? ? ? ? ? ?q?

the header MUST be printed out in ASCII.

Do we have any string encodings in R3 already?

Max - following blog does not imply that. Why should I do it on my 
localhost? It properly knows the codepage, etc.? http://www.rebol.net/r3blogs/0182.html

it being so old, its possible the decault encoding was still askin 
at that point.

askin = ascii

AFAIK unicode -> ascii is possible in R3 but don't know how... not 
having done it myself.  IIRC its on the R3 wiki or docs pages somehow.... 
googling it should give you some clues.

REBOL 3.0 accepts UTF-8 encoded scripts, and because UTF-8 is a superset 
of ASCII, that standard is also accepted.

If you are not familiar 
with the UTF-8 Unicode standard, it is an 8 bit encoding that accepts 
ASCII directly (no special encoding is needed), but allows the full 
Unicode character set by encoding them with characters that have 
values 128 or greater.

It should accept Ascii directly ....

that's on input.

print spits out unicode.

AFAIK

string! printing, to be more precise.  UTF and ASCII are  converted 
to two byte strings IIRC.  which is why you must re-encode them before 
spitting them via print.

see the system/catalog/codecs for a list of loaded codecs

 - hmm, docs need an update. Dunno why the section was moved to system/codecs 
 ... will ask on R3 chat ...

Max - I believe that Carl has written sone tricky string code and 
strings can be either single or double byte depending on their content.

possible, but I've always seen them output as double byte...  this 
topic has come around a few times in the last months

Running R3 from the Mac terminal the output from the print function 
is definitely utf-8 encoded.

I tried to look-up some codecs, but there are none for text encodings 
as of yet:

SYSTEM/CODECS is an object of value:
   bmp             object!   [entry title name type suffixes]
   gif             object!   [entry title name type suffixes]
   png             object!   [entry title name type suffixes]
   jpeg            object!   [entry title name type suffixes]

I think that to binary! will decode a Rebol string! to utf-8 :

>> to binary! "^(20ac)"  ;; Unicode code point for Euro sign     
== #{E282AC} ;; utf-8 character sequence for Euro sign

maybe peter's excellent encoding script on rebol.org could be used 
as a basis for converting between ascii -> utf8  when using R3 binary 
 as an input.  while R3 has them built-in

while = until

sort of like:

print to-ascii to-binary "some text"

I don't want to encode anything for simple CGI purposes, gee ;-)

but R3 is now fully encoded, which is REALLY nice.  you don't have 
a choice.  Resistance is futile  ;-)

and the fact that binary gives us the real byte array without any 
automatic conversion is also VERY nice, for building tcp handlers... 
it would have made my life much simpler in the past in fact.