World: r3wp

Anyone know if in R3 that op! will be treated as an op! in a block 
before evaluation?

be nice to do something like:

op? second [this + that ] 


and have it return true.  I know it is a word value now but I never 
understood why it was made word there.

>> type? first [+]
== word!

wow, found a crash :-)

First RebDev version was uploaded to our private world a few seconds 
ago.

The first screenshot of the CLI interface:

http://rebol.hmkdesign.dk/files/r3/gui/174.png

Server is still running on R2 for reliability, but it was written 
in R3, so apparently it's compatible.

The client appears to be a bit over 20 kb of code and is fairly simple 
to use. Still some bugs left to solve, but moving quickly forward.

so all console driven ?

is it cgi or lns?

or direct tcp?

all console driven, yes. it appears to be plain HTTP as it runs off 
port 80.

If the RebDev serve runs on R2, how does it handle character encoding? 
Does it simply ue the default Windows codepage on the client machine?

I would not trust non-ascii characters for now. With any luck the 
server saves the messages as binary UTF-8, don't know yet.

The current client is console driven (old school BBS), but there 
will be many more clients.

The current server is implemented as CGI scripts, though FastCGI 
is planned for later.

Not trusting non-ascii characters infers  that the current desing 
of  RebDev is "ignorant"of character encoding. If that is the case, 
it is a shame as RebDev could have been a great example of an "up-to-date" 
application built with R3.

Doesn't this all depend on the limitations of the front-end used?

It has to be this way as long as the server is running on R2. Says 
nothing about R3 or the design of RebDev

Even if the server is running on R2, all the strings could be stored 
with a consistent encoding method, such as ISO-8859-1. Of course, 
there'd be a lot of work detecting the client encoding method and 
converting all input strings to the chosen consistent method. Most 
of this work would be needed even if the server supported Unicode 
strings.

Personally, I think ignoring character encoding does say something 
about the design of RebDev.

considering that R3 will probably just send everything as UTF-8, 
I don't think the server has any reason at all to worry about encodings.

you have to worry about encodings when you do conversions. i don't 
see where the R2 server is doing any of that. Also, with UTF-8 there 
is no need to worry about encodings on searches and things like that. 
The only issue could be sorting, but that is also region specific 
so it's a completely different issue that R3 cannot solve globally 
either.

As you say, if all the input is UTF-8 everything will be fine. I 
mistakenly thought that the inputs from different environments would 
have been differenlty encoded as they are with R2.

That would have to be the case with R2 clients, as the client is 
the part that handles character encoding. However, there are no R2 
clients yet. The messages appear to be UTF-8 encoded end-to-end, 
stored in binary on the server, which is encoding agnostic. Once 
we have R2 clients, they will have to handle the codepage-to-UTF-8 
encoding, or just stick to ASCII.

And yes, it does say something about the design of RebDev, that character 
encoding issues of R2 won't affect it, by design.

This is one of those things where a picture is worth a thousand words. 
 We need a diagram of the hardware and software set up, and show 
WHERE encoding becomes a problem.

For example, if you paste some text from a Word doc into a webbrowser, 
 this then gets moved to the server.  Then it gets rendered out again...you 
wil run into problems with encoding.

Word use some SPECIAL encodoing for things like " : - and '

That sounds like an issue between Word and the browser edit field, 
or between Word and the clipboard

RebDev now has a webfeed suitable for iPhone.

Reichart, I still think that is not the fault of Word (except for 
changing your character on you) or the browser.

Some shots of rebdev on iPhone:

http://rebol.hmkdesign.dk/files/r3/gui/176.png
http://rebol.hmkdesign.dk/files/r3/gui/177.png

:-)

wahouuuuuuu !!!!

I think this will be open, so someone can get to prettify it later. 
The mobile version is simpler to do so it's done first.

That's great!

Henrik, Is that in iphone's browser?

yes

10 seconds to reply...your getting slow

:-) it runs in the iPhone simulator, but it works the same as on 
a real iPhone. If you have XCode and OSX Leopard you can test it 
out yourself.

So its html...why is mobile easier?

because it's just a simple HTML page. you can't post yet and you 
can't login to your own account yet like the console version. it's 
meant to be used with lesser browsers for smaller phones than iPhone 
as well.

and it was convenient for Carl since he owns an iPhone.

Gab, not an issue of "fault", I'm simply modeling examples of problems 
I see on dozens of websites, due to encoding "issues".  Don't care 
where the fault is, just that we need better black box tools fro 
dealing with it.

Reichart: From my point if view, the root of the problem is not so 
much that Word replaces key certain key sequences with other characters 
but on eof character encoding. The text will look okay on your machine 
but unless it is correctly converted may display incorrectly on other 
machines.


As I understand, Rebol/View uses the users default "codepage" on 
Windows and  MacRoman encoding on Mac. AltME doesn't take into account 
the different the different text encodings so when I type £ (a British 
pound sign) you will probably see some thing different.
 .

eof => the

Pound is similar over many code pages: more diverse -- ½ -- Mac: 
omega; Win/west: 1/2; Win/east: right-smart quote.

On rebol.org, you get a ? -- http://www.rebol.org/aga-display-posts.r?post=r3wp453x8946

On rebol.net, we shall see -- http://www.rebol.net/altweb/rebol3/chat453.html

REBOL.org shows a ? because if blindly emits all Alte pages as charset=utf-8.

If (this works in Firefox....You change your default for the page 
-- view/character encoding / western iso-8859-1) then:
-- Peter's post shows a GBP [for his char 163]
-- Chris' post shows a 1/2 [for his char 189]

_Part_ of the problem is that altme server --> client channel (ie 
what is sent to each of us when someone posts a message) does not 
seem to contain charset information......I may be wrong about that, 
but I do not see it anywhere.

I have not idea if client-->server channel does send that information.

I don't imagine it would -- I'm not sure there's a way within Rebol 
to detect the charset in use...

Peter....I'm confused....

Word, nor REBOL have anything to do with the problem....


Encoding problems happen on hundreds of websites (big, popular website), 
that do not use REBOL, and where Word is not the source.


I'll state again... we need strong clear black box logic that unifies 
all character maps (yeah, all).

WE need a single unified character system.