World: r3wp

hmmm

Yes, I agree

Hm, I see that gob! now supports CHANGE and POKE, good news.

CHANGE doesn't work: http://curecode.org/rebol3/ticket.rsp?id=1789

You're right. I remember it was throwing error, so I thought it's 
ok now with my quick test.

What's the technical explanation for this question/answer ?  http://synapse-ehr.com/forums/showthread.php?151-Help-with-Script-error-Cannot-use-path-on-none!

Is it the way Rebol evaluates as it builds functions?

It looks like the code disconnects from the database and then tries 
to save to it without reconnecting. Beyond that I can't tell without 
knowing at which stage of the code the error is triggered.

But it looks like the error is triggered before the SQL call, so 
it looks like either the db or counter variables are none.

to me it looks like the code is breaking when first executed

so, it creates an empty db, so db/1 will be an empty block

My question is .. what does rebol do when it builds a function from 
the function definition

There is nothing special there related to the function definition. 
The 'db and 'counter vars are global. It looks like the initial
    db: SQL "select * from customer" 
call is failing, and 'db is set to none. Test for that.

If that were the case, the 'layout would fail ...

When are the paths in the layout evaluated? The only part I don't 
know is the View part.

Immediately

In that error there are only 3 path roots that could be none: db, 
db/:counter and FN. If the db is empty then db/:counter would be 
invalid even in the layout. That leaves FN.

This seems like a job for PROBE.

If ''layout completes, then FN will be a VID field object

so this suggests to me that db = [ ]

If there are no rows returned then that makes sense. Looks like the 
database access needs some work. And even if the path succeeded, 
the SQL at the end of btn-save would fail because the database is 
disconnected. Plus, the create statement at the beginning just creates 
a database, not a table.

I didn't look at the rest of the code .. I'm just interested in the 
tech explanation as to why the function errors out like that

The error message itself refers to some fairly limited code. A couple 
probe statements would narrow things down even further.

Anyone know which algo is used by the SORT function ?

Not a stable one (there's a ticket about that). It could be guessed 
by using a logging compare function.

So, did you guess it ?

I would bet on a quick sort.

If it uses several algos it will be difficult

Quick sort is not optimal for cases where the comparison cost is 
expensive.
And with Rebol comparisons have high cost

>> print mold collect [sort/compare [20 19 18 17 16 15 14 13 12 11 
10 9 8 7 6 5 4 3 2 1] func [x y] [keep/only reduce [x y] x < y]]

[[10 20] [1 10] [10 20] [10 19] [10 2] [10 18] [10 3] [10 17] [10 
4] [10 16] [10 5] [10 15] [10 6] [10 14] [10 7] [10 13] [10 8] [10 
12] [10 9] [10 11] [10 11] [10 9] [5 1] [9 1] [9 5] [5 2] [5 3] [5 
4] [5 6] [5 8] [5 7] [5 6] [5 4] [6 7] [7 8] [8 9] [6 7] [7 8] [6 
7] [1 2] [2 3] [3 4] [1 2] [2 3] [1 2] [16 11] [20 11] [20 16] [16 
12] [16 13] [16 14] [16 15] [16 17] [16 19] [16 18] [16 17] [16 15] 
[17 18] [18 19] [19 20] [17 18] [18 19] [17 18] [11 12] [12 13] [13 
14] [14 15] [11 12] [12 13] [13 14] [11 12] [12 13] [11 12]]

ok it's quick sort

far from behing the best one in our context as I said. Too much comparisons

*from beeing

Darn. Quicksort is still slow for mostly sorted stuff:

>> print mold collect [sort/compare [1 2 3 4 5 6 7 8 9 10] func [x 
y] [keep/only reduce [x y] x < y]]

[[6 1] [10 1] [10 6] [6 2] [6 3] [6 4] [6 5] [6 7] [6 9] [6 8] [6 
7] [6 5] [7 8] [8 9] [9 10] [7 8] [8 9] [7 8] [1 2] [2 3] [3 4] [4 
5] [1 2] [2 3] [3 4] [1 2] [2 3] [1 2]]

See also this: http://curecode.org/rebol3/ticket.rsp?id=1152

Merge sort seems to give the best results when the comparison functions 
are expensive.
http://warp.povusers.org/SortComparison

Good idea, as long as the sort is stable.

Shell sort seems pretty good aswell

Merge sort is for when comparisons are *really* slow, sorting disk 
records slow. You have to have a really heavyweight mezz compare 
function to justify that. The overhead of the second series would 
be pretty high in cases where the speed difference would really matter. 
One of the inplace sorts would be better, as long as it's stable.

there's no need to have heavy mezz, the Rebol's scheme is already 
50 times slower (at least) than same compiled code when it ferdorms 
comparisons.

std::sort seems to do really well.

I don't know this algo

Apparently the actual algo varies from compiler to compiler, but 
it is a mix of qsort, heapsort and insertion sort depending on which 
is fastest in particular circumstances.

But it is in the C++ standard library, so C code wouldn't be able 
to use it without copying and rewriting.

It could in theory be the best, but that depends on how smartly it 
was written. It tends to be pretty reliable though because the pathalogical 
cases are in theory sorted with different algorithms when they would 
otherwise cause problems.

std::sort is not stable.

std::stable_sort is.

Interesting. It's been a long time since I used C++ (there were no 
standard libraries then). It never occured to me that someone would 
use an unstable sort algorithm without checking first whether it 
would be safe to do so. I must have missed that in college.

the funny thing about REBOL SORT is, that, it is actually stable, 
provided you use /compare

, which proves, that it just uses a wrong operator somewhere