Re: To get things started...

Nicholas Clark <[email protected]> writes:
>On Mon, Nov 27, 2000 at 05:17:47PM +0000, Nicholas Clark wrote:
>> On Mon, Nov 27, 2000 at 11:09:03AM -0500, Chaim Frenkel wrote:
>> > >>>>> "ST" == Sam Tregar <[email protected]> writes:
>> 
>> > Look throught the RFCs this was one of Damian Conway's.
>> > 
>> > <chaim> =~ /RFC/
>> 
>> http://dev.perl.org/rfc/93.html
>> 
>> I know I read it, I just don't remember reading it.
>> 
>>   IMPLEMENTATION
>> 
>>   Dammit, Jim, I'm a doctor, not an magician! 
>> 
>>   Probably needs to be integrated with IO disciplines too. 
>> 
>> He's right, but Nick's intending to implement an unread() (rather than just
>> ungetc()) so there should be enough rope for people to implement whatever
>> knots take their fancy (including the Jack Ketch knot)
>> 
>> Hugo makes some comments about implementation of this in:
>> http://archive.develooper.com/[email protected]/msg00459.html
>
>Bah. meant to add that it might be logical for
>
>    <chaim> =~ /RFC/
>
>to seek to the beginning of the file before it starts
>
>    <chaim> =~ /\GRFC/gc
>
>carries on from the previous position and doesn't seek back to the beginning
>(or otherwise throw all the buffered data away)
>
>Which effectively makes pos analogous to seek/tell.

I was musing on how to make "layers" visible to perl code.
And using pos() to point at the current position in the buffer
(note the _buffer_ not the _file) was one idea I came up with.

>So do we get rid of poss and seek() our scalars? :-)

Keep pos() and loose seek ;-)

>It also allows the possibility of pos on file handles being fsetpos/fgetpos
>Maybe that should have been an rfc 3 months ago, and really doesn't even
>matter if perlio obsoletes stdio and internalises stdio's distinction between
>text and binary streams.
>
>BTW I am serious about needing a /gc not to chuck the buffered data.
>
>It makes something like
>
>   @found = <chaim> =~ /RFC +(\d+)/;
>
>not spend time stacking a lot of data back that's only about to be discarded.
>
>But this isn't internals really, is it? I'm miles off topic.
>
>Nicholas Clark
-- 
Nick Ing-Simmons <[email protected]>
Via, but not speaking for: Texas Instruments Ltd.