World: r3wp

eeek!

I make a habit of testing R2 bugs in R3 as well.

I think i've seen this bug before too ....

I have to work around it in my database system.

I'm trying to rename a few 100 directories to conform to a naming 
scheme

It's annoying having to work round this .. and also that rename doesn't 
work except in the current directory.

yes, it's quite annoying

I've been telling my clients for years not to install REBOL applications 
in folders that have a space in the name -- like "program files/rebol"
It just creates too many problems.

My virtual filesystem (in QM) simply doesn't allow them.  Same reason 
-- too many problems...

what problems?

I use them all the time.

There are three ways to handle such directories that I'm aware of:

you can use the short directory format:

change-dir %/c/progra~1/

you can use the long directory format:

change-dir %/c/program files/

or you can just use the native format:

change-dir to-rebol-file "c:/program files/"

If you want to the know the short format for a directory just use 
the dir/x command from the command prompt.

All three of which are a pain.

(one is platform dependent)

Pain as compared to what?

Not dealing with spaces.

option 1 above is even better than that.

And is limited to Windows.

All I'm saying is that if you make the assumption that none of your 
filenames have spaces (where you have such control), then it removes 
some of the pain of having to deal with them.

I'm not saying there aren't workarounds (which you need particularly 
if you don't control the filespace)

there are also problems with using non-english characters at times. 
it backfires when you type a directory name in a macOSX script that 
makes a directory on a windows machine. results in chaos, because 
the dir name is read differently depending on the platform and whether 
you are reading it across the network.

Yeah Chris, I guess it depends on what your going.  For example, 
if you collecting directory information and must parse thru it then 
the spaces are obviously a pain.

Does read/direct/skip not work?  It always starts at the beginning 
of the file.  read/skip works, but with the direct it doesn't seem 
to.

It's been a longstanding problem, Tim.

These two blog posts discuss it and a solution. I do not know if 
the solution has been implemented:
http://www.rebol.com/article/0198.html

http://www.rebol.com/article/0199.html

thanks!

i have about 50,000 word strings in a single block.  I would like 
to do a find/any wordsblock "sear?ch*" ;on it but no go - am i missing 
some fundamental feature of Core or is this broken?

i was expecting it to return the index of the first found match within 
the block

example:
a: ["one" "two" "once" "twice" "three" "thrice"]
find/any a "on*"

isn't there an /only refinement?

doesnt work

I guess this is where the fabled find/deep would come in.

lol deep in a 1 level block :P

just checked R3.. doesnt work there either :(

I know :-) I guess you have to wonder what result you want back, 
because it has to search each string in the block. what you are looking 
for is a find on each string in the block and what if that is not 
found in the beginning? Does it return two indexes, one for the string 
and one for the block? That's where /deep comes in.

first find -  returns succesful index

as normal find works

yeah, but find doesn't know that

perhaps it's simpler to parse the string

too slow with 50,000+ words and pattern matching?

ill probably just use C# and use regex :)

deep-find: func [blk str] [repeat i length? blk [all [find/any blk/:i 
str break/return at blk i]]]

could probably be sped up with while or until

or by length matching wildcard pattern

because once i use the full 300,000+ word dictionary its gonna need 
to be fast :)

it helps if you are searching a hash

wildcard searching a hash is rather messy tho isnt it?

I've not tried it, but find should be much faster in hashes.

are you always searching from the beginning of the string?