World: r3wp

Well, given a function
f: func [code /a /b][print mold second bind? 'a]
do append/only copy code: [f/b] code
--->  [[f/b] none true]

Since I've passed in the code to call the function, it knows how 
it was called, and the order of refinements. The refinements are 
listed in spec order in the function context though.

What's the actual application for this recursive function, by the 
way ?

it's a file packing function. refinements are used to determine which 
files should be skipped and which files should be processed with 
other external functions

And why does it need to be recursive ? Recursing directories ?

I use it in many places for slightly different purposes

yes

ok, so more an abstract general idea.

I think you must pass in the code which is used to launch the function 
as a function argument :)
 no need, pass-args can handle everything

, but a native APPLY handling refinements transparently would definitely 
help

Henrik: why is the refinement order important to you? (since there's 
no way to know it from inside a function)

if you have control over the function, write a (recursive) function 
without refinements and a wrapper with refinements that calls it. 
(this is the best solution)

if you don't have control over the function, Ladislav's pass-args 
or similar techniques are the most general way to solve the problem. 
easier/faster solutions may be available in specific cases.

a native APPLY would solve all of this elegantly... hopefully we'll 
get one :)

aye, I look forward to apply too :)

What does PATH do?

in immortal words of Kurt Cobain "who knows? not me."
and this probably won't help very much:
>> ?? a
a: make object! [
    b: 1
]
>> path a 'b
>> ?? a
a: make object! [
    b: end
]

this is thee end...this is thee end my friend... (but that's another 
song..)

So what does end do?

I don't know. let's continue with the example:
>> type? a/b
== unset!

well, that's my fault, sorry

Don't know what PATH does...
>> x: first [a/b/c/d]
== a/b/c/d
>> y: path x 'b
** Script Error: y needs a value
** Near: y: path x 'b
>> ?? x
x: a/b

hm I'm now lost even in REBOL. back to that terrible Perl/OLE combination 
:/

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