World: r3wp

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 :)

thanks for the input.  I'll see what I can do.

how to prevent binary data from spanning multiple lines?

this

 #{
    3A
    18
    92
    56
}

should be this

#{3A189256}

is this possible?

Afaik, binaries don't keep the info about how they were laid out 
on the page like blocks do. The whitespace won't be preserved when 
they are printed out. And there is no whitespace internally in the 
binary, just binary data.

according to the above example I would like to store the binary via 
a tcp.

any other possibility to transform the binary? while  using enbase 
I have 
also todo a dehex after retrieving. would like to avoid this.

the best would be if I could store just 3A189256 and then reform 
ist back to a binary.
is this in general possible brian?

tombon, the binary is not spanning mulitiple lines .. that's just 
 a display issue?

unforunatly not. when I compose the value pairs to transmit there 
occur a crlf within. so the key/value just store #{

for example:

the store sequence is this

{key^-1
value^-#{
789CCBCA2E4EC9485348CC2ECE82D059C53960460E9005666465E74018C559D9
296919501A48A50000B5BE16913C000000
}

to lines separated by a tab for the key/value