World: r3wp

(my brain memory, that is)

Red icons ...usually a problem with syncing when Daylight Saving 
Time goes on or off.

reset-dates.r utility available from RT to correct them (doesn't 
always work).

(Ups, I did not notice the trailing dot. My wrong)

oops, that should be GET-MODES file 'modification-date,  but Sunanda's 
answer is more relevant..

Sunanda - but t hat problem of bad syncing happens only on certain 
systems. Here in CZ for most or all Win versions ... bad timezone 
or something must be the reason. I remember RT stating Win98 returned 
incorrect (shifted) time-stamp under some conditions, but that is 
not only W98 related imo ...

I'll stop promoting IOS here, if that issue is not resolved! I would 
not hesitate to push my client to use some correction script, but 
it does not work always :-( ..... I need proved solution and full 
resync is not that ...

It's a wierd problem, and RT don't seem able to fix it/
reset-dates.r is a sort of symptom suppressant.


I've had to do full reysncs a couple of times.....Not a good thing 
to ask **everyone** to do.

Who thinks that maybe load parser should be mroe relaxed with paths 
? eg:
>> view-root/public/
** Syntax Error: Invalid path -- public/
** Near: (line 1) view-root/public/

The parser doesn't know that VIEW-ROOT is a valid directory name, 
so why should it assume that it's a bad path ?

(Obviously, I know that the error disappears when the final slash 
is removed, but I want the slash there.)

(Also, it helps me make dir-utils commands like:   CD view-root/public/

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)