World: r3wp

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?

that's the way i understand it, yes

Well. at least to-binary shows the string as UTF-8  , if it's not 
the internal representation...  Dunno what to say..

Joanna: I haven't read the source (I have no access to it). I only 
know what Carl tells us. :-) I don't know if this has been documented 
somewhere, it is definitely buried within loads of AltME messages. 
:)

as I said, whenever you do a change that requires the internal representation 
to change, the string is converted. So if you have the string "joannak", 
that is represented as the sequence of bits 6A6F616E6E616B internally. 
if you do something like insert string #"^(1000)", the internal representation 
becomes 1000006A006F0061006E006E0061006B (endianess issues aside).

You never notice this (and in fact, don't need to know), because 
strings are always converted on i/o. to binary! string will convert 
it to UTF-8. other i/o will convert it to the platform's standard 
encoding (UTF-8 on Mac and Linux, UTF-16 on Windows)

ok, I have been diving into R2 a little more and I was curious why 
it is so hard to use the scripts on rebol.org. I am using new-blog.r 
for example and it appears that I am going to have to rewrite parts 
of it to get it to work properly. It is probably a configuration 
on the hosting provider I am using. Is there any documentation on 
how CGI processing works internally. I see all the tutorials and 
stuff and I understand that. I used that to get some of my scripts 
working. What does rebol -cs really mean? I am just trying to figure 
out how to determine where in the script it is failing. Any ideas?

rebol -cs launches rebol in cgi mode (-c) with the security sandbox 
disabled (-s)

what does the sandbox prevent you from doing?

writing or reading files, for example

ok, I thought that was the case

I know this is a stupid question. how do I know where in a CGI it 
is failing?

not a stupid question at all

I can write my own scripts and debug them pretty easily.

when trying to use someone else's is another challenge in itself.

CGI debugging is horrible. typically it's easiest to put a `print 
"Content-type: text/plain^/"` at the top of the script, then you'll 
most likely see the rebol error message

R3 will make this easier?

at the top: right below the initial REBOL [...] block

there is a trace I saw in R3

I will try that

Hello!  Looking for some general advice.  Just completed my first 
project in REBOL as a learning experience, a simple departmental 
database using View 2.7.6 with HMK's LIST-VIEW and Dobeash's SQLite 
driver.  While I'm sure there is much I could have done better, it 
works well enough that people want to use it!  Now my boss is looking 
for another LAN-based departmental application.  Will use REBOL of 
course; probably can get by w/ SQLite again.  But my questions are 
these: (1) use View 2.7.6, the new 2.7.7, or try 3.0?  (2) stick 
w/ the standard View/VID, and LIST-VIEW, or try Dobeash's RebGUI? 
 
Many thanks in advance for any advice you can share!

3.0 is not production ready at this point. Still under heavy development, 
so maybe just stick with 2.7.6. LIST-VIEW is untested under 2.7.7. 
I haven't had the time to test it (but please do, and tell me if 
it fails :-)).

I'm just curious Jack, did you project REALLY need a database at 
all?

I find that "most" places where people use a database, a few pages 
of code that can insert and delete stuff from a simple text list 
would work just fine (AltME does this for example, there is no database 
behind this).

Thanks Henrik!  LIST-VIEW was a BIG help in presenting data...I did 
have a few problems w/ displaying large text entries (> 200 characters?), 
which was likely due to me not knowing what I was doing!  Part of 
my concern in what choices to make was trying to prepare for the 
future of REBOL; if LIST-VIEW will not be an option under 3.0, but 
something like tables in RebGUI would be, then I want what I learn 
to carry forward for me.

So maybe I'll stick w/ what I've used, but upgrade to 2.7.7.  This 
will be a back-burner project, but I will certainly provide feedback 
on LIST-VIEW under 2.7.7 as I move forward.
Again, thanks for the great tool and for the ongoing support!

jack-ort, LIST-VIEW will be replaced with something smarter and more 
modular in 3.0. I don't want to lose its functionality when moving 
to 3.0 for production projects.

Main issue with LIST-VIEW is that it's too big and monolithic to 
debug properly for me. And thanks for using it. :-)

Hi Reichart - well, I thought I needed a db.  Plan is that once enough 
data is gathered, managers will want to run queries against the data. 
 My thought had been to give them a MS Access link to the SQLite 
db, and they can either use canned Access reports, or if they know 
what they are doing, allow for ad-hoc SQL queries.  Now, if there 
was a good reporting tool for working against the simple data storage, 
I'd consider switching.  I like simple!  :-)

It sounds like you're on the right track Jack. I still use VID, but 
some people prefer RebGUI. My main reason for not switching is inertia, 
and not having enough need to port things. Ashley's work is always 
great and well supported.


Whether you need a DB depends on your needs. The ability to use existing 
queries or reports is valuable. If you really need ad hoc query capability, 
a DB can make sense, but then you need someone who knows SQL.

RebGUI makes it easy to have a profesional looking App but I often 
hit a wall with it when it does not offer some needed functionality 
(like list-view). I often end up using VID again because I can "hack" 
it to what i need.

Hello again.. Been away for some months, still noob :-)

You're only as young as you feel!