ParrotIO objects
Cory Spencer
I'd posted a similar message to this on the weekend, but it was a little
sparse on the details, so I'll rephrase it again.
The program I'm writing is passing a ParrotIO object about to various
functions (the ParrotIO object being either stdin or a file handle to a
regular file). Each function can read as many bytes as it likes from the
descriptor. There are times, however, where I might decide that I don't
want the byte I just read, and need to push it back onto the stream. This
brings up (I think) two ways around the problem:
1) I'd like to be able to peek ahead at a byte, before actually
consuming it. ie)
peek DEST, ParrotIO, NBYTES
...
...
read DEST, ParrotIO, NBYTES
In this case peek returns NBYTES from ParrotIO into DEST, but it's
not actually until the 'read' op that the bytes are removed.
2) After reading in a number of bytes from the ParrotIO object, it's
possible to push it back onto the stream for reading later. ie)
read DEST, ParrotIO, NBYTES
...
...
unread ParrotIO, BYTES
Where after the 'read' op I decide that I don't actually want to
consume the bytes from the strea, so I am able to 'unread' them back
onto the ParrotIO object.
A Perl 5 module has apparently been implemented with similar behaviour:
http://search.cpan.org/~bmorrow/IO-Unread-0.03/Unread.pm
So the question remains: are either of these methods possible, planned or
even desirable for Parrot?
Regards,
Cory Spencer
Melvin Smith
>The program I'm writing is passing a ParrotIO object about to various
>functions (the ParrotIO object being either stdin or a file handle to a
>regular file). Each function can read as many bytes as it likes from the
>descriptor. There are times, however, where I might decide that I don't
>want the byte I just read, and need to push it back onto the stream. This
>brings up (I think) two ways around the problem:
>
> 1) I'd like to be able to peek ahead at a byte, before actually
> consuming it. ie)
Yes, Parrot will get an "unget" and "peek". Now that the buffering
layer is mostly working it should be quite easy.
I've had a bad bout with the flu for the last 7 days. As soon as I can sit
up again I'll see about patching it in.
-Melvin
Pete Lomax
I was planning on chucking say 0 or -1 in P4[n] when I closed the
file, but it won't let me do this. (set_integer_native not implemented
in class parrotIO) I hope there is something planned not yet
implemented?
Pete
Jeff Clites
On Dec 22, 2003, at 2:48 PM, Melvin Smith wrote:
> At 11:02 AM 12/22/2003 -0700, Cory Spencer wrote:
>> The program I'm writing is passing a ParrotIO object about to various
>> functions (the ParrotIO object being either stdin or a file handle to
>> a
>> regular file). Each function can read as many bytes as it likes from
>> the
>> descriptor. There are times, however, where I might decide that I
>> don't
>> want the byte I just read, and need to push it back onto the stream.
>> This
>> brings up (I think) two ways around the problem:
>>
>> 1) I'd like to be able to peek ahead at a byte, before actually
>> consuming it. ie)
>
> Yes, Parrot will get an "unget" and "peek". Now that the buffering
> layer is mostly working it should be quite easy.
I assume this would only be allowed to work if a buffering layer is
topmost, right? That is, I shouldn't be able to do either to an io_unix
layer.
> I've had a bad bout with the flu for the last 7 days. As soon as I can
> sit
> up again I'll see about patching it in.
Hope you feel better!
JEff
Leopold Toetsch
Can you come up with a minimal working example?
> Pete
leo
Pete Lomax
wrote:
Attached, one small program and two small text files for it to play
with. Strictly speaking, I could make it smaller, but I felt it better
to show something performing read functions on different files.
My question is: What can I do to P4 entries to mark them as available
for re-use?
Regards,
Pete
Leopold Toetsch
> My question is: What can I do to P4 entries to mark them as available
> for re-use?
close:
P0=P4[I1]
close P0
# mark slot as free
null P5
P4[I1]=P5 # set to NULL
ret
you can test the entry by:
set P0, P4[I1]
isnull P0, is_close
#
is_close:
> Regards,
> Pete
leo
Luke Palmer
When writing one of my pet languages, I found a need (or a want) to
replace the contents of a PMC with a different PMC. To accomplish this,
I wrote an op that memcpied the header of the source into the header of
the destination. It worked. (Maybe a simple struct assignment would
work, too)
Is this a safe thing to do? If so, I think it deserves core ophood.
Luke
> >Regards,
> >Pete
>
> leo
>
Leopold Toetsch
> When writing one of my pet languages, I found a need (or a want) to
> replace the contents of a PMC with a different PMC. To accomplish this,
> I wrote an op that memcpied the header of the source into the header of
> the destination. It worked. (Maybe a simple struct assignment would
> work, too)
Its not outerly clear what you want to achieve, but it sounds like
assign Px, Py
assign the PMC Px to the contents of Py, i.e. the set_pmc vtable.
> Luke
leo