World: r4wp

Really glad to hear progress!

Where will you publish it?

Go Cyhpre Go!

Nice.. it was my request :-)

http://issue.cc/r3/2006

Interesting idea. It seems like it would work natrually most of the 
time, but could create subtle issues that have to be explained. e.g.

repeat i j: 100 []
or
repeat i: j: 100 []

I would love to hear Carl give his opinion on it.

I parsed out a username @C\u00E1ssio so what do I need to do to show 
this as Cássio on a web page?

We're missing UDP scheme in R3 http://stackoverflow.com/questions/15700937/how-to-implement-udp-scheme-in-rebol3

It is a great now coming from a great man Cyphre !

*Great  news !

I have an updated SPLIT-PATH, modeled on Ladislav's implementation 
where it holds that

   file = rejoin split-path file


This does not match current REBOL behavior. His version arguably 
makes more sense, but will break code in cases like this:

	%/c/test/test2/ 
	REBOL      == [%/c/test/ %test2/]
	Ladislav's == [%/c/test/test2/ %""]


Ladislav's func only seems to go really wrong in the case of ending 
with a slash an that's the only slash in the value which return an 
empty path and entire filespec as  the target.

Schemes (http://) don't work well either.


REBOL also dirizes the file path if it's %. or %.., which Ladislav's 
does not. e.g.

	[%foo/ %../]  == split-path %foo/..

split-path: func [

 "Returns a block containing a path and target, by splitting a filespec."
	filespec [any-string!]
	/local target
][
	either any [
		; It's a url ending with a slash. This doesn't account for
		; formed URLs. To do that, we would have to search for "://"
		all [slash = last filespec]
		all [url? filespec  slash = last filespec]
		; Only one slash, and it's at the tail.
		all [target: find/tail filespec slash  tail? target]
	][
		reduce [copy filespec  copy %""]
	][
		target: tail filespec
		if slash = last target [decr target]
		target: any [find/reverse/tail target slash  filespec]
		reduce [copy/part filespec target  to file! target]
	]
]

The above matches Ladislav's REJOIN requirement, and handles a couple 
edge cases better. I have about 35 tests here, if people want to 
see them for discussion.

It leaves open the question of what the best results are in cases 
where the target is a dir. Should it be part of the path, returning 
no target? Should it be the target? Should it be the target if there 
is no traliing slash, but if there is a trailing slash it should 
be part of the path?

And could/should it be generalized by adding a /WITH option to specify 
a path delimiter other than slash?

Well, it really is worth it to find out what the preferences are 
and whether people like the "invariant" I proposed.

why not use %.  as the last element of splitpath in case of a directory?
true = dir? %.

It makes sense to me Anton. I don't know why SPLIT-PATH does what 
it does today, by automatically dirizing that result. If everyone 
agrees, then the next question is whether a trailing %. or %.. should 
be returned as part of the path, or as the target. That is, do we 
presume that they are directories?


SPLIT-PATH, today, returns the last dir in the path as the target, 
if the path ends in a dir. Here are some example values, and what 
SPLIT-PATH returns today.

;	%/c/test/test2/ [%/c/test/ %test2/]
;	%/c/test/test2  [%/c/test/ %test2]
;	%/c/test        [%/c/ %test]
;	%//test         [%// %test]
;	%/test          [%/ %test]
;	%/c/            [%/ %c/]
;	%/              [%/ (none)]
;	%//             [%/ %/]
;	%.              [%./ (none)]
;	%./             [%./ (none)]
;	%./.            [%./ %./]
;	%..             [%../ (none)]
;	%../            [%../ (none)]
;	%../..          [%../ %../]
;	%../../test     [%../../ %test]
;	%foo/..         [%foo/ %../]
;	%foo/.          [%foo/ %./]
;	%foo/../.       [%foo/../ %./]
;	%foo/../bar     [%foo/../ %bar]
;	%foo/./bar      [%foo/./ %bar]

To me, it's a matter of whether SPLIT-PATH should be consistent in 
how it handles the path, as a string to process, or whether it should 
try to be "helpful". The problem with being helpful is that it may 
make other things harder.

By saying that SPLIT-PATH always behaves the same way, depending 
on whether the path ends with a slash or not, it may not shortcut 
a few cases for us, but it does make it easy to reason about, and 
also to wrap for other behavior. e.g., you can always dirize the 
path before calling it.

One test missing in your collection:
%foo [%./ %foo]

Also:
%"" [%./ %""]

Thanks Andreas!

after thinking again, I would perfer %./ as the last part of the 
result of split-path, as it has a trailing slash and it  is still 
the samel

if the argument was a directory

What do you mean, if the arg was a directory? Can you give an example 
each way?

split-path %test/ should give [%test/ %./]

Why would that return anything for the target? That is, why not  
[%test/ %""]

%"" looks strange, even if its allowed. %./ has a trailing slash, 
if someone wants to test for that

I think I would prefer split-path so split into the last non-slash 
component (target), and the original path with that last non-slash 
component removed.

Anton, but then you could never get an empty target, and you would 
have to compare to %./ as your empty value.

And then make sure that wasn't the end of the original path.

Andreas, can you give examples, to make sure I'm clear?

Would behave mostly as the current split-path does.

(For the common cases.)

So this is OK for you: %/c/test/test2/ [%/c/test/ %test2/]

Yes, that's what I'd expect.

I'd also prefer a stronger invariant, as REJOIN is relatively weak 
for joining path components.

Something more along the lines of

set [d b] split-path f
f = d/:b

what do you mean with an empty target?  %./ just means the target 
is a directory, the actual directory

OK, using that as a quality test, here's where the current SPLIT-PATH 
fails:
Path quality failed: %/ %/none
Path quality failed: %// %/
Path quality failed: %. %./none
Path quality failed: %./ %./none
Path quality failed: %./. %././
Path quality failed: %.. %../none
Path quality failed: %../ %../none
Path quality failed: %../.. %../../
Path quality failed: %foo/.. %foo/../
Path quality failed: %foo/. %foo/./
Path quality failed: %foo/../. %foo/.././
Path quality failed: http:// http:/
Path quality failed: http://..http://../
Path quality failed: http://.http://./
Path quality failed: http://../.http://.././

And here's where my proposed SPLIT-PATH fails:
Path quality failed: %. %/.
Path quality failed: %.. %/..

%. is tricky :)

Anton, which is the behavior question. Do you expect SPLIT-PATH to 
return a target you can write to (i.e. a file)?

Here's a few example values and what I would expect: 

http://sprunge.us/AaDJ


Where there is a third column, current R3 split-path differs from 
what I'd expect, and the third column is what split-path returns 
currently.

Great! Since I haven't had coffee yet, the second column is *always* 
what you expect, correct?

Yes.

Got it.

But with a "path component"-based invariant, the %. %.. and %/ cases 
will require more work to reconcile.


With a "string"-based invariant (rejoin), those cases could more 
easily be described with the neutral %"" element: