How might this work?

I'd like to implement a module that permits this:

use IO::Mark;

sub examine {
     # Get the file handle. Might not be seekable
     my $fh = shift;

     my $mark = IO::Mark->new($fh);

     my $buf;
     $mark->read($buf, 1000, 0);

     # Do something with buf

     # On exit $fh rewinds making the fact that we've read
from it
     # invisible
}

IO::Mark is a clone of a filehandle that you can read from
without
(apparently) consuming input from the underlying handle.

Behind the scenes it would add a dynamically sized buffer to
the
filehandle and arrange for the filehandle to reread the
contents of the
buffer and then carry on reading new data from the handle.

The idea is to be able to write code that peeks the contents
of a non-
seekable handle transparently to the caller.

I can't immediately see anything on CPAN that does that -
although it's
entirely possible that I missed it.

As far as I can see I could do it using PerlIO and pushing a
new
buffering layer into the handle. Is that sensible?

-- 
Andy Armstrong, hexten.net

Andy Armstrong wrote:
> IO::Mark is a clone of a filehandle that you can read
from without
> (apparently) consuming input from the underlying
handle.

I've had use for such a thing in the past.

On 26 Feb 2007, at 21:20, Michael G Schwern wrote:
> Andy Armstrong wrote:
>> IO::Mark is a clone of a filehandle that you can
read from without
>> (apparently) consuming input from the underlying
handle.
>
> I've had use for such a thing in the past.

Indeed. It's so handy that I can't quite believe it doesn't
exist 

I'm playing with PerlIO::via at the moment which looks as if
it'll  
let me do what I want.

-- 
Andy Armstrong, hexten.net

Quoth andyhexten.net (Andy Armstrong):
> I'd like to implement a module that permits this:
> 
> use IO::Mark;
> 
> sub examine {
>      # Get the file handle. Might not be seekable
>      my $fh = shift;
> 
>      my $mark = IO::Mark->new($fh);
> 
>      my $buf;
>      $mark->read($buf, 1000, 0);
> 
>      # Do something with buf
> 
>      # On exit $fh rewinds making the fact that we've
read from it
>      # invisible
> }
> 
> IO::Mark is a clone of a filehandle that you can read
from without
> (apparently) consuming input from the underlying
handle.
> 
> Behind the scenes it would add a dynamically sized
buffer to the
> filehandle and arrange for the filehandle to reread the
contents of the
> buffer and then carry on reading new data from the
handle.
> 
> The idea is to be able to write code that peeks the
contents of a non-
> seekable handle transparently to the caller.
> 
> I can't immediately see anything on CPAN that does that
- although it's
> entirely possible that I missed it.

IO::Unread

Ben

-- 
   If you put all the prophets,   |   You'd have so much
more reason
   Mystics and saints             |   Than ever was born
   In one room together,          |   Out of all of the
conflicts of time.
benmorrow.me.uk                                    The
Levellers, 'Believers'

On 26 Feb 2007, at 18:35, Ben Morrow wrote:
>> I can't immediately see anything on CPAN that does
that - although  
>> it's
>> entirely possible that I missed it.
>
> IO::Unread

Nearly - but it doesn't have the convenience of being able
to take a  
non-seekable handle and pass it to two different chunks of
code both  
of which get to read from it without trampling on the
other.

With IO::Unread you need to know what you're unreading.
Ideally the  
code doing the reading should be completely unaware of any
magic  
associated with the handle.

-- 
Andy Armstrong, hexten.net

Quoth andyhexten.net (Andy Armstrong):
> On 26 Feb 2007, at 18:35, Ben Morrow wrote:
> >> I can't immediately see anything on CPAN that
does that - although  
> >> it's
> >> entirely possible that I missed it.
> >
> > IO::Unread
> 
> Nearly - but it doesn't have the convenience of being
able to take a  
> non-seekable handle and pass it to two different chunks
of code both  
> of which get to read from it without trampling on the
other.
> 
> With IO::Unread you need to know what you're unreading.
Ideally the  
> code doing the reading should be completely unaware of
any magic  
> associated with the handle.

Yes. I meant it as an example of how to invoke the :pending
layer (via
PerlIO_unread), which is I think what you want to use.

Ben

-- 
Like all men in Babylon I have been a proconsul; like all, a
slave ... During
one lunar year, I have been declared invisible; I shrieked
and was not heard,
I stole my bread and was not decapitated.
~ benmorrow.me.uk ~                   Jorge Luis Borges,
'The Babylon Lottery'

On 27 Feb 2007, at 20:58, Ben Morrow wrote:
>> With IO::Unread you need to know what you're
unreading. Ideally the
>> code doing the reading should be completely unaware
of any magic
>> associated with the handle.
>
> Yes. I meant it as an example of how to invoke the
:pending layer (via
> PerlIO_unread), which is I think what you want to use.

Ah, thanks Ben 

I have a pretty much working proof of concept here now. I'm
not using  
the :pending layer though - will investigate that, thanks.

-- 
Andy Armstrong, hexten.net

On 26 Feb 2007, at 21:31, Andy Armstrong wrote:
> I'm playing with PerlIO::via at the moment which looks
as if it'll  
> let me do what I want.

It's here if anyone's interested:

http://search.cpan.org/~andya/IO-Mark-v0.0.1/lib/IO/M
ark.pm

Not entirely happy with the implementation but as a proof of
concept  
it seems to work.	


-- 
Andy Armstrong, hexten.net

* Andy Armstrong <andyhexten.net>
[2007-02-27T21:52:38]
> It's here if anyone's interested:
> 
> http://search.cpan.org/~andya/IO-Mark-v0.0.1/lib/IO/M
ark.pm

Neat.  See also

  http://search.cpan.org/~hdp/IO-Handle-R
ewind-0.06/lib/IO/Handle/Rewind.pm

-- 
rjbs

On 28 Feb 2007, at 03:03, Ricardo SIGNES wrote:
> Neat.  See also
>
>   http://search.cpan.org/~hdp/IO-Handle-Rewind-0.0
6/lib/IO/Handle/ 
> Rewind.pm

Ah right. That's nice and simple. Less general though.

My main outstanding problem is how to cleanly pass my shared
cache to  
newly created filehandles. When I create a clone all I have
to work  
with is the filehandle being cloned. The clone needs access
to the  
same cache object the base filehandle is using. Stashing a
reference  
to it in the filehandle glob doesn't seem to work -
presumably  
because the filehandle the PerlIO::via handler sees isn't
the same  
handle that's visible outside PerlIO.

At the moment I'm using the base handle's fileno as an index
into a  
hash - but that's no use for a handle that has no fileno.

If anyone has any bright ideas I'd love to hear them.

-- 
Andy Armstrong, hexten.net