World: r3wp

enface => word!

rebview and enface are both 2.7.6.3.1

Should I RAMBO that ? Is RAMBO still used ?

RAMBO is still used for R2 bugs, yes.

It sounds like the preprocessing is loading and molding the code 
before encapping, without using mold/all.

I think this might be in RAMBO already. At least I remember mentioning 
this problem to Carl a few years back. As Brian says, it's a missing 
/ALL refinement.

About the spam, I clean that up every single day. What you see is 
one day worth of spam.

is it all human spam?  or bot spam?

can you add a rebol captcha to it  to save you work?

given that there is not much protection in rambo, it's probably bot 
spam.

the main thing is, that changing rambo (i don't know the code) would 
take me more time (especially testing and making sure we're not going 
to lose data) than the 20 seconds or so it takes to delete the spam. 
So I never get to study the code and see what can be done...

I verified this same bug today http://www.rebol.net/cgi-bin/rambo.r?id=3357&
 The workaround is to use /binary and then the limit is gone.

I've searched RAMBO about a WAIT inconsistency : the dictionnary 
says that "If the value is a DATE/TIME, wait until that DATE/TIME", 
but date! are not accepted as argument (both directly or in a block). 
If this a known bug? I can't find it in RAMBO.

doesn't it mean a time value?

It's probably a documentation issue.

Being able to wait for specified date/time would be great for doing 
cron

Precisely, I'm working on a scheduler lib for UniServe and I was 
wondering if I could wait for date!, but it looks like not.

would be good feature to have at least in R3 ...

good idea. create a curecode wish for it, please.

You can't wait on date! AFAIK.

wait-date: func [date [date!]][wait difference date now]

always someone to prove another wrong...  ;-)

An excellent solution, but you still can't wait on a date!. :-)

I agree, that it should be supported directly, so is there the ticket 
already?

what happens if someone changes the clock while you're waiting on 
a date! ?

what should?

What happens if someone changes the machine's clock while you wating 
for a length of time ?

you -> you're

graham, the only solution to that would be to wait, say, 10 seconds 
at a time, and check. but it really depends on the application...

re; wait till time, isn't that       add multiply subtract then/date 
now/date 86400 subtract then/time now/time


then - now * seconds per day + delta hours?   Negative time! possible, 
which it seems wait takes as zero anyway.

btiffin, just use difference now then

(or difference now/precise then if necessary)

Thanks Gabriele;  I knew there was a more concise method of getting 
at time!  from date arithmetic, but I got sidetracked when the google 
search wanted to show me COBOL data arithmetic.   ;)  Can't ever 
know enough COBOL, err, aaah, REBOL.

This hangs.

in R3

This?

p: make op! [[n m] [n * m]]   3 p 4

Wrong group, but good to know. MAKE op! clearly needs to do more 
parameter checking. CureCode it.

There's no reason to expect that to work, btw. An error should be 
thrown by MAKE.

why?

Because ops aren't mezzanines - they redirect to other functions.

if not divisible-by-any? n primes
if n is-not-divisible-by-any primes

if they could be made we could use this kind of grammar

There is no known spec argument for MAKE op! that is supposed work. 
You're spposed to use the OP function.

User-defined ops are a planned feature, not a currently working feature.

Thanks

How many people are in here?

It's not a bad idea though. Still, CureCode that code you posted 
above. It's a serious bug that MAKE doesn't trigger an error there.

Anybody knows what's this about?

http://www.rebol.net/cgi-bin/rambo.r?id=-4786&

Well, I do not think so...