World: r3wp

When I tried the same with Rebol 2.5.8 which is just sitting on my 
desktop and got 

>> print read %rebol.r

** Access Error: Cannot open /C/Documents and Settings/Peter/Desktop/rebol.r
** Near: print read %rebol.r

Same results with the periods

That's a different issue. Try the bolded code exactly as above.

Ok. So you see the bug too.

Sunanda, are you using NTFS ?

No, just plain FAT

So problem on WinXP/NTFS,  no problem on Win98/FAT. Definitely not 
a problem of rebol. I hesitate to post a RAMBO ticket.

Anton: what "list-dir" give you as result ???

And "what-dir" ???

Just the one file, trust me :)

The bug is shown for any file, not just rebol.r

i can confirm your observation

eg. rebol.exe....

looks like ntfs ignores leading dots

what can you expect from ms...

yeah... trailing you mean. :)
>> exists? %...rebol.r
== false
>> exists? %rebol.r....
== true

has anyone found out the cause for red icons in IOS?

I noticed one entry in RAMBO from Oldes or someone else, describing 
incorrect handling of timezones or something like that ...

but dunno if it is realted or not ....

I think so. Bad timezone found by QUERY (as used by INFO?). Replacement 
is to use GET-MODES file 'modification date.

(from memory)

(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. :-(