World: r3wp

In R3, true :)

Ah, sorry, I was looking for R3 sollution.

Note that the unless guard above is compatible with the R3 version. 
If either series is empty or at its tail at that position, it's a 
noop, silently.

So watch out.

Watch out for this limit in R3 too (which I forgot to backport):
>> swap a: "a" b: %b
** Script error: values must be of the same type
** Where: swap
** Near: swap a: "a" b: %b

I need it for blocks that has been sanitized before, so no problem 
here.

As far as I can tell, the single type restriction is so the implementation 
of the action in the various datatypes can be simplified. I am interested 
to see how well SWAP works for gobs though. Can you test this and 
see if there are bugs?

Yeah, I will. But I expect problems, gob! series support is very 
limited.

There shouldn't be any problems with this particular operation being 
defined, but I haven't done much bug testing since I don't need any 
graphics support most of the time. All I do is core.

As expected:

>> swap g next g
** Script error: cannot use swap on gob! value
** Where: swap
** Near: swap g next g

this IS core stuff. i haven't called view ;)

Does it work between different gobs? Note: It would only work with 
gobs that have subgobs, in theory.

If it doesn't, this needs a ticket. There are other similar gob bugs 
(CHANGE comes to mind).

Does it work between different gobs?

 - no, it doesn't work between two gobs and it doesn't work for one 
 gob (with sub gobs).

Then we need a ticket for that. I would think that there would be 
some GUI reasons for doing SWAP, though more for doing MOVE.

Well it' s a bad example, because
>> swap g next g
is easly performed with:
>> insert g g/2
:-)

??

>> g: [a b]
== [a b]
>> insert g g/2
== [a b]
>> g
== [b a b]

I just checked, and all of the functions called by MOVE are compatible 
with gobs. If they behave in a similar way then we can add gob support 
to MOVE.

working with gobs only

working with gobs only
 - isn't it a bug, then?

No it's a feature

A Gob can only have one parent at a time.

when you insert a gob already connected somewhere, it's automacly 
removed from the old place

Great feature

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.