World: r3wp

Ahh .. nice .. I could use some help in health informatics !

Hmm.. I think the gui is only working for Windows ....

So, you'll have to run parallels etc

ok, good to know. For now, I will use R2 for some GUI work I need 
to do.

I could do that

I will try it on a Win NetBook my wife has

Yes, the OSX version does not include the graphics engine.

this will change once the host code is released, so those parts can 
be ported

And the r3 gui is about to be changed ... so it's a moving target 
as far as I understand.

ok

the documentation is also a little lacking ...

I was happy that that the R2 GUI works pretty well on Mac now.

there are still some bugs in the core (and more likely to be found), 
but the database at http://curecode.org/rebol3/can offer clues for 
workarounds.

Or, maybe the index to the documentation is lacking ...

someone messed up the GUI documentation in the wiki.

Henrik .. this is what people keep saying ... but the thing is a 
wiki .. how come no one reverted all the changes?

because there are two different UI prototypes with each their documentation.

I am still trying to feel myself around. So far I find the docs to 
be ok.

ok, if you need roadside assistance .. each subject has its own channel 
...

A samaritan will likely respond ... if St John's doesn't get there 
first

Graham, I don't know. I personally don't have the time to delve into 
dealing with reverting those changes. It could take many hours to 
do.

I mean .. once it was discovered .. it's a sql script to revert everything 
by that user ...

That's the whole point of having admins and a wiki ....

don't we have any communication with that user? an email address?

This discussion should be in docbase .. but I don't know anything 
about this event.

About that "YueM's AltMe problem" .. If i did my math correctly the 
entire Rebol3 database download would take almost 3 hours.  And that's 
with optimal connection on 56K modem, not taking account any errors 
or protocol overheads at communication.

Sounds like I should suggest he leave his modem connected for 3 - 
4 hours then!

it might not work in any case.  cause the larger groups timeout before 
the transfer is done.

and it gets unresponsive.  maybe the new "mark all as read could 
help a bit.

It also depends on protocol overhead.. Running TCP on phoneline... 
Well, it can be done, but happyly I have mostly forgotten those times. 
:)

the best for a new install is to get your computer to sync on a fast 
line and then its ok for the daily updates.

but if you don't have a laptop.. hehe I can see it being a bit complicated.

Welcome Keith! Don't be shy about asking questions. There are many 
helpful people here.

Hmm.. Couple questions.. 


A) Where/how/who to report a error (typo) on web page?  I know that 
rebol3 errors goes to curecode, but what about pages of R3? (page 
in question) http://www.rebol.com/r3/alpha-intro.html


B) Where I can find latest info on some particular part of Rebol 
3 project.. Like for example current status of  Unicode support? 
I found one web page, that has been 'in progress' for nearly 2 years 
so I don't think it's up to date. http://www.rebol.net/wiki/Unicode

A) Those pages are wikified. I guess it's a matter of getting access 
to edit them.

as for 2) - we managed Carl to release monthly plans. But as per 
his latest status update, he is now saying, he will not publish monthly 
status updates anymore. Those might be more frequent, or less frequent. 
I fear the latter. There is also beta release plan, to which we don't 
stick either, so who knows, what will happen ...

http://rebol.com/r3/docs/project.html

I think that after much applauded period of R3 development, where 
we got something like 80 tickets resolved a month, R3 did not receive 
much dev cycles lately, due to other duties - web site redo, R2 release.

I hope that R3 development is renewed soon, or it destroys ppls energy 
and willingness to cooperate.

For A) just pointing to someone who happen to have access..  Near 
start of the document   " it and report it in [CureCode]]. "  looks 
to me there is one braket missing..  


For the B... it was related to this Unicode-sorting problem.  After 
some digging I got the impression that Rebol uses Utf-8 as a internal 
string format even at runtime. It will make comparisions quite costly 
operations since the strings must be (at least as far as I can understand) 
be expanded to 16/32 bits/char before comparision.  I do assume this 
is well known (undocumented) issue and accepted tradeoff (trying 
to optimize size)?

pekr, Carl has been doing the most important work on R2 for the last 
2 monts...  its a SINGLE huge task.   The web site is also part of 
R3 mission.  Carl has putting off the seb site for years, I am happy 
he decided to put a hold on things and "just do it".

(the work I mention above is the extension and host kit work)

Maxim - a wishfull thinking on your part? First - isn't there a typo 
in your claim? First you say - "the most important work on R2", then 
you mention the jost kint and extensions ...

In any way, you are imo wrong. Since the mid of december, we can't 
see any single release, nor any single question towards extensions 
aswered on R3 Chat. This is not to criticise, but to state facts 
- the development of R3 is imo not happening right now ...

joanna: R3 uses either 8 bit (latin1 basically) or 16 bit (ucs-2 
basically) for strings, depending on the presence of code points 
> 255.

the strings are switched automatically between the two formats. you 
should never notice. so, no, it does not use utf-8 internally. R2, 
instead, considers strings just as 8-bit character sequences (eg. 
like C's char[]), so if you use utf-8, they are utf-8 internally 
as well (R2 does not know about charsets at all)

Gab, is there any document that has that info?  Besides reading the 
source? 


One additional quesiton.. How does Rebol know for sure that some 
internal strings are 8-bit? If strinds are manipulated (as they are 
series), what point they become 16bits?

Note.. I don't want to sound like ranting (I know development is 
s a slow process.. ) but.. but..

Every internal string must come from somewhere, that's how R3 can 
know

i.e. a string is either coming from a source file, then you have 
the source file's encoding. or it's coming from another input, then 
you'll have to explicitly decode from binary. or it's created programmatically, 
then you have the codepoint values

Hmm.. So if you  modify existing 8-bt string in a way that character 
won't fit on 8-bit slot it automatically expands the string to 16 
bit?