World: r3wp

Never mind, it is just the comments that are wrong. The AS-STRING 
is legit, but related to the general design flaws in R2's binaries 
that are fixed in R3.

>> within? 0x0 0x0 2x2
== true
>> within? 0x0 0x0 0x0
== false

It's a zero sized box, right?

No point can be in a zero sized box.

So those results look fine to me.

the 0x0 point occupies all points of the box simultaneously :)

methinks that within? should take, integers, pairs and triplets


so integers for a one dimension, pairs for two dimensions and triplets 
for 3D

and maybe take an optional function if you want to supply a sphere 
or other volume

We don't have triplets. And the source of within is simple enough 
(on purpose, because of performance issues) that any optional function 
should be separate.

Anton, points have zero size. A zero-size rectangle could contain 
in theory one point. The question is whether WITHIN? is inclusive 
of that last point or not.

However, WITHIN? isn't for points, it's for pixels, and pixels have 
area. Which is I guess why that point isn't included.

tuple

tuple is 8-bit only. I think WITHIN? looks ok.

triplets then!

(sorry, I did actually mean pixel)

(I figured as much, but felt that the distinction was worth mentioning)

Should this be considered a bug? (R2)

>> b: reduce [:print :insert :read :+]  
== [native action native op]
>> find b :print
== none
>> find b :insert
== [action native op]
>> find b :+
== [op]
>> find b :read
== none
>> :print = :print
== true
>> :print = :read
== false

So FIND cannot locate native! types by direct comparison.

Looks like a bug to me !  I confirm the above behaviour with my testing 
on View 2.7.6.4.2 on Linux.

(FIND can locate native! datatypes, however, so that's working ok.)
>> find b native!
== [native action native op]
>> find next b native!
== [native op]

FAST ?

k: enbase checksum/secure to-string now/precise

k: enbase checksum/secure to-string now/precise
k': enbase checksum/secure to-string now/precise
Give same return !!!
better include wait .1 between !

A useful warning not to use current time as a unique key :-)


A wait of .001 is sufficient to get me different times -- but that 
may be processor and operating system dependent.

This code may help in exploring your limits:

n: 0
forever [
   n: n + 1
   k: enbase checksum/secure to-string now/precise
   wait .001
   k': enbase checksum/secure to-string now/precise
   if k = k' [print n halt]
]

better hint fo a unique key ? (meet rebol a week ago)

Never use current time as key generator. Win98 uses about 0.01 second 
timer resolution, which slapped me in the face a few years ago. Other 
OS'es may be similar.

elenay, should be enough to apply random to the binary.

true, clever, but we never knows. don't you ? I do :-)

As Henrik says, this code _probably_ returns unique ids:
n: 0
forever [
   n: n + 1
   k:  random/secure enbase checksum/secure to-string now/precise
   k': random/secure enbase checksum/secure to-string now/precise
   if k = k' [print n halt]
]


But for best results, add in something more:
-- a count?
-- user name / IP address?

a count would be useful

join the previous k

n reach 2 000 000, did not halt by itself. 

I take it like this, with mentions for responsability should be directed 
to you Sunanda ;-)
Thanks

That leaves you three basic options:)

That leaves you three basic options:)

(opps -- my enter key got reset somehow)
1. hire me at a reasonable rate as your official scapegoat

2. make yourself potentially a billion times safer (so no need for 
a scapegoat) by adding something to the checksum string -- eg:

    k:  rejoin [random/secure enbase checksum/secure to-string now/precise 
    random/secure 100'000'000]
3. read up on UUID / GUID generation, eg:
    http://www.rebol.org/ml-display-thread.r?m=rmlCYYK

sunanda, for your timing issue in generating unique keys, use my 
precise time module it NEVER returns the same time twice, the counter 
is CPu based.

i usually use a random string generated on app startup, the time 
and a random value at each call.  

purists will tell you not to use the system time for the random seed 
.  it creates a time frame of attack which vastly reduces the number 
of hits required for brute force attacks.  


use two independent system data values like disk free size, & a measured 
I/O divided by each other.   a single digit off generates a completely 
different seed, so its much better and cannot be guestimaged easily 
by the attacker.

I just ask the user to think of a number

This is what I often use:

>> random/seed now
>> enbase checksum/secure random mold system/error     
== "EZHHHYzUpj78+Eab+Y8vygt75ZA="

Of course, if you are running on a real operating system, you can 
get better "randomness" using:

>> p: open/binary/direct %/dev/urandom
>> enbase copy/part p 16
== "2Fm5zVhMBCgQkdQ3afEpYw=="
>> enbase copy/part p 32
== "Ymk3t6HyAgKNzpALcvGSXyV6poSDwRzk5pCR7IoDz68="
>> close p

I'm a newbie to Rebol. I need to know how to delete a file on my 
website. I tried uploading a file using:

write ftp://user:[pass-:-website-:-com]/myfile.enc myfile.enc


which does not work because of the ['-:-'] in the user name. I tried 
replacing the ['-:-'] with '%40', still did not work. So I tried the 
following which works:

ftp-port: [
	scheme: 'ftp
	host: "ftp.mysite.org"
	port-id: 21
	user: "[user-:-mysite-:-org]"
	pass: "xxxxxxxxxxxxx"
	target: %myfile.enc
]
file: read %myfile.enc
write/binary ftp-port file


So now my file is on my server. My question is - How do I delete 
this file? I see no way to tell the Delete command the name of the 
file on my server so it can delete it. And:

delete ftp://user:[pass-:-website-:-com]/myfile.enc


does not work for the same reason the standard velsion of write does 
not work, because of the ['-:-'] in the user name. Any help much appreciated.

delete [
	scheme: 'ftp
	host: "ftp.mysite.org"
	port-id: 21
	user: "[user-:-mysite-:-org]"
	pass: "xxxxxxxxxxxxx"
	target: %myfile.enc
]

does that work?

No, delete does not take a file spec

I just found that out.

Try this http://rebol.wik.is/Protocols/Ftp

See the file attached at the bottom

do %prot-ftp.r

then, do this

delete ftp://user%2540mysite.org:[pass-:-ftp-:-mysite-:-org]/myfile.enc

Hold the guimauve

I had to type that all out very slowly and carefully, long password, 
and I don't use the shell much these days (I'm an old Amigan). YES 
it worked! Thanks Graham. I'll add the guimauve, they do look delicious. 
Help me out much more and end up delivering a feast.


So I imagine I need to include prot-ftp.r in my Rebol programs and 
I'll be able to use the standard way of accessing files on my server? 
Am I right?

Thanks for all the help, this will get me going now.

I had an Amiga 1000 bought in 1985 ... always used the shell there 
:)

Yep, those were the days :) My Amiga 4000 finally died in 2002. That's 
when I switched to linux. No more Amiga :(

You can try this .... instead of loading up the ftp protocol, 


 system/schemes/ftp/handler/open-check: [none ["220" "230"] ["USER" 
 dehex port/user] "331" ["PASS" port/pass] "230" "SYST" "*"]

ie. patch the scheme in memory