World: r3wp

That number I posted is the highest in my algorithm I could hit.

Ok, that makes sense.

p: open/direct/write/new %/k/test.bin

b: make binary! 1000000 insert/dup b #{00} 1000000 i: 0 while [not 
error? try [insert tail p b]][i: i + 1]

created file ower 5GB here... than I stoped it.

what OS?

WIN/ ntfs

ok cool.

I want to be able to do some probes on the file once I get it to 
size.

on the port rather.

The problem is with reading anyway

You having problem reading that file now?

But not impossible I guess. Using such a big files is not practical 
imho.

I think it's when you want to seek to a position greater than 2 ^ 
31 - 1

you run into a problem then.

I'm not going to read such a file if I have only 1GB memory:)

Well I'm testing a new indexing system for TRETBASE and need to know 
some significant data to fine tune it.

That is where my interest lies Anton.

Interesting the limit for file size in REBOL is 2 ** 31

when the port/state/tail value reaches 2 ** 31 it converts it to 
a negative number and gives an error which is an "access error writing 
to port".

Now the port can still be read via open/direct but no longer accessible 
via open/seek at that point.

Not sure how OLDES was able to get his file over 5GB on NTFS as my 
test was also on NTFS.

I wonder if WRITE/APPEND allows files over 4 GB?

I would have thought that write would be using open also.

REBOL should be able to break this limitation.  Even if it means 
holding a pointer to a file position and then looping over again.

I tried Oldes method and able to get it over the limit.

I noticed using his refinements I no longer have access to tail from 
querying the port.

The only limitation I could find is in /seek.

So next question - do we have any source of /seek to understand why 
we have such a limitation?

The source of OPEN, isn't. It seems likely that the 32-bit integers 
of R2 are at fault here.

Well I would assume that the 32 bit integers are being used on open/direct 
so I'm not sure why this limitation only affect /seek and not /direct 
as well.

My need is to be able to get the tail or index of files larger than 
the 32 bit integer limit.

I expect that /direct is just using file handles and isn't setting 
offsets like /seek.

I don't know what the port flags or the port/state/misc counters 
are used for.

Do you know anyway around this limit?

A work around?

ahhh time to eat - be back in a few.

This may be one of those use-another-tool-through-call or use-R3's-64-bit-integers 
situations.

That isn't the kinda of answer I was looking for but expected.

Any ideas what the numbers mean in the port/state/misc section of 
a file port?

Nope. Anyone else want to give this a shot?

Would be nice to have the feature to access the currently indexed 
position of the open port and perform a function on it.  For example, 
modify /awake to work with files.  Such that any reference to the 
file or altering of the position can be handle via an awake/handler.

looks like in R3 we get  'AT expanded to 64 bit possible to access 
the open/direct files.

I have a handy little function I made and don't know if there is 
already an easy way to do this in REBOL but I have a function called 
'any+ that simply keeps me from repeating any statements.  For example:

>> a: 3
== 3
>> if any+ [1 2 4 > a][print "cool"]
cool

Got a bit tired of writing  ANY [1 > a 2 > a 4 > a]

This is one of those things that I often wonder if we already can 
do this easlier and I just don't know what it is.

There isn't anything built in that does that. For simple min/max 
comparisons, you could do something like this:

	if a < first maximum-of [1 2 4] [print "cool"]

I also have a shortcut for FIRST MAXIMUM-OF.


 pick-max: func [series [series!]] [attempt [pick maximum-of series 
 1]]
	if a < pick-max [1 2 4] [print "cool"]


For the general case, I would use a map and anonymous func combo. 
R3 has a native MAP func, but you have to roll your own in R2.

nice Gregg.

;here is my little 'any+ function:

any+: func [blk /local op args arg blk2][
    op: first back back tail blk
    arg: last blk
    if word? :arg [arg: get :arg]
    args: copy/part blk find blk op
    blk2: reduce [op arg]
    foreach item args [
        insert blk2 item
        if attempt [do blk2][return true]
        remove blk2
    ]
    false
]

for the any+ function you put the multiple items on the left side 
of your block and the single item to compare to on the right side

For example:

any+ [1 2 3 4 > 3]

it's good, but I wonder if we can come up with an even better syntax.

I think we can.  One that can probably accomodate much more.