World: r3wp

I actually did that and it got no errors which really has me a bit 
stumped.

That's weird. Could you test, if the just inserted value in the block 
is not integer!? Like:
if integer! <> type? first blk [print "something"]

And do that for every insert.

Well that is actually how I did my test.  I had the following in 
the subject area of the problem:


if not integer? record-number: first to-block raw-record [print record-number]

Problem is that it never printed anything

Maybe someone can tell me what the end! datatype is used for and 
that might help find the problem

Gonna go see if the core manual refers to the end! datatype.

end! is the datatype used to specify ends of blocks, if I remember 
correctly.

I didn't even know there was one.  In what way would it be used?

Yes, "internal marker for end of block"

It's an internal datatype.

My guess is, that somehow your input is an empty block (or the end 
marker) in some situations.

Hmm... ok then that might explain something.   I recall a copy function 
I had that caused the interal code of REBOL to spill out so I assume 
it has something to do with my port handling as that copy function 
I had did similiar.

So it might be in the area where I have a copy/part on file data 
which would result in a block.

Geomol where did you get that information as it being an internal 
marker for end of block?

R3 datatypes: http://www.rebol.net/wiki/Datatypes

Many are the same in R2.

ok thanks.

I think, end! was hidden in R2 and will be exposed in R3.

I suppose so.  Maybe Gabriele will be lurking and can provide more 
info.

I suppose the end! datatype isn't really interal code as I understood 
internal code in REBOL.

It appears possibly to do with the sort function

You can see the problem here - as it only seems to appear when the 
sort function is introduced:

>> head dbrecs

== make list! [1 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 
22 23 24 25 26 27 28 29 30
 31 32 33 34 35 36 37 38 39 40 41 42 43 ...
>> length? head dbrecs
== 10098
>> dbrecs
== make list! []
>> find head dbrecs end!
== none
>> sort head dbrecs

== make list! [1 4 5 end unset 6 7 8 9 10 11 12 13 14 15 16 17 18 
19 20 21 22 23 24 25 26 2
7 28 29 30 31 32 33 34 35 36 37 38 39 40...
>> find head dbrecs end!

== make list! [end unset 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 
21 22 23 24 25 26 27 28 2
9 30 31 32 33 34 35 36 37 38 39 40 41 42...

What do you see, if you do a
>> ? system/version

>> system/version
== 2.7.5.3.1

Have you checked the bug database, if it's a known issue?
http://www.rebol.net/cgi-bin/rambo.r

If it is the sort function then that would explain why putting the 
checks in my script didn't catch it because I was only using the 
sort in the console to test some other ideas.

(Just click the link, I gave, to run the bug database in your browser.)

I just searched it and didn't find mention of this problem.

This is related, I think: http://www.rebol.net/cgi-bin/rambo.r?id=3761&

Possibly.

But that one says its built already so there is still a problem that 
exists with the function.

I'm going to run another test real quick to see if it effects just 
the list datatype by converting to block before the sort

Ahhh - the problem goes away if I convert my list to a block datatype 
before the sort.

So sort is causing the problem when performed on a list datatype

Do you know of any mezzanine functions that utilize sort?

Is there a version 2.76?

2.7.6 rather

Different versions: http://www.rebol.net/builds/031/

Sort scripts: http://www.rebol.org/cgi-bin/cgiwrap/rebol/search.r?find=sort&form=yes

Yeah I don't see any hint of a version 2.7.6 in that list but I seen 
in the Rambo database a reference to one problem being fixed in version 
2.7.6.

There is an internal alpha of 2.7.6 that has not been released and 
I don't think RAMBO yet shows all the bugfixes for 2.7.6. Carl doesn't 
want to spend too much time on it, so Maarten is appointed release 
manager for it, as he was with R3 alpha 1.

so does this mean that 2.7.6 may never get released and instead just 
R3?

I hope not :-) I need some of those fixes for R2.

I don't mind the problems as long as they are being fixed for R3.

I have production systems that will not be migrated to R3, so I hope 
they will be fixed.

I don't know the sales stradegy for R3 which is why I'm not currently 
designing TRETBASE around it.  If I knew more I might make the leap 
now but didn't know how long alphas would be operable etc, costs 
of the end product of R3, etc...

it's a dangerous period for relying on R3 stability, because of modules, 
tasks and unicode not being in place yet. some very basic things 
may still change so much that the initial R3 test scripts might not 
work anymore.

Yeah good point.

I wouldn't expect production stability until about a year from now, 
but that doesn't mean we don't get to play with a lot of juicy alphas 
in the mean time. :-)

I actually haven't played with them much - it hasn't yet appealed 
to me.  Maybe I just don't understand everything that is changing.