World: r3wp

Geomol: This way the executable may reside on a readonly file system. 
Sounds good to me.

Geomol, that way of locating user.r on Windows is really for the 
best. Windows is a multiuser OS after all, and the APPDATA directory 
on Windows is used roughly the same as the home directory on Linux. 
Global settings can be loaded from rebol.r in the same directory 
as the View executable.

I see, thanks!

Geomol, I have an include system as well.  It doesn't check for already 
loaded scripts but you may want to look at it.
http://www.lexicon.net/antonr/rebol/library/include.r

Can't find www.lexicon.net, it seems.

URL is correct, perhaps try again later.

I would like once again, if find/match on blocks has correct behavior? 

blk: ["Petr Krenzelok" "Richard Smolak" "Ladislav Mecir"]
find/match blk "Richar"


... will not work, and I would expect it to. At least RebDB gives 
me such functionality and it is nice to have ...

doesn't find/match only work on a per element basis? otherwise it 
would be much more complex... if not strings, how would you search 
words, objects, integers, etc.?

if it would work on per-element basis, it would work ...

actually I want someone to explain me, how is supposed find/match 
to work with blocks, if it was ever supposed to work? ;-)

with per element basis, I meant full strings, not parts of a string... 
does find/match blk "Petr Krenzelok" not work?

well, it works in a following way - find/match blk ["Petr Krenzelok" 
"Richard Smolak"] - will return block in "Ladislav Mecir" element 
position ...

which is, maybe consistent, but practically - unusable ...

I want find-each native then, like we have remove-each ...

well, I wrote a function a while ago, which is pretty speedy for 
this purpose. I used it for real-time elimination of names in a list

it equivalents a find/all blk "petr"

well, iteration - that is not the way to go in scripting language, 
is it?

iteration can get very complex, very quickly... unless you only want 
to search strings

but maybe RebDB does exactly that, so maybe fast enough for some 
10K of records :-)

How many global-mezz are necessary. You could code this one your 
self and re-used as needed.

I don't talk about mezzs, but natives ...

ask Carl why he added remove-each as a native? ;-) you could use 
mezz too, no? ;-)

The FIND/MATCH behaviour seems correct to me, Pekr.

correct yes - usefull - no :-)

In your particular case, perhaps.

we started with remove-each, we could continue with change-each, 
find-each, no?

dunno - I would find them being consistent additions and they would 
be fast ...

do http://hmkdesign.dk/rebol/rch4.r
requires View 1.2

code is messy, many one-letter variables :-)

find-each: func [dataset [series!] value /local result][
    result: copy []
    parse dataset [

        any [set word string! (if find word value [append result word])]
    ]
    result
]

>> find-each ["Jaime" "Carl" "Cyphre"] "a"
== ["Jaime" "Carl"]
>> find-each ["Jaime" "Carl" "Cyphre"] "y"
== ["Cyphre"]

Small modification it takes care of non-string values in the block.

Ha! That is so cool. Never thought function which serves different 
purpose can be used in such case ;-)

find-each: func [dataset [series!] value /local result][
    result: copy [] 
    parse dataset [

        some [set word string! (if find word value [append result word]) 
        | skip]
    ] 
    result
]


>> find-each ["Jaime" 1 "Carl" 2 "Cyphre" 3 http://google.com"Ladislav"] 
"a"   
== ["Jaime" "Carl" "Ladislav"]

I wonder if that one will be faster than loop?

that should be easy to test, will do so tomorrow ...

I remember someone used 'parse in the past as a trick to get pointer 
to binary data in rebol ...

it was somethin with images IIRC ...

Anton, I got access to your include.r now. Interesting option to 
only include certain functions or words from a script!

oh.. ? I think it's essential.

.. to avoid inadvertent pollution of your target context (usually 
the global context). This should avoid many bugs. It always annoyed 
me when C coding that when I included a library for a particular 
function, I had to check that library to see what else I was including. 
Then of course some libraries include things from other libraries...

This reminds me of Tao Elate. In that OS, all library functions are 
small VP asm files on disk. So if you use e.g. printf, only that 
function and not the whole stdlib is loaded in memory. The same function 
is also shared among all running programs minimizing memory overhead. 
Genius, as I see it!


Something like that can be implemented in REBOL with the use of objects 
in objects (that are not multiplied in mem). It's the way, e.g. the 
feel object is implemented in View. To be really efficient, only 
the functions (in the object) needed should be included into mem 
from disk.

note: that feature can be imitated using

    make object! [#include %somedefinition.r]


when using my INCLUDE. The only trouble is, when the author of the 
script does some "nonstandard" things. Then it may not be protective 
enough, which is the case of Anton's include too, where you have 
to rely on the discipline of the original author.

when you need a reduce/deep and there isn't one, what do you use 
instead?

I want to reduce something inside a nested block      reduce [ 'blah 
[  to-word "desired-literal-word" ] ]  ;sorta thing

reduce [ 'blah reduce [  to-word "desired-literal-word" reduce [to-word 
"deep-literal
-word"]] ]   ;ss this works...just talking to myself...nevermind

hmmn, reduce/deep or reduce/nested would be more elegant nonetheless.

what are you doing?

is compose/deep/only an option? Also a reduce/deep would be short, 
if you need it.

trying to reduce a set of nested blocks ... compose/deep/only would 
not reduce the inner blocks, but leave them as they are...

compose/deep [ (a) [ (b) ] ] ; would work