World: r3wp

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

is there any other compression which returns a string instead a binary?

You can just form a binary ... to get a string

Mind blank ..anyone got a routine to trim a particular character 
from the end of a string?  I want to remove trailing pipe characters

I could reverse the string and then parse it using a charset .. but 
that seems crude ( any reason why the parse direction can not be 
made an option ? )

That's one of the proposals that hasn't been implemented yet.

Why not use FIND with the charset?

All trailing pipe characters? Do you want to remove any other characters 
other than | ?

>> b: charset [not "|"]
== make bitset! [not bits #{00000000000000000000000000000008}]
>> find/reverse/tail tail "abc|||" b
== "|||"

looks like R3 to me!

I want to remove trailing |

For R2 you might need to complement the charset rather than using 
not.

I didn't know you could use find with a charset

>> b: complement charset "|"
== make bitset! #{
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
}
>> next find/reverse tail "abc|||" b
== "|||"
>> head clear next find/reverse tail "abc|||" b
== "abc"

FIND/reverse/tail doesn't work in R2.

I'll give it a go... ta

So you might need to do a bit of tweaking for the R2 version, but 
it's a start.

is this being backported to R2?

FIND/reverse/tail works in R2, but not with charsets. It's a bug.

as I thought ... no find with charsets

oh ... ooops

FIND works with charsets in R2, but the /tail option doesn't. It's 
a newly discovered (just now) bug.

just now ??

Yeah. By me, just now, while I was doing this experiment.

neat

Thanks :)