World: r3wp

Ok, submitted a ticket.

short hand, yes.but also,  not blocked by security. since  you can 
only launch rebol-scripts.

I also recall reading that a launched script cannot launch a script 
of its own.  something about preventing scripts from the desktop 
to launch other scripts, as a security measure, IIRC.

That restriction was removed fairly recently (about a year ago ?).

eeek... make date allows 0 values !

>> make date! [0 0 0]
== 30-Nov-65535
>> make date! [0 0 1]
== 30-Nov-0000
>> make date! [75 0 1]
== 13-Feb-0001
>> make date! [01 0 75]
== 1-Dec-0074


sorry, but these make dates are just funny. 0 becomes a negative 
offset in time in some instances... like the last.  should I RAMBO 
this?  I would expect make date to accept only one 0 value, being 
the year... any other 0 makes no sense.

btw, I looked and didn't find this strange behaviour being notified 
on RAMBO...

Negative offsets can actually be very useful, when creating relative 
dates. The thing I don't like about the zero behavior is that it's 
non-intuitive. i.e. using zero produces a negative result, where 
you would think -1 would be what you want to use. Other than that, 
it's just something to be aware of, not a bug IMO.

Reading existing http url returns just empty string if exists? function 
is called on non existing url before - Rebol/View (1.3.2.3.1) Is 
this know bug?

>> system/version
== 1.3.2.3.1
>> exists? http://www.rebol.com/donwload/rebol3.exe
connecting to: www.rebol.com
== false
>> print read http://www.rebol.com/
connecting to: www.rebol.com

>>

oh.... you've just stumbled on something which might be related to 
something I  discovered last week on command!


but strangely, this is new behaviour for me... so it might be related 
to server swap. and the fact that now, an URL does not exist anymore! 
 you might just have resolved a clueless issue.  especially since 
the exists? command seemed to work on new console issues.  


I will make other tests and confirm is I just discovered the same 
bug than you!

(ignore "issues"  word above)

it's already fixed: http://www.rebol.net/cgi-bin/rambo.r?id=4039&

but btw... in my bug (which might or not be the same) it does not 
only corrupt the http protocol... the whole exists? cmd is down, 
since I am testing files in my case!

have you tried the same thing in 2.7?

Oldes, you're a year late with that bug report :)

Ok... now I don't know, what is worst - if I'm late or the fix is 
late?

Isn't it fixed??

I think he meant... its not in 1.3.2 release

well, it's likely to be a mezzanine .. ?

exists? is, we'd have to look closer to see if this can be applied... 
the port stuff itself is not always trivial to patch...

the fix for that is what "caused" the read/binary bug in 2.7. (rather 
than "caused", it exposed a native bug when calling handler functions.)

Regarding #3867 "feel/detect event/face should be target face, not 
face" 
http://www.rebol.net/cgi-bin/rambo.r?id=3867

I realised when mimicking the behaviour of DO EVENT, that the reason 
the target face is not given is because its impossible to know at 
the time DETECT is called. Events travel down through the face hierarchy 
through the DETECT functions, the evaluation of which could have 
an effect on the result. The DETECT function can block events or 
allow them through, depending on the result they return, which is 
programmable and therefore dynamic. So a DETECT function higher up 
in the face hierarchy which is evaluated before a DETECT lower in 
the face hierarchy cannot know which is the target-face, because 
the result of the lower DETECT may change the target-face.

Therefore, I now see this as either a major design issue or a documentation 
error requiring some clarification. I don't think it is likely to 
be implemented (not in R2, anyway) because that would probably require 
an overhaul of the event system, and would likely break a lot of 
stuff.

The question is: do we want determinism or dynamism in this case 
? :-/

I think we don't want to lose dynamism.

In most cases it is sufficient to know which face is under the mouse 
cursor at the time of the detect event. Coded as a mezz this is pretty 
slow.

seems the spam bots have figured out how to submit "bugreports"...

Yeah they figured that out long ago... RT have been filtering them 
manually I think.

why dont RT add a captcha?  ... it easy with rebol and the draw command.

A guess: the web site is probably running a /core version -- /view 
versions used to not work well in CGI environments (though that may 
have changed).
/core has no draw ability.

A math based captcha doesn't require draw

Or, the images could be pre-generated

doesn't core support the draw native?  which can draw directly on 
an image datatype.

Or the form inserted using javascript

(at least the submit button)

i've just been in bed with a flu for the last few days, so noone 
has been deleting spam :)

Wouldn't it be a little easier to add a captcha to the script ?

Or, even simpler, just add my smtp challenge script to validate the 
email address?

I think, that email validation is so often required that every bot 
must know how to fill field named EMAIL

I really don't know, why everybody must be forced to rewrite some 
letters or do basic math only because of a few idiots. Just block 
their IPs or give the captcha only to some of these IP ranges (if 
you think, that there still can be someone innocent). That's what 
I would do.

how can you possibly be sure that the IP does not contain a zombie 
spam bot that posts to the site as well as real posters?

that's why I say - give the captchas only to users from these IPs

why should gabriele be forced out of his sick bed to delete spam?

better to have a captcha test

spammers use proxies so you can't always block their ip address

or, use zombie pcs

so insert the submit tag using javascript

and use chickenscript to automate javascript