World: r3wp

I would like that too. but a path! is a series, maybe that is tricky? 
but we could set the last element to unset.

Can anyone think of any reason why it shouldn't be allowed ? I can 
only speculate that *maybe* it slows down the interpreter in some 
way, but I don't think so.

it might help with file paths, but what about object paths?  How 
should a typo like system/view/ be handled? or face/text/ ?

Yes... that is the main issue: since a path can be represented as 
a block, how does the trailing slash get indicated in a block?

Since a slash itself is not allowed to be a symbol within a path 
(in other words you can write foo/divide but not foo//) perhaps we 
can simply use a / at the tail of the block to indicate that it has 
a trailing /.  Something to consider.

Not sure about the block thing (examples?), but It think it should 
cause an error only when such a path is evaluated.

I understand the block thing now.

About #3626  Quick PATH-THRU patch to handle CGI query strings

I am not sure anymore. :-/ I think the current implementation is 
the most "perfect" one, and it should be left up to developers to 
patch for particular cases.

Also, for the record, I have mainly reversed my position on "polarity" 
of alpha channel values. (ie. is 255 full transparency or solidity 
?) :-/

I feel guilty, because I argued strongly for it. I mainly changed 
when I realised the mathematical simplicity of it, and learning the 
standard.

I've been thinking that INMOLD might be a good name to rename the 
recently added NEW-LINE to. (I basically want NEW-LINE to be called 
anything else but NEW-LINE). (being a short name, it will also keep 
the Germans happy.) But, not to be lazy, here is what I have in mind:

INMOLD: func [

 format [block!] "internal formatting to apply eg. [newline all skip 
 3]"
	value [block!] "block you would like formatted"
	/local path code
][
	; wrap NEW-LINE
	code: reduce [path: to-path 'new-line 'value true]
	parse format [
		any [
			'remove (poke tail code -1 false)
			| 'newline () ; redundant
			| 'all  (append path 'all)
			| ['skip set n integer!] (append path 'skip append code n)
		]
	]
	do code
]

and a few tests:

blk: [a b c d e f g]

inmold [newline all skip 2] blk  ; -> new-line/all/skip blk true 
2
;== [
;    a b
;    c d
;    e f
;    g
;]

inmold [remove newline all skip 3] blk   ; --> new-line/all/skip 
blk false 3
;== [a
;    b
;    c d
;    e
;    f g
;]
inmold [remove newline all] blk  ; --> new-line/all blk false
;== [a b c d e f g]

Any comments ? Anyone hate the name "INMOLD" ?  I'm just passionate 
about avoiding that confusion NEWLINE <-> NEW-LINE for newbies.

Maybe making the function NEW-LINE a refinement of REMOVE so that 
REMOVE/NEWLINES would remove the newlines?

About #3574 "apply-effect function"

Now that DRAW has been implemented this can be set to "Built" "Tested" 
or "Dismissed" with a Response.

I'll write the refinement to REMOVE and submit it RAMBO if you like 
the idea...

Oh hum... I totally misread that. :-(

I'll just shut up now. ;~>

:) thanks for reading at least :)

Posted a ticket for the "final slash on paths" issue.

Romano, SPLIT-PATH-3:
Probably not really a big problem, but:
split-path-3 http://  ;== [http:/ %/]
split-path-3 http:/   ;== [%./ %http:/]

Probably more of a problem (inconsistant ?):

split-path-3 %""   ;== [%./ %""]    ; <-- better if second item of 
result is none ?
split-path-3 %"/"  ;== [%/ none]
split-path-3 %"."  ;== [%./ none]
split-path-3 %"a" ;== [%./ %a]

DIR?  -  This function, useful as it is, is confusing, because it 
is not obvious that it goes to the filesystem or network to check. 
Perhaps it should be called EXISTS-DIR?

I also feel the lack of a function just to see if a file or url ends 
with a slash. If you work with the filesystem at all you quickly 
find yourself checking for final slashes all the time. Here is my 
latest way of detecting that:
#"/" = pick tail file -1

That sure is ugly to put into code all the time, and I keep wishing 
this is what DIR? would do.

I understand that there is probably a huge body of code that would 
be adversely affected by this renaming, so I am looking for a nice 
short name. So far I thought of DIR-SPEC?  (ie. "does this file have 
the specification of a dir ?") but....

.. it doesn't seem short enough.

Anton, that are the results of standard split-path that i replicated.The 
only difference is in %"" which gives an error on split-path and 
that result on split-path-3. I have some problems on how path are 
splitted by split-path in some cases, but to change them is a problematic 
thing, because all handlers knows how split-path works and get their 
decisions on it. I am not sure that the better result is [%./ none] 
in the %"" example, because the starting path (%"") is a file of 
name "" like in the %"a" example, where the starting path is a file 
of name "a". In the other 2 examples (%/ %.) the starting path is 
a DIR not a file (and the file is "exactly" none).

#"/" = last file ; somehat shorter.

Volker: it fails on %""

ah. did not read enough.. is that a practical problem? maybe %"" 
should be turned to %"./" automatically on parsing?

Romano, you are right. You are fixing rather than changing behaviour.

Anon it is hard to say what the result should be in these cases:
	split-path http:// 
	split-path http:/ 

but usually (i think) split-path is not called directly on url, before 
they are splitted with parse-url or with decode-url.

Yeah, I wouldn't worry about it. This is a minor minor issue for 
me.

Is there anyway to browse tickets in RAMBO?

Being able to browse by Product, Class, Type, etc. would be really 
nice!

Someone posted this to the ML...

I can Encap: [ title 
program 1.0" ]
I gives an error of memory management. is this a bug ?"


I know I ran into this as well but I don't remember what the work 
around is and I can't seem to find it.  This bug doesn't appear to 
be in RAMBO...

I was helping him, but didn't see the same trouble.

that problem should be fixed in the latest sdk betas.

In #3639, Oldes asks for a request-dir, same as request-file. I've 
always wanted these to be implemented in rebol. So I created my own, 
based on scroll-table.

do http://www.lexicon.net/antonr/rebol/util/demo-request-dir.r

(Tested most recently on View 1.2.57.3.1e)

>> do http://www.lexicon.net/antonr/rebol/util/demo-request-dir.r
connecting to: www.lexicon.net
Script: "Demo request-dir" (28-Dec-2003)
Script: "scroll-table style" (7-Mar-2004)
Script: "List Sort Button" (10-Dec-2003)
Script: "header-group" (7-Feb-2004)
connecting to: www.lexicon.net

Include: Couldn't load-thru http://www.lexicon.net/anton/rebol/util/request-dir.r
** Script Error: request-dir has no value
** Near: request-dir/initial %./

The url in the "Include" line is wrong : there is "anton" and upper, 
there is "antonR"

I think Carl posted a REQEUST-DIR to the ml long ago too, didn't 
he?

*REQUEST-DIR

And I have modified it and put back in the library.

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=request-dir.r

DideC, I moved site. You must update. Do this, then try again:

load-thru/update http://www.reboltech.com/index.r[folder "Anton"]

(and sorry about that - one day soon, all this will not be necessary)

(err. [foler "Anton"] is not necessary in the above line, but it 
will still work)

Yes ok, it works now, thanks.
There is not only folders in your request-dir ?!!

eh? what do you mean ? Oh do you mean you can also see files at the 
bottom of the list ? Yes, that is by design. But the directories 
are the only items that are selectable. It always annoyed me not 
to be able to see all the contents of a directory in other directory 
selectors.

About incompatibility between versions of Rebol;  I think Rebol could 
benefit, as I have gleaned from other projects out there, from a 
strict cycle of 1/ feature additions,  2/ bug fixes,  and maybe 3/ 
a final category for "difficult" additions or changes (causing incompatibility 
with prior versions).