World: r3wp

or you own unreleased version?

same version as used on the detective and published on my site

Ok.

what would be the best way how to legalize urls like this one http://maps.google.com/mapfiles//cb/blue_outlines.png

I mean rebol-file from such a url

hm.. parse t: "a//bb/c" [any [to "/" p1: some "/" p2: (p1: change/part 
p1 "/" p2) :p1] to end] t

You mean, to "clean" it, into a legal url ?

http://anton.wildit.net.au/rebol/freezer/simple-clean-path.r

yes... that's what I wanted.. especially to make the local file secure 
as well... (so converting url to local file does not leave the send-box:)

I already had own version, but your is a little bit better as correctly 
handles complete url... my was only for the path

This is one reason I wrote my files:// protocol -- http://www.ross-gill.com/r/sandbox.html
(need to add to the library).

we also had a secure-clean-path....

Ah.. secure-clean-path should be in rebol.org already.

do func [a b /c] [either c [a + b][a * b]] 2 3

How do I invoke the refinement?

or perhaps:

f. func [a b /c] [either c [a + b][a * b]] 2 3

do :f 2 3 ; <--- here?

Think I figured it out...

nope, didn't work. I need the function in a composed block:


compose [do (:f/c) 2 3] ; causes error, since arguments are not inside 
the compose parantheses.

But the arguments are not used, so:

compose [do (:f/c 2 3)]


But now the arguments are local to the function. The arguments come 
from a different context, so I can't just compose the get-word'ed 
function with the arguments.


So I'll go back to the first question on how to make a refinement 
on an inline function?

why use the refinement in a throwaway function?

the function is rather complex and must be used many times, so I 
wrote it outside the block.

the block is a database query on a remote machine

and the function helps me to find out whether certain conditions 
for a database entry is true or false

Didn't Maarten use refinements in rugby?

hmm, since you're composing, why not put a path there?

otherwise... do 'f/c 2 3 should work.

>> f: func [a b /c] [either c [a + b][a * b]]
>> do 'f/c 2 3
== 5
>> do 'f 2 3
== 6

gabriele, what if the function is local, but must be used remotely 
(security is unimportant right now)

That is a good question, Henrik.

what is wrong with an extra assignment?
f:  func [a b /c] [either c [a + b][a * b]]]    f/c 1 2

do (f: func [a b /c] [either c [a + b][a * b]] 'f/c) 2 3

or a wrapper, an 'f-without-c and 'f-with-c.

volker, can't check right now if that works, but does it pack the 
entire function inside the block?

inside the parens

and then returns a path with a refinement. 'do gets the path, done.

You can put a 'use around it to avoid the temp

But not really sure what you want to do. somehow sending a function 
i guess.

well... if it's to be automatically called etc., i'd suggest avoiding 
refinements as much as possible. just use a logic arg.

if you really have to use refinements, you have to compose a path, 
no other way around in r2. (you see, that's why we've been asking 
for a low level apply native for so much time)

I see, thanks

After dealing with strings for so many years with various languages, 
I would say that TRIM should be default with any reading/writing 
functions, and when you don't want something trimmed then use a function.

a: "  my untrimmed string   "
write no-trim a

That doesn't make any sense to me as I hardly ever use trim.

In the case where TRIM is embedded into some functionality, disabling 
it becomes an exercise of varying difficulty.

eg. VID's TEXT style trims text automatically, unless you specify 
AS-IS. Discovering where this happens takes a little while.

I second Anton's statement... adding TRIM is EXTREMELY damaging to 
data.  100% of work I have done in the last year implementing transactional 
ticketing web services 100% implemented in REBOL would have been 
simply nightmarish if such data destruction would have occured.

just handling the ports is finicky enough!

as an example, I NEVER use parse without the /all refinement... its 
just so damaging... lengths become all screwed up and trying to separate 
clearly your tokens in the input strings becomes much harder.

Everyone has different needs. I can see the argument for auto-trimming, 
but neither behavior is clearly "better" IMO. In this case, I would 
vote not to auto-trim.

some things cannot be "undone" and such behavior unless it is switcheable 
is dangerous... I've had many problems with memory useage since Carl 
switch the object model so that it copies all series at each new 
instance... the old way was simple to copy... but now, its almost 
impossible to share data amongst peer instances. 


I know why he did it... but I think more explicit documentation where 
the feature was causing some unexpected effects for newbies would 
have been a better solution. and we still have many of the string 
sharing side effects in View anyways... so it didn't explicitely 
fix the main issue in the first place!

Agreed. Things that can' be undone are problematic.

so its a bit like the pre-reduce on apply debate... it can't be undone 
(unless a switch exists, then its ok)  in this case, that is what 
/only usually stands for.

I would call some person's submitted password with inadvertant whitespace 
as 'destructive' .. besides, there would be no 'data destruction' 
if you used no-trim, would there? As Gregg put it, everyone has different 
needs.  If you measured the trimming of strings vs not, I would imagine 
more are trimmed.

terry, it's not possible to implement a no-trim function.

what is the difference between copy and copy/deep?  I cannot seem 
to find any simple examples...