r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Graham
23-Jul-2008
[10787]
eeek!
Henrik
23-Jul-2008
[10788]
I make a habit of testing R2 bugs in R3 as well.
Graham
23-Jul-2008
[10789]
I think i've seen this bug before too ....
Henrik
23-Jul-2008
[10790]
I have to work around it in my database system.
Graham
23-Jul-2008
[10791x2]
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.
Henrik
23-Jul-2008
[10793]
yes, it's quite annoying
Sunanda
23-Jul-2008
[10794]
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.
Chris
23-Jul-2008
[10795]
My virtual filesystem (in QM) simply doesn't allow them.  Same reason 
-- too many problems...
[unknown: 5]
23-Jul-2008
[10796x4]
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.
Chris
23-Jul-2008
[10800x2]
All three of which are a pain.
(one is platform dependent)
[unknown: 5]
23-Jul-2008
[10802]
Pain as compared to what?
Chris
23-Jul-2008
[10803]
Not dealing with spaces.
[unknown: 5]
23-Jul-2008
[10804]
option 1 above is even better than that.
Chris
23-Jul-2008
[10805x3]
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)
Henrik
23-Jul-2008
[10808]
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.
[unknown: 5]
23-Jul-2008
[10809]
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.
TimW
23-Jul-2008
[10810]
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.
Sunanda
23-Jul-2008
[10811x2]
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
TimW
23-Jul-2008
[10813]
thanks!
ICarii
3-Aug-2008
[10814x3]
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*"
Henrik
3-Aug-2008
[10817]
isn't there an /only refinement?
ICarii
3-Aug-2008
[10818]
doesnt work
Henrik
3-Aug-2008
[10819]
I guess this is where the fabled find/deep would come in.
ICarii
3-Aug-2008
[10820x2]
lol deep in a 1 level block :P
just checked R3.. doesnt work there either :(
Henrik
3-Aug-2008
[10822]
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.
ICarii
3-Aug-2008
[10823x2]
first find -  returns succesful index
as normal find works
Henrik
3-Aug-2008
[10825x2]
yeah, but find doesn't know that
perhaps it's simpler to parse the string
ICarii
3-Aug-2008
[10827x2]
too slow with 50,000+ words and pattern matching?
ill probably just use C# and use regex :)
Henrik
3-Aug-2008
[10829x2]
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
ICarii
3-Aug-2008
[10831x2]
or by length matching wildcard pattern
because once i use the full 300,000+ word dictionary its gonna need 
to be fast :)
Henrik
3-Aug-2008
[10833]
it helps if you are searching a hash
ICarii
3-Aug-2008
[10834]
wildcard searching a hash is rather messy tho isnt it?
Henrik
3-Aug-2008
[10835x2]
I've not tried it, but find should be much faster in hashes.
are you always searching from the beginning of the string?