AltME groups: search

Yes. I think of this aspect as combing the best elements from Forth 
and Lisp/Logo in a natural way. That is, lists (blocks) are the foundation, 
and you build up a vocabulary to do what you want. It also encourages 
us to structure and doc things a little more, compared to Forth; 
but you have the freedom to express things any way you want. It's 
a very different view from Python, where (my opinion), the goal is 
to make all programs look the same, no matter what the problem domain 
is.

i would like to do Authentication with R2 !!!!  is it possible ?

To answer your question in more concrete manner - I think that we 
have to stop and prevent our past ttitude of "you can code it yourself". 
Many ppl who come or will come to REBOL, are seeking a solution, 
they are not interested to do the work themselves. I think that R3/Extensions 
open some door to link to many outer system. But the hard work still 
needs to be done. As we are a small community, I once again propose 
some kind of Bounty system, so that we can sponsor most popular requests. 
This should address one aspect of the problem - REBOL devs not necessarily 
working only for free ...

Yes, I use hylafax which runs on linux .. but a windows client just 
has to do a http post of the file to the hylafax server

with launch you can probably come next to what you want with
launch {-s --do " script.r arg1 arg2"}

Hello! I'm receiving the following error when processing a cgi form 
to send an e-mail of the response.  I correctly can send from my 
laptop, Rebol/Core -- command line, with my set-net settings in user.r 
but when I do the same thing on my hosting account I get the following 
error:

most smtp servers do ip filtering on the input.  this allows them 
to know who is sending the email to them and will only allow ips 
they serve to connect.


since your hosting account is probably on a remote server, it won't 
be allowed to send data via your home smtp server account.

In the past I've always used /usr/sbin/sendmail to send e-mails via 
cgi but I'm lost on how to do it via Rebol.

hm.. I have a very newbie question .. do you most effectively add 
new pairs to hashtable by appending to it as a block ? can't figure 
out how to change a value .. set doesn't work that way

i was just thinking again about the idea of IF (etc.) keeping a reference 
to the condition argument for you, that is, so that instead of writing:

    if x: select block value [do-something-with x]

you can write:

    if select block value [do-something-with it]


The reason people say it's not worth it is usually that of having 
to bind/copy the block - you don't want that in every IF call and 
probably not even in the ones where it would be useful (and, there's 
really no other name you could use for the function).

so, I thought, can we avoid the bind/copy in any way?


actually, i think we can. some people would run in horror maybe, 
and Brian will complain about it not being thread safe (we still 
have no threads though), but what about the native was changed to 
do something like:

    func [condition block /local it*] [
        set/any 'it* get/any 'it
        it: :condition
        also
            if :condition block
            set/any 'it get/any 'it*
    ]

Brian, Steeve's examp;e works, you just have to do >>secure none

I was reading http://www.chalicegames.com/swym/SwymWebIntro.html
and some concepts were interesting to me(especially ETC), so I made 
REBOL equivalents:

http://box.lebeda.ws/~rebolek/rebol/swyv.r


There's a documentation in the script, so just few examples of what 
it can do:

SERIE:


>> serie [etc 1 2 4 .. 20 cycle [1 2 3] length 5 iterate [x: x + 
10] from 10 5]

== [1 2 4 8 16 1 2 3 1 2 10 20 30 40 50]

COMPARE:

a: [1 2 3 4 5 6 7 8 9]
b: [2 4 6]
>> compare a b [some a > every b]

== true


>> compare a b [one a > every b] 

== false

FILTER:

>> filter serie [iterate [x: x + 1] 10 ] [[x > 2] [x < 5]]

== [3 4]

>> filter etc [3 6 9] 100 [x > 250]

== [252 255 258 261 264 267 270 273 276 279 282 285 288 291 294 297 
300]

>> filter serie [1 .. 10] [[x > 5][zero? x // 2]]
== [6 8 10]


It's written in R3 but should also work in R2 (not tested). It's 
not optimized so if you're interested in it, feel free to do whatever 
you want to improve it (more patterns that ETC can recognize...).

Well it's interesting as a study dialect. But to be honest guys, 
i don't see the interest  to have them in Rebol.

Because we can do much of the use cases rebolek showed us  with one 
or two lines of rebol code.

And i don't need to say that it will got lightning speed by comparison

But anyway, It's lot of fun to do such things with Rebol.

if you want to check if there is a server port listening then you 
can do

open tcp://localhost:8881


and if you want to see if that port is open to the outside, then 
you need to use another PC to probe that port address

some miracle

 in this case meaning a community member with the time volunteering 
 to do the work.

Janko, a function is a context! value like objects. You can use the 
following mental analogy to see how it is related :

foo: func ["for demo" a [integer!] /local b][...]


would be *roughly* equivalent to constructing an object like that 
:

foo-def: make object! [
	hidden-ctx: make object! [a: none local: none b: none]
	body: [...]
	spec: ["for demo" a [integer!] /local b]
]


The body is bound to the 'hidden-ctx context at function creation. 
When calling 'foo, the interpreter will set the 'hidden-ctx object 
words values according to passed arguments and refinements and then 
DO 'body.


There's no differences on how REBOL treats "arguments" and "local 
words", it's part of the illusion. The /local refinement is used 
by *convention* only, to set "local words", you could just decide 
to use any other refinement for the same job. Here's an example :

>> a: func [/local b][print b]
>> a/local 5
5


Additionnaly, when you apply the ordinal natives on a function! value, 
you get :

>> first :foo
== [a /local b]		;=> the hidden context words

>> second :foo
== [...]			;=> the function body block

>> third :foo
== ["for demo" a [integer!] /local b]	;=> the original spec block

hm.. if rebol binds hidden ctx to function body then it really can't 
do anything to trigger warning on global words. (if I understand 
things aroung bind correctly)

well, how else would you do it? I guess you need kind of an escape 
sequence to evaluate a word or something.

there is plenty of functions to do such, the simple one is the one 
you can do

build: func [
    {Return text replacing $tags with their evaluated results.}
    content [string! file! url!]
    /quiet "Do not show errors in the output."
    /local out eval value
][
    content: either string? content [copy content] [read content]
    out: make string! 126
    eval: func [val /local tmp] [
        either error? set/any 'tmp try [do val] [
            if not quiet [
                tmp: disarm :tmp
                append out reform ["***ERROR" tmp/id "in:" val]
            ]
        ] [
            if not unset? get/any 'tmp [append out :tmp]
        ]
    ]
    parse/all content [
        any [
            end break

            | " $" [copy value to " " | copy value to end] (eval value)
            | copy value [to " $" | to end] (append out value)
        ]
    ]
    out
]

I have the code:
case equal? length? find myLine "text" 4 [...]
It fails on ==none
I can do it in more lines of code but was wondering the 
shortest way to get past this.
Any suggestions?
tia

Back in time digression...


I have often noticed that it is unemployed as a method for complex 
testings.

In general it's faster and more easily readable than a serie of nested 
if / else.

But to do such, the programmer must know how testings can be complemented 
and other simplification technics.

The novice programmers (whatever the language) often find it difficult 
to do it correctly.

This is probably a gap in computer education. We don't learn anymore 
the basics of Boolean algebra.

At least for me it is an important criterion to determine the general 
level of someone in computer sciences. 
If I see too many nested if / else in a program.
I think the personn lacks of solid foundations in programming.

Faster according to Carl. I think he had a blog entry on this one. 
Something to do with "all block" being more efficient than "if cond 
block".

I would still like to set up metrics to see what funcs are used most, 
for both development and production (i.e. profiling), and set up 
a rating system. There have been some ad hoc analyzers in the past, 
but no reference system.

Yes, Graham, I know. I should just do it. :-)

- the point here being that all functions used rejoin greater? equal? 
lesser? uppercase? are pure functions and can't screw up anything 
whatsoever

- second point is that to do this via dialect you would have to recreate 
whole rebol in rebol which is very very suboptimal (why do we have 
an interpreted lang then??)

- so if you could sandbox execution of functions , for example by 
only allowing pure rebol functions this would be solved

No you don't ... only one person has to do it and shares it with 
everyone else.  Thank you very much.

Well, in R3 we don't have pointers or pointer arithmetic, you can't 
just reference arbitrary memory, all data has to be either literal 
or returned from a function. Words aren't bound by default, they 
are bound by the LOAD and DO mezzanine code, which can easily be 
replaced for your sandboxed code. The code can run in an isolated 
module with careful control of its imports.

People say "do it in a dialect" like those come for free. There's 
dialect processing overhead, issues of when the arguments are processed, 
decisions about whether there are keywords or not. To get an idea 
about the real overhead of doing it in a dialect, look at the source 
of APPLY or MAP-EACH in R2. Both are compiled dialects.

If there's any way to make your code execute in one of the native 
dialects, do it, it's worth it.

data: parse-fixed-width-lines read/lines %PO.txt [
	vat-incl: 4 [ trim empty? not ]
	vat-num: 9 trim
	...
]

this func is used to execute [ trim empty? not ] with a value.. which 
is similar to pipe or stack lang with only 1 level deep stack :)) 

stream-through: func [ fs d /local x acc ] [ accumulate x acc copy 
[] fs [ do compose [ (x) d ] ] ]

I've done my own, and its similar, in size and functionality... not 
much to do... the scientific notation is a pain to manage.

Some time ago, I did form-decimal function too. But I am really a 
coding lamer, so dunno, if it cover at least half the cases other 
versions do. Here it is:

form-decimal: func [num /local tmp main rest sign base][

     either found? find tmp: to-string num "E" [

              parse tmp [
                 [copy main to "." 
                  skip
                  copy rest to "E"
                  |
                  copy rest to "E"
                  (main: copy "")  
                  ]
             
                 skip
                 mark: (sign: copy/part mark 1)
                 skip
                 copy base to end
               ]


        either sign = "-" [

                tmp: copy "0."

                loop ((to-integer base) - 1) [insert tail tmp "0"]
                insert tail tmp rest
        ][
                tmp: copy ""

                insert tail tmp join main rest

                loop ((to-integer base) - (length? rest)) [insert tail tmp "0"]  
                    
                           
        ] 
     
      tmp                 

     ][num] 

]

Graham, you are the man. That works perfectly. Thanks for the info 
and saving me a ton of time.  That's one of those "How in the world 
did you know that?" things to me.  I guess that "do" says "What does 
this mean to me?" - the "me" being Rebol . I appreciate your help 
(once again).

Has anyone extended the FOR* funcs to have special handling options 
for the first and last elements?  Gab's power-mezz, and an idea from 
another template generator made me think of how I do that today. 
Here's the basic idea:

forskip+: func [
        "Like FORSKIP, but with local FIRST? and LAST? support."
        [throw catch]

        'word [word!] {Word set to each position in series and changed as 
        a result}
        skip-num [integer!] "Number of values to skip each time"
        body [block!] "Block to evaluate each time"
        /local orig result
    ][

        if not positive? skip-num [throw make error! join [script invalid-arg] 
        skip-num]
        if not any [
            series? get word
            port? get word
        ] [

            throw make error! {forskip/forall expected word argument to refer 
            to a series or port!}
        ]
        orig: get word
        use [first? last?] [
            first?: true
            last?:  false
            body: bind/copy body 'first?

            while [any [not tail? get word (set word orig false)]] [
                if tail? skip get word skip-num [last?: true]
                set/any 'result do body
                set word skip get word skip-num
                first?: false
                get/any 'result
            ]
        ]
    ]

; Aliases copied from R3 mezz-file
ls: :list-dir
pwd: :what-dir
rm: :delete
mkdir: :make-dir

cd: func [
	"Change directory (shell shortcut function)."
	[catch]

 'path [file! word! path! unset! string! paren!] "Accepts %file, :variables 
 and just words (as dirs)"
][

 ; Workaround for R3 change in lit-word! parameters with paren! arguments
	if paren? get/any 'path [set/any 'path do path] 
	switch/default type?/word get/any 'path [
		unset! [print what-dir]
		file! [change-dir path]
		string! [change-dir to-rebol-file path]
		word! path! [change-dir to-file path]

 ] [throw-error 'script 'expect-arg reduce ['cd 'path type? get/any 
 'path]]
]

more: func [
	"Print file (shell shortcut function)."
	[catch]

 'file [file! word! path! string! paren!] "Accepts %file, :variables 
 and just words (as file names)"
][

 ; Workaround for R3 change in lit-word! parameters with paren! arguments
	if paren? :file [set/any 'file do :file] 
	print read switch/default type?/word get/any 'file [
		file! [file]
		string! [to-rebol-file file]
		word! path! [to-file file]

 ] [throw-error 'script 'expect-arg reduce ['more 'file type? get/any 
 'file]]
]

Yeah, sorry, TO-RELATIVE-FILE doesn't do full relative, it's mostly 
a variant of CLEAN-PATH. I wrote the R2/Forward version for use in 
DevBase 2, included it in 2.7.6, then ported it to R3. It's one of 
the two functions where the flow went the other way (IN-DIR being 
the other).

from !REBOL2 --> 

Gregg said "I wouldn't want to lose lit-words, but they do create 
issues at times."


I also don't want to loose lit-words (it they are what I thinkt they 
are). Isn't lit word 'this . which get's ecaled via do dialect to 
just word. I also don't want to loose that in no way.

REBOL's free-ranging evaluation is the polar opposite of Lisp that 
way. :-)  It can take getting used to, but I found it natural before 
long. It is different though, and it's something people can cite 
as being obviously different from other languages. 


Something fun to ask is what we would have to give up if REBOL had 
arg lists like other languages.

And what would it take so you could write REBOL like Lisp?


Would you be able to write func calls with parens, as in other langs, 
and then pre-process it with REBOL?


Ultimately, people have to realize that the lack of parens on func 
calls isn't just some crazy thing Carl wanted to do to be different.

The new or changed mezzanines in R2 2.7.7+ that use the lit-word 
calling convention explicitly evaluate parens to be more like the 
R3 version of the functions. However, since the evaluation is explicit 
within the function rather than performed by DO at the call location, 
op! evaluation isn't triggered:
>> a (w) + 2
** Script Error: Cannot use add on paren! value
** Where: halt-view
** Near: a (w) + 2


Since the lit-word calling convention is only really appropriate 
for functions that act like syntax (like FOR), interactive functions 
that work on files (like CD) or functions that use word values as 
flags (like SECURE), they are never used with functions that take 
as arguments the types of values that are returned by op! expressions 
(numbers, binaries, true or false). So this is never an issue in 
practice, only in bad code that should never work.

And the reasons to not have a prefix minus:

- It's ambiguous with the infix minus, and we don't have a compiler 
to resolve the ambiguity.

- The special case of DWIM for a missing first argument slows down 
DO, and makes user-defined ops not work.

I have ALTERNATE and MERGE at the lower levels. The first combines 
two series and returns a new series. The second merges one series 
into another, with a /SKIP refinement. I have TO-SPEC-BLOCK , since 
that's such a useful and common need. I avoided using AS- in the 
past, thinking more standard non-copying coercion funcs would make 
them confusing. Those haven't appeared, so I do use AS- sometimes 
now.

For instance, in R3 (can't check R2 right now on this computer) comparison 
is allowed to unset! and error! values can be done with operators 
if the unset/error value is on the left side of the operator, but 
not on the right. This is because operators redirect to actions, 
and action functions are different depending on their first argument 
(single-dispatch). The comparison actions for unset! and error! can 
compare to other values, but the comparson actions of other types 
don't support comparing to error/unset. The action! function that 
calls the action has a typespec for its first argument that doesn't 
allow error/unset, but the op! redirects to the internal action, 
not the action! function, and it works because it uses a DO trick 
instead of a standard function call.

Basically, the functions that you see in REBOL aren't necessarily 
the functions that are actually called. For each function type DO 
calls them a little differently, and this eventually gets to the 
actual function code. For most functions the argument spec type checking 
is done by DO, not the function itself. For natives (or mezzanines 
with explicit type checking) there can sometimes be some extra checking. 
Apparently all actions have to do some extra internal type checking 
because the argument compatibility rules are too weird to be expressable 
using the REBOL function spec syntax, so that syntax doesn't tell 
the whole story sometimes - the source of many dismissed documentation 
bug tickets, I'm afraid.

Oh, it gets trickier (in theory - I've had to do a lot of scientific 
method on the internals, not decompiling). I think that DO does some 
of the function call work, and the function type itself does the 
rest through an internal action. DO handles the evaluation rules 
and builds the stack frame, then passes along that stack frame to 
the function dispatch action of the function type for it to redirect 
to the real code in a type-specific way.


Now it definitely works that way, the only question is whether the 
type-specific dispatch code is built into DO itself, accessed through 
the action dispatch mechanism, or action code called directly without 
going through the action dispatch mechanism. Only Carl or a decompiler 
could say for sure. But really, it doesn't matter because the behavior 
is the same in any case.

On the other hand, if your data has good locality you can do a bitset 
minus a base value and it can still be small. Say if you are doing 
the numbers from 100000 to 100100 just subtract 100000 first.

Nothing to do with images

UNIQUE is not used because of this.

I can't remember how many times i wanted an handy way to add unique 
values in an existing serie.
like 
>> unique index [new-values ...]
instead of having such, we do dirty tricks like.
>> unless find index new-value [append index new-value]  
pretty common...

ZERO?, TRUE? and coercion. I can't really deside what to think about 
these examples:

>> zero? 0.0.0
== true
>> 0.0.0 = 0
== false

>> true? 1
== true
>> 1 = true
== false

What do you guys think?

It does make sense to have conditionals work on more than just logic 
values. Whether or not to do so is arbitrary, and many languages 
do so (mostly the Lisp-derived languages). It's one of the two main 
models.

then I guess I can't entirely do a debug-func: :func.


that's OK as long as there will be a method to not produce much overhead 
for production code.

Doc, how many R2 releases have happened in 2 years? One, and it wasn't 
a bug-fix release. But more releases are coming, and more often. 
So report stuff in RAMBO - it will do until we get those tickets 
migrated to CureCode.

I imagine we do a lot of things in REBOL that we shouldn't do, because 
nobody told us not to. :-)

Reporting the wait bug documents it, even if it gets fixed or not, 
so other users can (as I do) browse through RAMBO to either confirm 
the bug or to see if someone offers a fix or a workaround. It would 
be a problem if RAMBO was a closed system where you could not freely 
study the reports, but you can, and Curecode is the same. Do people 
not ever take notes, when stumbling onto something unusual?

I am not an R user, but I think of interest to offer such links between 
languages : I have done a simple Matlab extension for Rebol and if 
I find enough time, I will do also a Python extension

I have done several searches but haven't found what I'm looking for. 
I've looked at binding discussions until I went cross-eyed. Not a 
complaint, just an explanation of why I am consulting the "biological 
repository". I want to build a function that can access its own name, 
so I can assign it to a name and then just invoke that name to activate 
functionality using the name . The simplest example is -- name [] 
[......print name]. I would rather not use an object but will if 
necessary. My apologies if everyone else knows how to do this.

Great work, would be a nice alias to add in Rebol.

>> whereof: [get in disarm try [+] 'where]

>> g: f: does [print ["my name is" do whereof]]
>> g
my name is g
>> f
my name is f

re 'self as a keyword: do not worry, Christian, many Rebol dialects 
have keywords, e.g. 'self is already a keyword of the object specification 
dialect, as I see it. Just the Do dialect is promoted to not have 
keywords, alghough the names of infix operators actually are treated 
as keywords in R2, as I noted elsewhere

as far as I am concerned, I do not understand the people who ask 
for the name of the function - I never needed that, so it may be 
a design problem - they want to do something, that can be done in 
Rebol more elegantly, than they are trying to do it

yes, understood, it is OK, I just wanted to note, that you do not 
need to worry whether any specific dialect, like e.g. the function 
body specification dialect, at least for specific functions you define 
in the way that you find useful, uses any keywords you find useful 
for a specific purpose - that is the principle of Rebol dialects: 
do whatever you find useful

I guess it's easier to do it that way then have the user interrogate 
all the processes

I need to do something like this:

>> a: context [b: context [c:1]]
>> get in a 'b/c
== 1

Is there some way to do this?

having,
>> to-path [a b c]
== a/b/c

you can get it with:
>> do to-path append [a] 'b/c
== 1

In R3, dir? returns true for a non-existant directory if the file! 
supplied ends with a /. This is the opposite from R2 but is it correct 
to do so?

I do not understand, which one looks strange to you: is it the representation 
of mold "^""?

(just something I've come to do through the years.. never rely on 
print)

All you have to remember is that every round of loading does another 
round of resolving escapes, and every round of molding does another 
round of adding escapes. And that there is one round of loading when 
you DO a script or do a command line, and one round of molding when 
the command line prints its results.

Did anyone do IP arithmetics? I need to check, if some ip is in correct 
range  :-)


I have e.g. IP 10.10.10.10, and I need to check, if it belongs to 
10.10.0.0/16. I have very primitive (but probably complicated function, 
which can't however count with cases where mask is different from 
8. 16, 24, or 32:

in-ip-range?: func [ip-fw ip-sq /local is? ip-sq-tmp ip-fw-tmp][


  ;--- turn ip-string into block of separated values- removes dots 
  and slash ["10" "10" "10" "10" "24"]
  ip-sq-tmp: parse ip-sq "./"
  ip-fw-tmp: parse ip-fw "."

  mask:  last ip-sq-tmp
  ip-sq: copy/part ip-sq-tmp 4
  ip-fw: copy/part ip-fw-tmp 4
   
  switch/default mask [

    "8"  [either (copy/part ip-fw 1) = (copy/part ip-sq 1) [is?: true][is?: 
    false]]

    "16" [either (copy/part ip-fw 2) = (copy/part ip-sq 2) [is?: true][is?: 
    false]]

    "24" [either (copy/part ip-fw 3) = (copy/part ip-sq 3) [is?: true][is?: 
    false]]

    "32" [either (copy/part ip-fw 4) = (copy/part ip-sq 4) [is?: true][is?: 
    false]]
  ][
     is?: false

     print ["Mas not found: " mask ", the result will most probably contain 
     false positives ..."]
  ]

 return is?

]

Convert to integers (through tuple then binary) and do bitwise operations.
>> ip: to-tuple "10.10.10.10"
== 10.10.10.10
>> ip-as-integer: to-integer to-binary to-tuple "10.10.10.10"
== 168430090
>> set [mask-ip mask-range] parse "10.10.10.0/24" "/"
== ["10.10.10.0" "24"]
>> mask-ip: to-tuple mask-ip
== 10.10.10.0
>> mask-range: to-integer mask-range
== 24

>> mask-integer: (to-integer to-binary mask-ip) and (-1 xor (to-integer 
2 ** (32 - mask-range)) - 1)
== 168430080
>> mask-integer = (ip-as-integer and mask-integer)
== true

would it be possible to have more operators? In !Mikrotik group, 
I am trying do some stuff for MT routerOS API. Thanks to Anton, I 
can now proceed. When "studying" Python code, I found segment like:

elif l < 0x4000:
     l |= 0x8000


1) they can directly compare 'l of integer type to binary value. 
But I might make wrong conclusion here. But 'l is really result of 
len('string here') operation. But - even if so, I don't miss such 
an automation, as I can always write if l = to-integer #{8000}


2) Second line is more interesting - I did not find precisely |=, 
but found e.g. /= ... and it translates like do some operation, and 
assign. In this regard, the only comparable operator of REBOL is 
++ or --, but in R2 this is just mezzanine, in R3 native. But if 
I am right, their code:

l |=0x8000

R3:
l: (to-binary l) or #{8000}


So, if I would assume 'l being of correct type already (binary here), 
would it be possible to have?:

l |= #{8000}


Hmm, that is not probably compatible with REBOL parser and REBOL's 
assigment operator, which is :

Is there any bits converter in REBOL? Or not even in rebol? I mean 
- how do I get from 255 or FF to "11111111"? :-)

To do proper integer to binary conversions in R2 you can convert 
the individual octets of the integer to char and then convert them 
to binary. I'm sure Steeve has more solutions for that though.

I really hope we go through the CureCode tickets soon and collect 
all of the ones that make minor changes to core semantics, so we 
can do a rip-the-bandaid-off fix-them-all release soon. Before too 
much code is written that might depend on the unfixed behavior.

its a shame cause looping a large list manually and comparing with 
same?  is VERY slow  :-(

on a 10 million sized series. 


my fastest FIND-SAME loop is 20 time slower than FIND, which would 
be much faster, since all it would have to do is compare a pointer.

Propably some inspectors could be added in the flow  to do some JIT 
compilation of your plugs ;-)

I've written a recursive function to do it, but I wondered if there 
weren't some better way.

On MIN/MAX with pairs, sorry I wasn't clear. I do NOT think it's 
a bug. I use that behavior myself, and seem to recall it being discussed 
long ago. It may not be what you expect initially, but I think it's 
the right design choice.

And when we get the permissions to do so, we can then

re "ask in chat or CC" - I asked in chat, privately, but do not see 
any reaction yet, and I added a comment to CC #1571

I do not know if that is what I want...i'm looking to prioritize 
each compare giving each a "weight"

You might be able to modify my ftp protocol for R3 to add the SITE 
command so that you can do CHMOD if that's the aim

practically speaking though if you only have the one ftp server .. 
you only have to do it once

network-modes? I do not see a ref erence to file dates.

Much easier to read if you do PRINT MOLD CONTEXT ...

what's your gut got to do with it?

You are certainly entitled to do whatever you like, but saying "foreach 
is the winner speed wise..." is wrong, since you did not allow parse 
to do what you allowed foreach to do.

so far, preallocating too large buffer takes much more time... but 
look at my funcs... I do even better  :-)

result: clear []


which re-uses the same block over and over, unless ladislav knows 
otherwise, the memory for that block isn't released by clear, only 
its internal size is reset to 0  which is why clear is so fast AFAIK.

Max - where do I get the dataset from, if I would try to rewrite 
your find-fast into a version using 'parse? :-) Do you generate one?

SWITCH used to be a mezzanine, so you could easily patch it if you 
want. This is the old mezz source.

switch: func [
    [throw]
    value
    cases [block!]
    /default case
][
    either value: select cases value [do value] [
        either default [do case] [none]]
]

Graham... LOAD does the escaping, READ does not. does this help? 
MOLD also does the escaping, so if you PROBE at the console you see 
that, but it has nothing to do with what is actually in memory.

Yeah, and the R3 CALL doesn't do anything like that yet. Time to 
edit the host code?

Graham, what about using REBOL words to do that job.. like:

>> rejoin [ "call " mold to-local-file %"/c/program files/rebol/rebol.exe" 
]
== {call "c:\program files\rebol\rebol.exe"}

If you want to do a progress meter, you'll need the read and write 
events as well.  Easy enough to add back in.  I wonder if this shouldn't 
be improved so that we can use it as standard in core 2.7.8.

In the close event I am supposed to return a true to exit that event 
loop, but if I do that I also shut down View events so I left it 
as false.
Is that correct??

in R2 ... isn't this wrong?

>> a: first do "['dd]"
== 'dd
>> type? a
== word!
>> a: to-lit-word a
== 'dd
>> a
== dd
>> type? a
== word!

but lit words are a datatype.   when such a lit word is encountered 
in a do block and evaluated, it is reduced to a word.  that is ok.


but when it is *stored* AS as a lit-word, it should not be evaluated. 
 remember that words may contain words, which will be evaluated.


so why should lit-words be evaluated too?  the basic word containing 
a word already does that.

Graham, Gab.: you are right, never checked that MOLD works like that 
on longer strings. I will remember that now.

But anyway... when you need to do call on unknown files, you should 
use more soficticated way.
Using just:
	rejoin [{"} to-local-file file {"}]

I consider as as security thread and I would never used it like that. 
And it does not metter if using MOLD or not.

Oldes, indeed, one should pass CALL a block and let it do the conversion 
(because it is platform dependent) - though right now I don't think 
it does much more than to-local-file and adding quotes.

What do you think about this:

>> even? 2.1
== true


As far as I am concerned, I would call it a bug, since 2.1 does not 
look like an integer multiple of 2.0 to me.