[PASM] problem opening / reading file

[Clinton A. Pierce]

At 10:04 PM 8/12/2002 +0200, Jerome Quelin wrote:

>I looked at parrot_assembly.pod and saw:
> open px, sy
> Open the file Y on filehandle X
> read px, py, pz
> Issue a read on the filehandle in y, and put the
> result in PMC X. PMC Z is the sync object.

Ow. The I/O still hurts my head even now. It seemed to be an ugly
stepchild at the time.

>So, what am I doing wrong? What's the real syntax? (I wish there were a
>parrotopentut ;) ).

I don't think the I/O's quite mature enough for something like a
tutorial. I've got a couple of examples in the BASIC source code. They are:

basic.pl -- Where the immediate mode command is read. Nothing special
here. Note though that I run the command through a STRIPSPACE (alpha.pasm)
routine which removes trailing whitespace. You get the newlines here, and
in Win32 PASM I've seen inconsistencies as to what exactly this means (one
char or two). These may be fixed now.

instructions.pasm -- Look down where the LOAD instruction is
processed. Since there's isn't (or wasn't) a functional line-read PASM
instruction I wind up reading the whole damndable file into a buffer and
splitting it back out into an array. Also note that errors on the open are
silently ignored. I don't think they work right yet. Or they didn't. The
EOF detection didn't work IIRC, but checking for a zero-length read was
good enough at the time.

[Line I/O from files seems strange but Line I/O from the tty is just
peachy. *shrug*]

Also the INPUT routine does some line I/O just like basic.pl.

>While I'm at reading files - why isn't there a readline op for file handles?
>Is it planned / forbidden for an unknown (to me) reason / other (patches
>welcome :o) )?

*shrug*

>Another question. Is there a way to fetch command line arguments, such as:
>$ ./parrot foo.pbc foo bar baz

Thanks for asking this, as Simon Glover's answer was...
informative. Didn't know this before now.

[Dan Sugalski]

At 11:13 PM -0400 8/12/02, Clinton A. Pierce wrote:
>At 10:04 PM 8/12/2002 +0200, Jerome Quelin wrote:
>
>>I looked at parrot_assembly.pod and saw:
>> open px, sy
>> Open the file Y on filehandle X
>> read px, py, pz
>> Issue a read on the filehandle in y, and put the
>> result in PMC X. PMC Z is the sync object.
>
>Ow. The I/O still hurts my head even now. It seemed to be an ugly
>stepchild at the time.

Anyone up to throwing a list of outstanding problems with the I/O
system together? We need to get I/O off of Melvin's altogether
too-full plate before his wife hunts me down and does nasty things,
so this'd be a good place to start.

--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Clinton A. Pierce]

At 02:27 AM 8/13/2002 -0400, Dan Sugalski wrote:
>At 11:13 PM -0400 8/12/02, Clinton A. Pierce wrote:
>>At 10:04 PM 8/12/2002 +0200, Jerome Quelin wrote:
>>
>>>I looked at parrot_assembly.pod and saw:
>>> open px, sy
>>> Open the file Y on filehandle X
>>> read px, py, pz
>>> Issue a read on the filehandle in y, and put the
>>> result in PMC X. PMC Z is the sync object.
>>
>>Ow. The I/O still hurts my head even now. It seemed to be an ugly
>>stepchild at the time.
>
>Anyone up to throwing a list of outstanding problems with the I/O system
>together? We need to get I/O off of Melvin's altogether too-full plate
>before his wife hunts me down and does nasty things, so this'd be a good
>place to start.

I'd volunteer, except that I'm used to grunging around at the assembler
level of I/O (INT 21h!) or with C's stdio and I don't think that your goal
is either one of these targets. Frankly too, I don't understand the
reasons and goals behind the monstrous complexity of Perl 6 and latter Perl
5's I/O.

If you simply want a list of what we have outlined in core_ops, what works,
what doesn't, and what's needed for a primitive I/O system... THAT I could
piece together.

[Rob Hanson]

At 02:27 AM 8/13/2002 -0400, Dan Sugalski wrote:
>Anyone up to throwing a list of outstanding
> problems with the I/O system together?

From: Clinton A. Pierce [mailto:cli...@geeksalad.org]
>I'd volunteer, except that I'm used to grunging
> around at the assembler level of I/O (INT 21h!)
> or with C's stdio and I don't think that your goal
>is either one of these targets.

I looked at the io ops a few weeks ago and it looks like only the open and
readline are working. The write and read ops are using an incompatable file
handle (int instead of FILE). I played around with them a bit and got them
working for strings, but didn't go much further than that.

If you want, I could take a stab at fixing it, although like Clinton, I'm
not sure what the ultimate goal is.

I also had a question about the read and write ops for NUM and INT... is it
a good idea to be able to read/write in an INT length worth of data when INT
size could vary from machine to machine? Or am I missing the reason for
those?

Thanks.

Rob