World: r3wp

either tool sets or individual utility functions.

the basic premise is that any tool should be able to have several 
competing implementations and versions.  They are available, made 
free of license restraints.

I would call this the Rebol Vault.  or in short   REVAULT which ties 
is very nicely with the REBOL itselft.

All this would need is a few conspirators who manage the code submission 
in order to classify them and make sure they comply to a clear manifesto.,

there is no refusal of code, only that it must obey to common sense 
rules.

then we would have a useable set of professional interworking toolsl 
which will grow instead of runing in circles.

rebol.org has many nice features.  but I feel (and sorry for being 
open and blunt) that its a tough resource to use.

many things either do not work or have no useable examples in how 
to use them.

any how... I am saturating this group... so I'll stop, but I'd like 
some support from others in trying to ORGanize the Content of rebol.ORG.

the site is well organized... but its content isn't

and it reflects the community.

wrt slim, people might say its not documented... well, it was all 
documented on the web for a long time... but that didn't change anything. 
 And I can't be the only one providing all the answers for such a 
community oriented project.  Other people have to jump in.  The list 
of advanced features within slim is too long to list here, but it 
has many things even python coders wish they had.

so  I ask this, is anyone willing to put a little bit of time where 
their mouth is... and help me organize the content of rebol.org.

I am not talking about adopting slim as it is.  it maybe too full-featured. 
 but we need a common reference.  and people underestimate how Carl 
perceives the work done by the community.  If the community tends 
to its own. and creates a precedent... I know Carl will be only too 
happy to work in the same direction.

I am sure that the good hearted folks on rebol.org will only be happy 
to get help and in the least some heart felt orientation on how it 
can be improved.

so, my ranting is done, it is not aimed at anyone its just that I 
wish rebol.org was more usefull for me... I imagine I'm not alone. 
 :-)

I am willing to put a bit of time on structuring a vault of high-quality 
and re-useability functions and toolsets.  Is anyone ready to help 
me put some time on it  ? (speccing, coding, refactoring current 
sources,  and/or management of submission of new code).

Maxim


I also personally feel that Rebol really needs an easy-to-use, well-organised 
standard library. (Ruby Gems seems to be a very good model). 


I will be willing to help once I have done a few of the things that 
I have promised to do

.. on Rebol.org

ok I will make a discussion for this:  revault   (just a working 
name)

Apologies -- REBOL.org was unavailable for just under a day, it's 
back now.

The problem originated with the ISP, and it took them a little while 
to work out what they'd done wrong.

Using a "non-standard" language seems to have added to their debug 
time:
Extracts from two emails from the ISP's technical support:

<<Hi, Sunanda.  Sorry this is taking a bit.  As I'm sure you know 
you have

a non-standard setup :-)  We aren't familiar with it and are puzzling 
it

out.  Am I right that you have your own scripting language?  And 
that
[snipped] is the [path to the] interpreter?>>

<<Aha!  Our web server rebooted yesterday.  It's a FreeBSD server, 
and for

a reason we haven't determined yet, the Linux compatability module

didn't load.  We loaded it and your site works again.  We'll figure 
out
why that module didn't load at boot.>>

Thanks Sunanda, it's cool to have an insight into what causes outages.

Thanks.

It's another example of Carl's blog observation: things take longer 
to fix if they don't go wrong.
http://www.rebol.net/article/0307.html

Hi. This is the qmail-send program at yahoo.com.

I'm afraid I wasn't able to deliver your message to the following 
addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

<[lists-:-rebol-:-com]>:
xxx.xxx.xxx.xxx does not like recipient.

Remote host said: 550-"The recipient cannot be verified.  Please 
check all recipients of this
550 message to verify they are valid."
Giving up on xxx.xxx.xxx.xxx.

--- Below this line is a copy of the message.

Sorry, hit return to soon.  The above is supposed to be preambled 
with a whine about me not getting into the mailing list.  I can't 
talk to lists spat rebol spot com.  And I just noticed I didn't mungle 
the list email in above.  I mungled  IP addressed to xxx.

tomc troubleshoots the ML -- a message here to him usually gets a 
quick response

Thankees

550 is a server error

There is this script in the library http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=ez-plot.r
but there seems to be missing the q-plot.r script, which is required:(

Thanks.

Looks like this dates back to the slightly mangled handover between 
REBOLtech and REBOL.org.
**
The script is here:
http://www.reboltech.com/library/scripts/q-plot.r

Though I haven't checked if it works.......If you could, and it does, 
please let me know; and we'll moe it over to REBOL>org

it is working

Thanks. It's in the Library now:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=q-plot.r

What about using Apache's Rewrite module [ http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html
] to make nicer links in the Library.

It would certainly be nicer to have shorter URLs. We inherited the 
use of CGIWRAP (which is creating all the long URLs), and were not 
able to remove it when we started. That's a great pity.

What I'd realy like is for the server to be running apache 2, so 
we could read the REDIRECT variables in the 404 handler. Then we 
could do pretty much any amount of rewriting of URLs intelligently 
in a REBOL script.
Sadly, we are still on 1.3 with no hope of an early upgrade.

The rewrite must be possible in 1.3 as well. You can move old links 
permanently using script.

Dear Library Team,


   I've only got a single script in the library, but I like it, and 
   I'd like it to live through the R3 update.

Are there any plans for adding explicit rebol versioning to scripts 
that want to stand the test of time?


   Is having multiple binaries on target REBOL platforms a no-no?  Meaning, 
   could the released binary packages for REBOL 3.0 include REBOL 1.3 
   (2.7) executables so scripts don't age out as fast as they did when 
   going from 1.2 to 1.3?  A little bit of configuring on the host OS 
   to start the correct REBOL by extension, shebang, or resource fork 
   on MacOS?  Can DO add a secret launch of older/other binary if a 
   Needs: is specified?

Curious.

there are no binaries on rebol.org

Graham;  Yeah, sorry, I knew I was bringing up two seperate points. 
 Should have mentioned it.  I'm just hoping the 700+ scripts in the 
library don't go to waste when everyone goes R3.  A little/lotta 
work on RT's part, a little/lotta work on the Library Teams shoulders...

Sunanda is the go-to guy on this, but we do have a tested-under field 
in the library header. At least that way you would have a clue if 
something was known to work under R3.

So I'll add a little/lotta work on contributor shoulders as well 
then?  Just that some contributors may be ex-rebols by now.  :)

Someday we'll have a slick auto-test system that runs each script 
under every known version of REBOL and gives a red or green light 
for each one. Of course, that means we need a test engine....result 
logging...Hmmm, might not happen right away. :-)

Gregg; If history is any indication, and you are involved, the future 
looks bright.  :)

Gregg hasn't been involved hands on in the library for sometime!

Graham;  Ok.  Credit where credit due.   I still want Mr. Irwin offering 
up hints and guidance, the same as I expect you to keep things on 
a nice shiny track as well.  :)

{Altme lost the first version of this post)

We don't as yet know the extent of the incompatibilities between 
R3 and previous versions.

The more incompatibilites there are, the bigger a problem we all 
have: most of us have personal libraries of useful functions (code 
snippets etc). If we cannot trust them to work under R3, then we 
all have a hiatus while we fix our code.

Yep.  Agreed.  I was pre-thinking potential work arounds...I've come 
to rely on the library scripts for information, inspiration and idle-time 
wasting.  :)

perhaps R3 can include some type of switch to check the header first?

The Library itself already has some problems with this.

The Libraty code (lots of it) runs under an outdated version of REBOL.

And that has trouble doing a load/header on scripts written for later 
verisons.

It's an annoyance at the moment, and not worth fixing yet if we have 
to go through another remediation to fix code for R3

That would be a good solution, Graham, if:
1. it were able to then load and run the right .exe

2. the whole software stack runs the same version......Imagine the 
annoyance if you need one utility that needs and earlier / later 
executable? (I don't need to imagine that; it's happened already 
for me)

Sunanda; I'm not a g-level rebol yet, but if you need to off load 
any mundane time-wasting low-brain work, send it this way and I might 
be able to help...willingness is there...skill? dunno.  :)