World: r3wp

Welcome back...

Thanks, Reichart.

Geomol -- Thanks....I've made the changes and notified Carl that 
his documentation has been updated.

Doing a search, "Author: Maxim" doesn't briing up his newest script, 
Blood.r   The author field in blood.r is the same as other scripts 
which do show up with the above search.  A search for "Liquid" does 
return blood.r.  Is this a case of "hasn't been indexed yet"?

probably.... use the "latest scripts" link.

if you just put maxim in the search field, blood is in the list

Maxim, I have the script.  Playing with it now.  If I was directing 
this question at you I would have put it in the !Liquid group.  ;-) 
 This is a question about the behind the scenes opperations of rebol.org...

I know   hehe

Ammon -- some of the indexing happens in the background, so can trail 
12 hours or so behind a script being updated.

In the specific case of searching for an author name, the syntax 
you need is different:
    [author//maxim olivier-adlhoch]
Help for searches is here:
   http://www.rebol.org/boiler.r?display=introduction.html

Of course my syntax was wrong.   It probably fairly common for someone 
to search the library for a specific set-word! and even if it's not, 
we definitely want to allow for it.

I expected granular indexing as well...

Thanks for the info!

Guys, at the moment, rebol.org is soooo slow here, something like 
10 sec to appear. Is it just my experience here, or are there any 
problems? ...

Nope.  I'm actually getting rebol.org in about 2 seconds but I'm 
seeing about 10 seconds of lag on this world.

Sunanada, I have another question for you.  While I was poking around 
the library earlier I noticed that I have named some of my scripts 
very poorly and would like to change the FILE: value in the header, 
which apparently just creates a new copy of the script.  Is there 
a way to remove the old script such that I really am renaming the 
script rather than uploading a new one?

Also, the link to the list of license tags from the [license] link 
of a script is broken.  You have an extra slash in there.

OMG!! I just discovered there is an online DIFF engine on rebol.org 
!!! WOW... sunanda... you must provide that functionality upon script 
update, this is too awesome to hide away in an easy to miss set of 
links in the script statistics.

I mean, if we could view the diff before pressing "update" we would 
have something starting to look like an integrated VCS  :-)

I second the motion!

the interface is already ubber clean  :-)  


if I had this on rebol.org update, I think It would make the update 
process even more appealing for potential new users.

Ammon -- I can rename existing scripts. It's a moderator-only function.
If you want it done, please let me know which ones.

Ammon -- thanks for bug report.

Maxim -- thanks....the diff function code is an embarrassing collection 
of random hacks. I'm hoping someone else will write a better version 
that could be made public :-)

well what I am seeing impressed me ... I wasn't expecting that on 
rebol.org... really you should allow us to compare right in the update 
page.  I know I'd use it every single time  :-)

might even use rebol.org more :-)

in fact... might = will

I attempted to rename button.r to vid-button.r so the new script 
should be deleted and the old one renamed if possible.  As for the 
rest of them...

wizard.r  TO vid-wizard.r
group.r TO vid-group.r    
drop-down.r TO vid-drop-down.r   
dragbar.r TO vid-drag-bar.r       
date.r TO vid-date.r


Since we won't be calling the GUI Dialect in R3 VID the new names 
should make what the scripts do clear even after R3 GUI scripts start 
popping up...

Thanks Max -- I'll take a look at making that an option on upload.

sunanda COOL  :-)  and promote it on rebol week, on the ML and in 
"announce"  here too, really I think its a big deal/feature.


 I woundn't be surprised that most rebol.org users don't even know 
 the diff was there  ;-)

Maxim -- not sure it'll be that *cool* -- most people are probably 
not aware of it as you can only see it in action for the scripts 
you own.

Ammon -- thanks again for the license link bug. It's fixed now.....Shows 
how seldom anyone checks license T&Cs for scripts :-)

=D

sundanda:  its cool for script owners.   It adds value in suddenly 
being more than just a storage space... I can even check my code 
as I submit it.

for me anyways, it adds a feature that I can really use ... an online, 
simple VCS.


I can make sure that a new release not only is shared, but also free 
of a set of bugs.  I can suddenly say.. what did I change... and 
more easily comment on it, for example.

Ammon -- those scripts are now renamed as reqeusted.

Sweet!  Thanks.

I just added ascii-math.r to the library. It looks fine in the  view 
, but the downloaded file contains gibberish characters before each 
non-standard ascii char. This problem may be related to the problem 
that Oldes was having on 14-Mar-08.

Thanks for the script -- and for the problem report.

Looks to me like the script, as uploaded, contained non-UTF8 characters, 
and they are being treated as multi-byte characters.

REBOL, and REBOL.org can really only handle ASCII....Unicode and 
such like is for R3.


If you email (preferably in a ZIP to prevent email software from 
chewing up the code) the original script, I'll take a look.

so you support utf8?good to know.. next time I will upload it as 
utf8

The library doesn't support utf-8 yet. We  have found that many people's 
browser are set so that the browser renders the output from rebol.org 
as utf-8.

In this way, the library accidentally supports utf-8 in the sense 
that if you upload utf-8 and display it in a browser set to display 
utf-8 everything will be displayed properly.

The core of the library system is old enough that it was written 
without considering character encoding at all.

Supporting utf-8 will require a lot of changes ..... though probably 
not quite as many as moving to R3.

If most of it is currently ascii, would it not just be a case of 
adding a few filters?

'it', being current content.

Preventing any new content from posting invalid sequences, for example...

Peter beat me to it, thanks.

Sorry Oldes, the Library does not support utf-8, despite my confused 
suggestion that it did.

Because we use a charset of UTF-8 in the browser header, it is _possible_ 
that we can more-or-less handle scripts with 2+ byte UTF-8 codings 
in REBOL strings! But that's not been tested.


Good point, Chris -- we already have such a filter, but it is not 
used to turn back conributions.

Sunanda, I have emailed the zipped script to you.

Chris, one issue that we face with the mailing list archive is not 
knowing how the imput is encoded. I think this is also true of scripts.

Thanks, Scott.
--The email script looks fine
-- it's identical to what is in the Library
-- Viewing the scriot works fine
-- Downloading it doesn't

.....Which is exactly what you reported. We are now both on the same 
page :-)

We've had a similar problem before (I've just checked the source 
code, and it's prompted my memory).


To solve it, we analyse the script for various extended ascii chars 
and then perform some messing around on HTTP content-type headers.


It's messy, and it's worked up til now......But obviously, we need 
some more analysing and messing around for this script.

Results of a tiny bit of debugging on the ascii chars problem:
-- problem seems to be at the input stage:

     -- if you have exended ascii characters (top bit set, like the 1/4 
     used in the script) what we get from the webserver is bad (extra, 
     unexpected extended ascii chars)

    -- only download is (visibly) affected, although the extra extended 
    ascii chars are present in the text streams

     -- though there is some REBOL mezz code (decode-cgi) that may be 
     doing something I do not understand

    -- I can replicate the problem with both Apache and Xitami which 
    suggests the problem may be in REBOL rather than a given server.


-- the quick fix would be to add accept-charset="ISO-8859-1" to the 
<form ....> or <textarea ....>

    -- but that stops all extended ascii, including the ones we want. 
    So we won't do that.

-- the slower fix has yet to emerge from the available options.

why not standardize everything on UTF-8?

As far as I know, Core 2.5.6 (what the Library CGIs runs on) does 
not support UTF-8.

does not support UTF-8

 - what do you mean by "support"? if you mean having native encoders/decoders, 
 no, it does not. but, utf-8 is just 8 bit characters, and it is backwards 
 compatible with ascii. if you can handle ascii, and leave alone any 
 char > 127, you already support utf-8.