PIO tests
Michael Scott
Maybe some of the expected results are debatable.
Should PIO_parse_open_flags think that "<<<<<<<<<" is the same as "<"?
Should PIO_fdopen open ok on stdout with invalid flags like ";-)" or ""?
Also, successive calls to PIO_seek with SEEK_CUR seem to be broken.
Mike
Juergen Boemmels
> Here are some tests for the io.h API that should go in t/src/io.t.
Ah yes. I know I submitted one too. I thought it got committed a long
time ago but maybe it wasn't. I will try to merge it with your tests
and commit a change.
In one test you include "../io/io_private.h". I'm not sure if it's a
good idea to test implementation details. On one side its better to
test as many as you can, on the other side mainly the public API
should be tested, the implementation should just work.
> Maybe some of the expected results are debatable.
>
> Should PIO_parse_open_flags think that "<<<<<<<<<" is the same as "<"?
No it shouldn't.
> Should PIO_fdopen open ok on stdout with invalid flags like ";-)" or ""?
I think all invalid flags should be invalid.
> Also, successive calls to PIO_seek with SEEK_CUR seem to be broken.
I will look at this.
> Mike
bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Michael Scott
On Tuesday, Sep 30, 2003, at 15:44 Europe/Berlin, Juergen Boemmels
wrote:
> Michael Scott <michae...@mac.com> writes:
>
>> Here are some tests for the io.h API that should go in t/src/io.t.
>
> Ah yes. I know I submitted one too. I thought it got committed a long
> time ago but maybe it wasn't. I will try to merge it with your tests
> and commit a change.
>
> In one test you include "../io/io_private.h". I'm not sure if it's a
> good idea to test implementation details. On one side its better to
> test as many as you can, on the other side mainly the public API
> should be tested, the implementation should just work.
I'm just including io_private.h to get the correct flags to test the
return values of PIO_parse_open_flags() which is in the public API.
I agree there are limits to what should be tested, but what embarked me
on the tests in src/io.t was the failure of test 6 in pmc/io.t. I tried
to fix it, but because there were no src/io.t tests I couldn't be sure
whether the problem lay in the io.ops code or the io/* code.
Needless to say, once I'd written src/io.t, I got sidetracked into the
need for string C code tests, and never got back to pmc/io.t.
It seems to me that there are at various levels of "public" in Parrot,
and each one should be tested. Furthermore, the more tightly the
testing is done at the lowest level, the more confident we can be about
the higher level test results.
PIO_parse_open_flags() is, I think, a good case in point. It makes
sense to throw a bunch of invalid values at it in src/io.t, and then
assume that it works in pmc/io.t.
BTW those src/io.t tests should be rewritten to use the scheme Leo uses
in the 3rd test in src/basic.t. I proposed a patch to simplify this in
"[PATCH] C code test header" which if you could get into CVS I'd be
grateful as my string tests will rely on it.
Juergen Boemmels
> On Tuesday, Sep 30, 2003, at 15:44 Europe/Berlin, Juergen Boemmels
> wrote:
>
>
> > Michael Scott <michae...@mac.com> writes:
> >
> >> Here are some tests for the io.h API that should go in t/src/io.t.
> >
> > Ah yes. I know I submitted one too. I thought it got committed a long
> > time ago but maybe it wasn't. I will try to merge it with your tests
> > and commit a change.
> >
> > In one test you include "../io/io_private.h". I'm not sure if it's a
> > good idea to test implementation details. On one side its better to
> > test as many as you can, on the other side mainly the public API
> > should be tested, the implementation should just work.
>
> I'm just including io_private.h to get the correct flags to test the
> return values of PIO_parse_open_flags() which is in the public API.
Maybe PIO_parse_open_flags should also get moved to io_private.h. The
private/public split of the io subsystem is far from complete. In fact
io is the first subsystem that even tries to do so.
> I agree there are limits to what should be tested, but what embarked
> me on the tests in src/io.t was the failure of test 6 in pmc/io.t. I
> tried to fix it, but because there were no src/io.t tests I couldn't
> be sure whether the problem lay in the io.ops code or the io/* code.
>
>
> Needless to say, once I'd written src/io.t, I got sidetracked into the
> need for string C code tests, and never got back to pmc/io.t.
>
>
> It seems to me that there are at various levels of "public" in Parrot,
> and each one should be tested. Furthermore, the more tightly the
> testing is done at the lowest level, the more confident we can be
> about the higher level test results.
Ok you convinced me, we need to test private implementation
details. But this tests should be cleanly flagged as such.
> PIO_parse_open_flags() is, I think, a good case in point. It makes
> sense to throw a bunch of invalid values at it in src/io.t, and then
> assume that it works in pmc/io.t.
>
>
> BTW those src/io.t tests should be rewritten to use the scheme Leo
> uses in the 3rd test in src/basic.t. I proposed a patch to simplify
> this in "[PATCH] C code test header" which if you could get into CVS
> I'd be grateful as my string tests will rely on it.
The whole c_output_is() tests are more or less a hack.
Ideally there would be C-markos like
OK(val, name), DIAG(text), IS(this, that, name), etc. and be able to
check individual c-statements without recompiling and running a new
file each time.
Michael Scott
On Tuesday, Sep 30, 2003, at 19:20 Europe/Berlin, Juergen Boemmels
wrote:
Being more or less of a hack myself, I'm happy to persist with the
existing scheme, in the absence of any imminent ideal. The main hassle
with c_output_is() is, when developing the test, the C code dies and
the Perl harness doesn't notice. That's why I stick a "done" at the end
of every test.
Michael Scott
On Tuesday, Sep 30, 2003, at 19:31 Europe/Berlin, Melvin Smith wrote:
> Since PIO_parse_open_flags just assists the IO code in fulfilling
> an API, but is not part of the published API, I would suggest that it
> be moved into the private, but before tests are written for it, there
> should be a spec written.
Given how much code is already written, it's probably most efficient to
write the spec as tests.
> When I wrote the code, there was not even
> a design for what sort of API we would implement. I chose supporting
> a "stringified flags" because I liked it, but there was never much
> discussion about whether this was the right way or not. It is a very
> Perlish
> way of doing it, but languages that have constant values would then
> have to translate back to the string version to run on top of Parrot.
> That, or
> there will need to be a second form of open() written to take numerical
> constants.
When I was writing the PIO_parse_open_flags() test it did seem to me
rather Perlish to have string flags in the first place. But I'm a new
cockroach in town, so I kept my mouth shut, not wanting to get stomped
on.
If the PIO_F_* flags used by open() were moved up to io.h then they
could be exported as .constants by config/gen/parrot_include.pl and
used explicitly.
Various composite flags could be added for convenience.
PIO_F_WRITE_TRUNC (">")
PIO_F_WRITE_APPEND (">>")
PIO_F_READ_WRITE ("+<", "+>")
Also, add an INT flag version of open.
inline op open(out PMC, in STR, in INT)
>
> In short, I think it should be discussed as to whether it is even the
> right
> way. It seemed right at the time, but now I'm having second thoughts.
>
> -Melvin
Jeff Clites
> When I was writing the PIO_parse_open_flags() test it did seem to me
> rather Perlish to have string flags in the first place. But I'm a new
> cockroach in town, so I kept my mouth shut, not wanting to get stomped
> on.
>
> If the PIO_F_* flags used by open() were moved up to io.h then they
> could be exported as .constants by config/gen/parrot_include.pl and
> used explicitly.
>
> Various composite flags could be added for convenience.
>
> PIO_F_WRITE_TRUNC (">")
> PIO_F_WRITE_APPEND (">>")
> PIO_F_READ_WRITE ("+<", "+>")
>
> Also, add an INT flag version of open.
>
> inline op open(out PMC, in STR, in INT)
It does seem to make more sense to have the open op take an INT mode, à
la the Unix open(2), and leave the translation from a flags string to
an INT to the language level. This of course leaves the PIO layer less
language-specific, which is good, and it also gets rid of ambiguities
such as whether "<+" is a valid alternative to "+<", or whether "<<<<<"
is valid, or what do do with a mode string such as ";)-", since a bit
in an INT is either set or not, making an INT flag-set unambiguous and
(probably) never invalid.
Here is the list of modes from the open(2) man page on my system; I'm
not sure if this is a subset or a superset of what PIO should support:
O_RDONLY open for reading only
O_WRONLY open for writing only
O_RDWR open for reading and writing
O_NONBLOCK do not block on open or for data to become
available
O_APPEND append on each write
O_CREAT create file if it does not exist
O_TRUNC truncate size to 0
O_EXCL error if create and file exists
O_SHLOCK atomically obtain a shared lock
O_EXLOCK atomically obtain an exclusive lock
JEff