World: r3wp

I mean, is that integer! the value assigned to the port's state/index 
field?

yes it is

Steeve, I'm not sure how well you can override a built-in types (not 
decided yet), but you will be able to create new ones.

My belief i s that difference is that index is used to move the head 
to the specific position of the file where as using 'at keeps you 
at the head of the file.

But I don't know and asked before here and got no answer.

Paul, Brian, others, i used to manipulate the port/state/index with 
read-io and write-io because it's faster (i made some tests).

But the main reason is that we can directly manage the buffer used 
so that we avoid some overhead existing in the standard port handler

Paul, you don't move the head, you move the position. AT and SKIP 
are relative to the current position, 1 or 0 based respectively. 
INDEX? returns the current position, relative to the head.

How did you do those test STeeve?  I have been interesting in changing 
Trebases operation depending on how that works.

Right Brian but it doesn't seem to.

I'll defer to Steeve on this one - I am more familiar with the R3 
port model than the R2 one.

Not with the file port Brian.  At  seems to always work from the 
head.

if you open a port in direct mode it is always at head but in seek 
mode you can pick from the a specific point in the file.

Yeah, the port-as-series model doesn't work with direct very well.

Paul, it's just using port/state/index is theoricaly faster than 
at (because at is a wrapper)

internally 'at uses port/state/index

you can  see the source (i don't remember where)

iirc

the most annoying overhead comes from the wrapper of the copy func.
you should use read-io instead of, if you want very fast access

read-io and write-io use correctly the port/state/index, just don't 
forget that port/state/index is zero based (seems to be a bug)

Steeve, yeah I would assume that is the case.  So the difference 
your seeing in performance is really just a small one as a result 
of the 'at then being a wrapper?

I'm might do some tests here to see myself

agreed it's a small overhead concerning at, but not concerning copy 
(see the source if you find it)

source for what?

source for the file port handler, ok i'm looking for it....

You can't see the source of the file port handler.

in the past i found something...

It's native code.

perhaps it's the scheme to be exact

You might be thinking of one of these:
>> first system/schemes

== [self default Finger Whois Daytime SMTP ESMTP POP IMAP HTTP FTP 
NNTP HTTPS]

So what you really mean Steeve is that read-io is faster than copy 
correct?

That would make sense since read-io is lower level

i think it is

I never check to see how significant the difference was though.  
I might try  a test on a million records or so

I have got to backport the R3 profiling functions to R2 :(

Would be nice Brian but I got good ole stats/evals

speaking of backporting is 2.7.6 the end or is 2.7.7 still a possibility?

Further R2 releases will wait until after the R3 developer release, 
but they are coming.

The R3 profiling functions are wrappers around the R3 stats, so I 
just have to translate that to the R2 stats.

i think that in the past i saw the  source of the file-handler even 
if i can't find it anymore in my sources.

i have the sources of the handlers of other shemes in some proto 
scripts delivred with the commercial version of view.
But nothing else... i loose my memory...

read-io shouldn't be used with /seek it appears.

in fact they should make it so that  it CAN'T be.

need it to throw an error  or something.

why ? i use it with /seek as well

how many characters do you attempt to read each time?

seems with see you only get 15 characters to fill the buffer

see = seek

pass it a greater number and it will still only return 15

works ok with direct though

I think I ran into this problem before

Gonna check Rambo.