World: r3wp

Interesting that R2 is much faster than F3 here.

R3

R3 is still beta -- so may be full of debugging code.

Also, are you comparing my times with yours? We have may have different 
speed machines

fastest algorithms on R2 and R3 are generally equally fast here.

I should rephrase that .. interesting my PC is much faster than yours!

....Or not running as many other processes :)

Just tried your code on R2.  You do have a faster machine than me, 
and R3 is currently much slower for this benchmark:
== 0:00:00.39
== 0:00:00.046
== 0:00:00.047

weird guys, but you don't do the same thing in R2 and R3 
(positive? -10:00) is 10 times faster than (positive? now/zone)

Another way (not faster but lol)

>>#"," - 1 == #"+"
>>#"," + 1 == #"-"

so, that should works like

>>#"," - sign? 10:00 

But it doesn't in R3, because

>> #"," - -1
==>> #"," - -1
** Script error: char! overflow/underflow
** Where: -
** Near: - -1

So, you can't add or substract a negative integer! to a char!, but 
you can add or substract a positive integer!
Weird, i said

Btw, with R2 it works

>> #"," + sign? -10:00
==#"-"

Seems a bug in R3

except, the formula was wrong
>> #"," - sign? -10:00

In R3, this will work:
    to-char (0 - sign? 10) + #","
    == #"+"
     to-char (0 - sign? -10) + #","
    == #"-"


Not quite as fast as Chris's suggestion, but rejigging to remove 
the (...) may help:
    dt [loop 100000 [to-char (0 - sign? -10) + #","]]
    == 0:00:00.39

well, it's just a shame to have to reconvert to a char!

doesn't work with 0 for timezone

ahah, yes

BY THE WAY,

pick "+-" negative? now/zone

fixes the 0 issue

-1 => "-" , and 0, +1 => "+"

sorry ... it should be  

pick "-+" negative? now/zone

Is my understanding of find/part wrong, or is this a bug?
     series: ["a" "b" "c" "d" "e"]
     find/part series "c" at series 3  

     == none      ;; fails to match using the [at series 3] part of  'series
    print mold at series 3  
    == ["c" "d" "e"]  ;; but [at series3] does contain the match

The /part <range> argument (at series 3) is supposed to mark the 
end of the search range. So, here FIND is searching in ["a" "b"] 
only.

>> find/part series "c" 3
== ["c" "d" "e"]
>> find/part series "c" at series 3
== none
>> index? at series 3
== 3

This looks like an inconsistency to me.

what do you mean Doc ? It has been always like that.

with /part you can specify a length or a terminal pointer to the 
serie.
What's wrong with that ?

/part makes the compare a record.  so its expecting a block to match 
I think.

? find
        /part -- Limits the search to a given length or position
                length (number! series! pair!)

It seems clear to me

/part -- Limits the search to a given length or position
, you're right, I've missed the "length or" part..

it should say "tail position" to be exact

doh.... sorry... my mind mixed-up /part with /skip...

Thanks. What was confusing me is an inconsistency between R2 and 
R3 -- was not sure if R3 was the bug fix or the problem.
R2:
    select/part series "c" at series 4
    == "d"
R3: 
    >> select/part series "c" at series 4
     == none

*** Do we agree R3 is right in this case?

yep

i use /part a lot, for example when i want to to find something in 
the first line of a text.
>> find/part text "something" any [find text newline tail text]

Looks like its a RAMBO report then, rather than curecode :)

Bind. I often use blocks of field (column) names from a db table 
in functions. Trouble is when I add a field I have to go back and 
add that field name to every place where I am using my fields.  I 
was thinking of just creating a block at the beginning of my code 
and then using "bind" to create a local context. I just can't seem 
to make it local. It behaves as a global. Is there some trick?

columns: [a b c d e f]
>> c1: use columns copy/deep reduce [columns]
== [a b c d e f]
>> c2: use columns copy/deep reduce [columns]
== [a b c d e f]
>> set c1 1
== 1
>> set c2 2
== 2
>> reduce c1
== [1 1 1 1 1 1]
>> reduce c2
== [2 2 2 2 2 2]
>> c1
== [a b c d e f]
>> c2
== [a b c d e f]

C1 and C2 are locals

Thank you Steeve. Never used "use" before and Bindology 101 was like 
Bindology 596 for me. :-)  (no offense Ladislav ) Thanks. I also 
didn't know you could set all the members of a block like that.  
Appreciate your help.

James, in my functions that fetch sql data I just setup all the variables 
as local and do a set on the record

eg.

func: [ get-sql /local name dob address ][
	foreach record records copy db-port [ 
		set [ name dob address ] record
	]	
]

>> name
** Script Error: name has no value
** Near: name

>> get-sql: func [/local name dob ][ set [ name dob ] [ "Graham" 
now/date ]]
>> get-sql
== ["Graham" now/date]
>> name
** Script Error: name has no value
** Near: name

ooops .. need a reduce in there .. but you get the idea.

Yes, that's the way I do it. exactly. My problem is that I often 
add some field and have to go back and add it to all the functions.

And so I was looking for a global way without the global (if you 
know what I mean)

well, you can create a context inside your functions

nope .. that won't work.

I looked at that and it creates an object. Would be ok then my laziness 
shows up and I don't want to have to use object paths.

won't work anyway

Looking at "bind" it appears it should work. It even describes an 
example which is what I want to do:


Binds meaning to words in a block. That is, it gives words a context 
in which they can be interpreted. This allows blocks to be exchanged 
between different contexts, which permits their words to be understood. 
For instance a function may want to treat words in a global database 
as being local to that function. 

unless you declare the variables as local , or use [ local-variables 
.. ]

well, you still have to bind either using 'use or 'bind

Graham, it's really about laziness on my part.

BTW, sorry to hear about your site.