World: r3wp

Part of the "problem" is that REBOL is really built for programming-in-the-small 
today, and being interpreted, you can't optimize out things you don't 
need--not without a preprocessor of some kind. It also lends itself 
to simple, direct word use, not the more verbose context/func approach. 
That makes it harder to build effective libraries. 


I've often thought that the best approach might be a simple library 
of "global" functions, which would basically add to the available 
words in REBOL, so they should be very generic, and there might be 
a lot of them. More complex modules would be contexts, and we'd need 
an agreed upon system for naming, exported words, etc.

Collecting things is a good first step, but then we quickly need 
to consider something like Ladislav's #include function  and a context/module 
standard.

I've been dumping functions on Big Bold's snippet repository; it's 
easy and provides visibility to non-REBOLers, but you can't search 
for stuff by tags and there is no collaboration system of course.

Hi All,  I have often discussed the stuff... I have done more than 
just propose, I have coded an open framework to handle libraries.

it has been used, I use it daily.  I have been using it for several 
years now.  and it does many things more than include.

I'm not saying its perfect.  never have, but it was supposed to be 
a starting point where people could agree on a platform for sharing 
code.

it already handles all of what Carl proposes wrt modules.  except 
what can't be done like namespacing, and memory protection, which 
have to be hard-coded in the interpretor.

its on rebol.org its called slim.r

but the basic issue with the REBOL community in general is its lack 
of unity....  Most of us are free thinkers.  We do our own, cause 
we can !  :-)

its funny that Gregg brings this up (again) cause I was chatting 
to sunanda about setting up  a special part of rebol.org.

which has no "scripts"  but actually  "libraries"

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.