World: r3wp

http://97.107.135.89/projects/rebol/r3shell/


A tiny bit of progress. No visible cursor yet. Limited console history. 
Only capitalized chars (dunno why yet).

It does not display anything here, at least not in FF nor IE. Do 
you have any real output from R3 console already? ...

IE does not work (surprise)

just had an error in my code, try reloading, I won't edit for a few 
minutes.

there is no R3 yet, only trying to get a decent console for now. 
returned values are just echoes of the buffer.

Actually, the R3 part can be handled by someone else, if you feel 
free to try. we should just agree on how to talk to eachother. I 
can submit an ajax request and then output whatever is returned in 
the console.

Damn it, how can we throw an handmade event! ?

when i construct an event! with something like:
>> make even! [type: 'minimize gob: my-gob port: port-event]

i got:
** Script error: cannot set gob: field to gob! datatype

Wtf, i can't set the gob field with a gob ??????

Each time i try to rework on new gob styles, i'm stoped by such lazy 
bugs

seems that capturing the correct keycode is a bit chaotic in different 
webbrowsers.

Steeve - put it into CureCode ... maybe we ignored GUI related bugs 
for much too long ...

Ever so slight improvements: got some more decent lower case chars 
now and cursor movement seems to work OK. IE still doesn't work and 
many special chars still don't work.

Max: I think your suggestion to Henrik of running an R3 server port 
to perform the evaluation is the best way to go. One sligth problem 
is that server ports don't work on Linux.

uf, Carl might seem convinced to add time/memory option for security 
settings :-)

Could someone test this under Linux Firefox, WIn32 Firefox, Win 32 
Safari and Win 32 Chrome:

http://97.107.135.89/projects/rebol/r3shell/


I'd like to know which keys don't work on the keyboard if you press 
shift 0-9. Thanks.

I see odd results: Win32 + FF...

** they all work if I press shift+n and release the shift each time.
** but if I do shitt+09876 it goes wrong at 6:
      )(*&)(*&)(*&^c_
** ditto the other way, it goes wrong at 7:
    shift+1234567    ==> !"£$%^&_  ;; what I'd expect
But:
    shift+12345678  ==>  !"£$!"£$%^&*_

does the % char come out properly?

(it would be fortunate if they all misbehaved the same way, but I 
fear they don't)

Yes, shift+5 ===> % as many times as I like.

I see, you are using a standard PC keyboard, right?

Standard for the UK, yes.

Win32 + Chrome:
(Backtab) do nothing
(left parent) do (backtab)

Period works as backspace here. % does nothing.

i meant backspace, not backtab ;-)

backspace in win32 chrome here goes back to the previous page.

that is of course in VMWare on a mac.

You did not ask about Win32+Opera, but I tried anyway....

 % (shift+%) acts as a backspace.... but that is when the console 
 works.
Other times the console is just black.

if the console goes black, then the row is blanked out. pressing 
enter should reset that and give you a new line.

I think I'll have to rethink this. I've done it mostly like a traditional 
terminal, but this is clearly not very stable.

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.