World: r3wp

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.

I would want to put all values that are going to be tested in a block.

a < [1 2 3 4]

Would be nice if we use op! values as an argument to functions.

yeah that is what I initially wanted to do Henrik.

I remember from my HP48 calculator that any numbers put in a block, 
could be operated on like that. But I think this is the beginnings 
of vector operations, which is a big area that should be done right.

My function is actually very restricted in that it looks for the 
op! as the second to last value and the comparator as the last item.

because I would also like to see:

>> 1 + [2 3 4 5]
== [3 4 5 6]

in R3 there are ways to do this with a bit more code.

I could make that change to my function and easily accomodate that.

No outside of a single block though.

I would love to see it in R3, but so far nothing from Carl WRT this 
particular feature. I think it might complicate op! way too much.

I'm sure we can do something in the mezz sense once R3 gets released.

Shouldn't < > and = return as a logic values as well as being op 
values?

>> logic? get to-word "<"
== false
>>

I guess because it doesn't return true or false until it operates 
on something it wont return a logic value.  But maybe we should at 
least subclassify some operators to distingish them more.

some modifications made:

op+: func [blk /local op args arg blk2 blk3][
    op: first back back tail blk
    blk3: copy []
    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 item: attempt [do blk2][

            either find form blk charset "<>=" [return item][append blk3 item] 
              
        ]
        remove blk2
    ]
    if not empty? blk3 [return blk3]
    false
]

>> op+ [1 2 3 4 + 1]
== [2 3 4 5]

what you return is that the datatype is op!, not logic!, so logic? 
returns false.

>> op+ [1 2 3 4 > 2]
== true

yeah I know I thought it would return logic and op depending on the 
test.

would be nice to have lop?

lop? - returns true or false if operator returns logic values.

what do you mean?

ok