World: r3wp

R2 needed some heroics for other collating sequences. Not tried this 
sort of thing in R3 yet.
   http://www.rebol.org/ml-display-message.r?m=rmlMWWJ

Argh! Does one remember how to convert integer! to its binary equivalent 
and the opposite, in R2 and in R3 (it's different IIRC) ?

R2 way is to use to-hex
    to-hex 100
    == #00000064

Yes, but issue! are not binary!

I need to make some binary mask with some integer value like :
	var: random 99999999
	res: var and #{00ff0000}

OK. Find a solution.

to-integer #{00ff0000} give me an integer, so I will make some "constant" 
values from the binary I need and will make the AND between integers.

>> to integer! binary: debase/base to-hex integer: 11 16
== 11

(not very convenient, I admit)

LoL

In R3 is is much more comfortable

Another option:

>> do http://www.fys.ku.dk/~niclasen/rebol/libs/bit.r
>> enhex 100 
== #{00000064}

I want to block all of eastern europe ( sorry guys ) from my sites 
...

now vbulletin only allows blocking by ip address eg. 1.2.3.*
but the country blocks appear like this 

# Country: RUSSIAN FEDERATION
# ISO Code: RU
# Total Networks: 4,256
# Total Subnets:  35,139,848
2.60.0.0/255.252.0.0
2.92.0.0/255.252.0.0
31.28.0.0/255.255.224.0
46.0.0.0/255.255.0.0
46.3.0.0/255.255.0.0

is there some code I can use to transform the bottom into the top?

should I just simply replace the first occurence of a 0 on the left 
with a * ?

depends on the accuracy you need

I don't need accuracy!

I just to block every spammer that lives in Eastern Europe

then replace every non-255 occurence with * :)

eh?

2.60.0.0 => * ??

from the mask :)

this will match several million false positives too, but well :)

vbulletin doesn't use masks

ok, so where there isn't a 255 in the mask, then replace the same 
point in the ip address with a *

2.60.0.0/255.252.0.0 is 2.60.0.0/22

2.60.*.* will match less than 2.60.0.0/22

2.*.*.* will match more than 2.60.0.0/22

well, I think I would use 2.*

will that stop Putin posting?

blocking several gazillion non-eastern europe users as well :)

collaterall damage

Rebol []

data: {# Country: AFGHANISTAN
# ISO Code: AF
# Total Networks: 22
# Total Subnets:  98,560
27.116.56.0 - 27.116.59.255
58.147.128.0 - 58.147.159.255
61.5.192.0 - 61.5.207.255
111.125.152.0 - 111.125.159.255
111.223.244.0 - 111.223.247.255
117.55.192.0 - 117.55.207.255
117.104.224.0 - 117.104.231.255
119.59.80.0 - 119.59.87.255
121.100.48.0 - 121.100.55.255
121.127.32.0 - 121.127.63.255
124.199.112.0 - 124.199.127.255
125.213.192.0 - 125.213.223.255
175.106.32.0 - 175.106.63.255
180.94.64.0 - 180.94.95.255
180.222.136.0 - 180.222.143.255
182.50.176.0 - 182.50.191.255
202.56.176.0 - 202.56.191.255
202.86.16.0 - 202.86.31.255
203.174.27.0 - 203.174.27.255
203.215.32.0 - 203.215.47.255
210.80.0.0 - 210.80.31.255
210.80.32.0 - 210.80.63.255
}

output: copy ""

foreach line parse/all data "^/" [
	if line [
		trim/head/tail line
		if not find/part line "#" 1 [
			ranges: parse/all line "-"
			from-ip: load trim/head/tail ranges/1
			to-ip: load trim/head/tail ranges/2
			; they diverge on the 3rd number
			from: from-ip/3
			to: to-ip/3
			for i from to 1 [

    append output rejoin ["" from-ip/1 "." from-ip/2 "." i ".*^/"]
			]
		]
	]
]

print output

gives ...

27.116.56.*
27.116.57.*
27.116.58.*
27.116.59.*
58.147.128.*
58.147.129.*
58.147.130.*
58.147.131.*
58.147.132.*
58.147.133.*
58.147.134.*
58.147.135.*

etc ..
Does that look okay?

looks ok :)

maybe someone has CIDR enumeration code already lying around :)

8000 lines of IP ranges

going to be a big file!

oops .. 3Mb file of ip addresses to block

the VID editor just died on that

222,000 lines of addresses

let's hope vbulletin doesn't choke

-> ~Chit Chat

Does anyone know why modifeid? and info? return a date without the 
time when accessing a file through ftp lon a windows ftp server? 
 Is this a limitation of windows, the ftp scheme, the ftp server, 
or the version of Rebol (I'm using the latest 2.7 - activated ODBC 
connection all dll access)?  Are there any known fixes to this - 
a quick google didn't find anything?

ecall there is a ftp update out there, does anyone know if that fixes 
this limiation?

it should return the time, I've got ftp synching routines which use 
info? and use date/time.   so I'd bet its a limitation on the server, 
or its using a non-standard date string in its LIST command.

Okay, I'll see if our server admin can change something that will 
help.  Using Romano's FTP-Patch.r shows the date for files, but there 
is some code in place to get it to work from what I can tell.

You might also try connecting with the FTP server with a command 
line client like NcFTP and looking at the listings directly.

or just modify the existing ftp client ... the formatting is a parse 
rule

ftp protocol ...

I meant, look at the listings directly, so you know what to look 
for when modifying that parse rule :)