World: r3wp

Can this routine (http://www.rebol.net/article/0281.html) for copying 
large files be used to transfer a file over a network as well?

of course it can

Sounds good. What do I need to change? I'm really not a network expert 
nor a port expert.

because at the moment it only takes file! as argument. Does switching 
to url! is enough?

but maybe not, I'm not sure how it's with the seek

just try to add url! into "from" argument and try it

It depends if the particular server supports resume. My batch-downloader 
manages to do resumes from most FTP sites I have tried.

Is it at rebol.org?

Does it support FTP login?

But FTP might have problems with corporate firewalls, right?

See
http://anton.wildit.net.au/rebol/util/batch-download.r
http://anton.wildit.net.au/rebol/util/demo-batch-download.r

It supports FTP urls. If the url can contain the login details, then 
it should be ok.

Sorry, my first comment above "resumes from most FTP sites" should 
be "HTTP sites". I've not widely tested it with FTP, only with a 
few FTP files Graham was using for his EMR project.

Ok, so it's for HTTP download? That's good! :-)

What would be the best way how to delete for example last 100 lines 
from really large file?

PATH: Looks like a simplyfied find & copy combination to me.

>> ? path
USAGE:
    PATH value selector

DESCRIPTION:
     Path selection.
     PATH is an action value.

ARGUMENTS:
     value -- (Type: any)
     selector -- (Type: any)
>> a: [1 2 3 4 5]
== [1 2 3 4 5]
>> path a 3
>> a
== [1 2]
>> path a 3
>> a
== [1 2]
>> a
== [1 2]
>> head? a
== true
>> head a
== [1 2]
>> a
== [1 2]
>> tail a
== []
>> a
== [1 2]
>> a: [1 a 2 b 3 c 4 d 5 e]
== [1 a 2 b 3 c 4 d 5 e]
>> path a 'd
>> a
== [1 a 2 b 3 c 4 d]
>> a: [1 a 2 b 3 d c 4 d 5 e]
== [1 a 2 b 3 d c 4 d 5 e]
>> path a 'd
>> a
== [1 a 2 b 3 d]
>> a: [1 a 2 b 3 d c 4 d 5 e]
== [1 a 2 b 3 d c 4 d 5 e]
>> path a 't
** Script Error: Invalid path value: t
** Near: path a 't
>> a: [1 a 2 b 3 [d] c 4 d 5 e]
== [1 a 2 b 3 [d] c 4 d 5 e]
>> path a 'd
>> a
== [1 a 2 b 3 [d] c 4 d]
>> path a [d]
>> a
== [1 a 2 b 3 [d]]
>> a: [1 a 2 b 3 [d] c: 4 d 5 e]
== [1 a 2 b 3 [d] c: 4 d 5 e]
>> path a to-set-word 'c
>> a
== [1 a 2 b 3 [d] c:]
>>

I don't thing it's correct behaviour:
>> a: [1 2 3 4 5]
== [1 2 3 4 5]
>> path a 3
>> a
== [1 2]
>> a/3
>> a/4
== 4
>> a/5
== 5
>> length? a
== 5
>> a
== [1 2]

>> type? a/3
== unset!

I think it just corrupts the block somehow

Huh.  Looks like it's marking the end of the block without actually 
removing elements, so that they're still accessible if really needed.

>> A: [a b c d e]
== [a b c d e]
>> path A 3      
>> ? A
A is a block of value: [a b]
>> A/2
== b
>> A/3
>> A/4
== d
>> mold A        
== "[a b]"
>> back tail A
== [e]
>> back back tail A
== [d e]
>> back back back tail A
== []
>> back back back back tail A
== [b]


I can see myself using this...  And I think I'd actually had a problem 
a while back where it would have been helpful.

Im iterating over a lines in a file , with this line in a foreach 
body

if find tempLine "//Database " <> none [ print "Here" print line 
 ]

but the print line is printing [ true; ] instead of the actual line 
?

oh hmm, im splitting by lines with this -> lines: parse (read to-file 
rejoin [ moduleName ".php" ]) "^/" , but it seems to be splitting 
by spaces ?

parse/all

that works, but the find function doesnt seem to be working, the 
two lines it returns for matching //Database are var $new_schema 
= true; and case 'ACL': return true; ---

those are the only two lines that have true in them

use braquets

if (find tempLine "//Database ")  <> none [ print "Here" print line 
 ]

and remove (<> none), it's useless

argh , cant wrap my head around these damn precendence rules

if find tempLine "//Database "  [ print "Here" print line  ]

can you explain why the brackets work ?

because "//Database " <> none is first evaluated

return always true

so, in realty , you do a find templine true

and why is that evaluated first, I thought things were left to right 
?  YOu know where in the manual i can re-read this ?

no

all op! are evaluated first

i don't no for the manual

*know

thx for your help -- the manual desperately needs a search function

CharlesS, if you changed the equation to;

if none <> find tempLine "//Databases" [...] this would also work.

the find in this case would be evaluated first, prior to the op!. 
 Unfortunately I don't know where I read this but I know i've seen 
lots of code where the equation portion of the condition is followed 
by the condition itself  ie, if 2 = 5-3 [do this].  It's backwards 
to what you would expect, but follows with the right to left evaluation 
that occures.

PATH is just not supposed to be used :) it is there by mistake afaik.

it's there so we've got something to fiddle with and don't ask about 
new releases too much ;)

;)

I wonder what is 2.7 good for, as R3 official release is at DevCon, 
and it is less than 3 months? ;-)

i guess people won't start using r3 in production that soon.