World: r3wp

Better said Gregg.

Wevoften wish people a good morning each morning we see them. Why 
not offer them a longer term good wish too?

Nothing wrong with that.

My host provider no longer support REBOL. So looks like I'm going 
to be changing my host provider

Time for one of the VPS hosts like slicehost or linode?

For several years I've been using REBOL for CGI on sites hosted at 
Lunarpages.  I never asked before trying it, but they've never given 
me any troubles about it.  They have shut down several PERL scripts 
that were in use on the same servers, and they've also emailed me 
about folders with names that they considered potentially suspicious, 
so they are paying attention...

Yeah I ran REBOL in the past with this host which needed to ENABLE 
something before so I thought if I just replaced the binary with 
a new one with same name it would be no problem but it didn't work. 
 So I'm out of luck with them.  I get money back prorated so I'm 
going to switch providers.

Well we put the older version back and REBOL works again.  Does anyone 
else have the linuxx86 2.7.6 working on a server via cgi?

2.62 works but 2.7.6 doesn't work.  Same permissions on file and 
same locations but wouldn't work.

I noticed that I couldn't uncompress the 2.7.6 via the cpanel extract 
function either so i extracted it via my windows box using 3rd party 
tool and uploaded it but it still failed.

Try with 2.7.5 please, want to know if this is a new bug.

I'll check it out but really need the functions in 2.7.6 otherwise 
it does me no good.

I was using the sources at www.rebol.com downloads page.  I'm going 
to try the 2.7.6 from the builds directory.

Yep that one worked.

The one on the rebol.com download page doesn't work.

Excellent that one is now calling Tretbase via CGI and updaing the 
database with the form inputs.

The main download of 2.7.6 core (Libc6, Debian) works fine for me. 
  I've never been able to get any version of View working on Lunarpages 
servers (tried every command line switch listed by "usage") - assume 
it has do with them not having windowing components installed on 
their hosting machines.  BTW, rebpro from sdk-2706042 also works 
(without a key).

That is interesting Nick, I'll keep that in mind should I want to 
utilize some of those features.

not being able to run view on headless servers is why I stick with 
core. around where I am when a machine is large enough to be interesting 
it typicaly is shut up in some climate controled room with a lock 
one the door.

Proof that Joe Marshall did not understand REBOL at all: http://list.cs.brown.edu/pipermail/plt-scheme/2007-June/018753.html

ouch

I like this sentence:   "and it saves the user a lot of work in learning 
your language (*if* he already knows lisp, that is)."

Well Max; it's kinda why I keep asking for junk! data.  REBOL requires 
mere-mortals to understand REBOL datatype! to take full effect of 
the language.  Until REBOL can LOAD "$10,000,000.00"  I'm going to 
gripe every so often.  ;)

Oh, and it doesn't have to load as money!   just not trip on Syntax 
Error: Invalid money -- $10,000,000.00

So close ...  it even knew I was aiming for money!

:)

but brian, you have as much time as you want to get that  $10M  :-)

>> more-time: make time! 10000000
== 2777:46:40

and you know what they say....

time is money   ;-)

lol

Brian: on that one, I'll never understand why you guys don't simply 
use string parsing. REBOL cannot just be able to understand anything.

Isn't Brian saying that he wants a junk! datatype to catch unrecognised 
data instead of R throwing an error?

right, and 1) that can't work 2) you can parse as string, use load/next, 
and use your own parsing when load/next fails.

when you start doing 2) you'll see why it can't be done in a *general* 
way and thus 1)

ie. it needs to be a parser designed for your specific application 
- it's a user interface thing, not a language thing.

if your users don't know rebol, then don't use a dialect as the user 
interface.

And if they're malacious users ... use string parsing

If they are users  ... use string parse ... even genuine users make 
mistakes

>> type? load "$10'000'000'00"
== money!

I want Joe the Plumber to be a home rebol.  REBOL is one step away 
from allowing normal people access.  This hit me when I was showing 
how easy REBOL was to a construction boss.  How they could be masters 
of their own domain.  They lit up like a christmas tree.  A few days 
later a $10,000.00 entry caused one of their little scripts to fail. 
 The lights went out, and instead of embracing becoming a home business 
script writer, they felt stupid, and when I tried to reexplain the 
use of tick versus comma, they just got pissed off and will never 
be budding REBOL home users. 


All of us here could handle 001101010110110110110110010101 and eventually 
get the machine to do what we want.  I'm aiming to open our favourite 
little engine so grandma could use it to write grocery lists and 
then little VID charts etc, etc.   If we keep that to ourselves, 
well, IMHO, REBOL will wallow in the usage numbers counted in hundreds 
not millions as I believe it could.


I could be wrong, but REBOL is too close to being usable by non-programmers 
to let this slip by without at least griping once every 2 months 
or so.  :)


In my little warped world, the REBOL console could be the home users 
"application framework".  Every inch closer to common text usage 
could add an untold number of people by making them feel enabled. 
 Less geek, more people.   Again, I'll admit, I could be wrong; maybe 
the art of scripting will always be for nerds.

I assume that money can't use the comma because of incompatibility 
with parse.

I mean money usesit but load can't because of parse.

'Load can rip you off when it comes to parse:

>> a: load [$10,000]
== [$10.00]

Brian: I am not sure, but what Gabriele might mean is, that such 
change is possible, but could have some consequences ....

The search function is changing a bit.  I'm simplifying the look 
so that it is only two blocks:

db/search [logic][action]


There will no longer be a database block.  Instead a database and 
field will be inputed together such as:

db/search [my-base.field-name > 1][my-base.field-name]


In that example it would check the database called "my-base" and 
check its fieldname which is called simply "field-name" in the example 
above to see if it is greater than the value  of 1.  If it is then 
it returns the field-name value.

doh wrong group

Well, technically the design does allow for more international usage; 
and that IS a good thing, but North Americans use commas.  I'll quiet 
down after this post and then repost to the issue in a few months. 
 I don't know really, but I feel a few small incremental changes 
could open up the field to more people not inclined to be programmers.


On a grander scale, for linguistics work ala Icon's power, being 
able to LOAD %somerandompoem.txt  and not worry about syntax errors 
could open up a whole new domain for REBOL.  That would require a 
junk! datatype, and sure there will be issues with correctness, but 
let the english majors worry about those.  Today they won't even 
bother to start, so there are no issues of correctness as there are 
no scripts.   But imagine some English professor or a theologist; 
LOAD %kingjames.txt and then using REBOL to do statistical analysis, 
right at the console.  A report could count how much non-REBOL data 
was in the books along with counting the times 'Moses was mentioned 
in 2 or 3 simple lines of code.


I'll stop dreaming now (for a awhile) and get back to the task of 
being a nerd.  S'alright.  ;)

Money can't use the comma because of incompatibility with Europe, 
not parse.

Brian, load in Icon is more like READ, and Icon's analysis code is 
very much like REBOL's string parsing.

There is no equivalent to REBOL's block parsing in Icon, because 
code is not data in Icon.

Gabriele: <it needs to be a parser designed for your specific application 
- it's a user interface thing, not a language thing.>
Well said!

Turning raw, external, untested, characters into application-compatible 
data types is not trivial. It's something a language can help with, 
but the language cannot do it all.....especially when you add in 
another important stage: that of giving the user meaningful, context 
sensitive, error mesages if the characters need correcting in specific 
ways.

We don't need LOAD to be relaxed (what a nightmare that would be!), 
we need commonly available library functions for parsing localised, 
sloppy user data. With those library fnctions we can stop the people 
from asking us to break LOAD.