[perl #23252] [PATCH] IO seek/tell refactoring
Leopold Toetsch
> Some refactoring in the seek/tell system.
Thanks, applied.
leo
Vladimir Lipskiy
>
> All tests pass for Linux/i386 and MacOS X (thanks Dan)
>
> Windows is untested but I hope i got the things right.
t/pmc/io...............NOK 3# Failed test (t/pmc/io.t at line 37)
# got: 'fdopen failed
# '
# expected: 'ok
# '
t/pmc/io...............NOK 4# Failed test (t/pmc/io.t at line 51)
# got: 'fdopen failed
# '
# expected: 'ok
# '
t/pmc/io...............NOK 5# Failed test (t/pmc/io.t at line 66)
# got: 'ok 1
# ok 2
# not ok 3
# ok 4
# ok 5
# ok 6
# '
# expected: 'ok 1
# ok 2
# ok 3
# ok 4
# ok 5
# ok 6
# '
t/pmc/io...............NOK 19# Failed test (t/pmc/io.t at line 274)
# got: 'Can't spawn ".\parrot.exe --gc-debug t/pmc/io_15.pasm": Bad
fil
e descriptor at lib/Parrot/Test.pm line 61.
# '
# expected: 'ok 1
# Hello Parrot!
# '
# '.\parrot.exe --gc-debug t/pmc/io_15.pasm' failed with exit code 255
# Looks like you failed 4 tests of 19.
t/pmc/io...............dubious
Test returned status 4 (wstat 1024, 0x400)
DIED. FAILED tests 3-5, 19
Failed 4/19 tests, 78.95% okay (less 1 skipped test: 14 okay,
73.68%)
Juergen Boemmels
Thanks for the testing
> t/pmc/io...............NOK 3# Failed test (t/pmc/io.t at line 37)
> # got: 'fdopen failed
> # '
> # expected: 'ok
> # '
> t/pmc/io...............NOK 4# Failed test (t/pmc/io.t at line 51)
> # got: 'fdopen failed
> # '
> # expected: 'ok
> # '
This is a missing implementation of fdopen on windows.
Its not clear to me how this call should behave. PIO_win32_fdopen
takes a Parrot_WIN32_Handle which is actually a void*.
Using the numbers 0,1,2 in this call does not seem right
here. Especially since we decided to drop the integer file handles
(perl #22899).
> t/pmc/io...............NOK 5# Failed test (t/pmc/io.t at line 66)
> # got: 'ok 1
> # ok 2
> # not ok 3
> # ok 4
> # ok 5
> # ok 6
> # '
> # expected: 'ok 1
> # ok 2
> # ok 3
> # ok 4
> # ok 5
> # ok 6
> # '
get_bool calls PIO_eof, which only checks io->flags & PIO_F_EOF. The
win32 read function does not seem to set this flag correct. It looks
correct but without win32 I cant debugg this.
Can you run parrot t/pmc/io_5.pasm in the debugger, break on
PIO_win32_read and look if the line
io->flags |= PIO_F_EOF;
is reached?
> t/pmc/io...............NOK 19# Failed test (t/pmc/io.t at line 274)
> # got: 'Can't spawn ".\parrot.exe --gc-debug t/pmc/io_15.pasm": Bad
> fil
> e descriptor at lib/Parrot/Test.pm line 61.
> # '
> # expected: 'ok 1
> # Hello Parrot!
> # '
> # '.\parrot.exe --gc-debug t/pmc/io_15.pasm' failed with exit code 255
why can't it spawn .\parrot.exe only in this test all other tests seem
to have no problem with spawning. Try to run this test by hand
.\parrot.exe t/pmc/io_15.pasm
> # Looks like you failed 4 tests of 19.
> t/pmc/io...............dubious
> Test returned status 4 (wstat 1024, 0x400)
> DIED. FAILED tests 3-5, 19
> Failed 4/19 tests, 78.95% okay (less 1 skipped test: 14 okay,
> 73.68%)
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
Simon Glover
Thanks, applied.
Simon
Vladimir Lipskiy
> Its not clear to me how this call should behave. PIO_win32_fdopen
> takes a Parrot_WIN32_Handle which is actually a void*.
Yup. I've alredy peeped in io.h, io_win32.c. And as soon as
I get more familiar with PIO, I'll try to say what the fdopen
implementation on windows is a lack of.
> Using the numbers 0,1,2 in this call does not seem right
> here. Especially since we decided to drop the integer file handles
> (perl #22899).
Okay. I'll take a look.
> > t/pmc/io...............NOK 5# Failed test (t/pmc/io.t at line 66)
> > # got: 'ok 1
> > # ok 2
> > # not ok 3
> > # ok 4
> > # ok 5
> > # ok 6
> > # '
> > # expected: 'ok 1
> > # ok 2
> > # ok 3
> > # ok 4
> > # ok 5
> > # ok 6
> > # '
>
> get_bool calls PIO_eof, which only checks io->flags & PIO_F_EOF. The
> win32 read function does not seem to set this flag correct. It looks
> correct but without win32 I cant debugg this.
>
> Can you run parrot t/pmc/io_5.pasm in the debugger, break on
> PIO_win32_read and look if the line
> io->flags |= PIO_F_EOF;
> is reached?
I can't build pdb on win32 with nmake and MSVC, if you meant
that debbuger:
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
pdb.c
pdb.c
link -out:pdb
.obj -nologo -nodefaultlib -debug -pdb:none -machine
:x86 blib/lib/libparrot_s.lib oldnames.lib kernel32.lib user32.lib gdi32.lib
win
spool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
netapi32.
lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib
odbccp32.lib m
svcrt.lib
CVPACK : fatal error CK1003: cannot open file: pdb.exe
LINK : warning LNK4027: CVPACK error
NMAKE : fatal error U1077: 'link' : return code '0x1'
Stop.
Anyway, TIMTOWTDI. I've checked around it's never reached,
'cause ReadFile returns 1 no matter whether you read more than
1 byte or less. I've attached a ????around[1] and now it successfully
passes io_5.pasm on Win32.
> > t/pmc/io...............NOK 19# Failed test (t/pmc/io.t at line 274)
> > # got: 'Can't spawn ".\parrot.exe --gc-debug t/pmc/io_15.pasm":
Bad
> > fil
> > e descriptor at lib/Parrot/Test.pm line 61.
> > # '
> > # expected: 'ok 1
> > # Hello Parrot!
> > # '
> > # '.\parrot.exe --gc-debug t/pmc/io_15.pasm' failed with exit code 255
>
> why can't it spawn .\parrot.exe only in this test all other tests seem
> to have no problem with spawning. Try to run this test by hand
> \parrot.exe t/pmc/io_15.pasm
Bi-bi (~8 .. In itself io_15.pasm is okay. The problem(?) was
that there wasn't close FOO before openning the same file
for writing which the FOO file handle pointed to. The
attachment fixes it.
Though the whole thingy leaves me wondering how the perl
filehandles could be linked with the parrot io objects.
A mending in the attachment fixes the problem(?).
..
[1] wurgaround.
Leopold Toetsch
> Bi-bi (~8 .. In itself io_15.pasm is okay. The problem(?) was
> that there wasn't close FOO before openning the same file
> for writing which the FOO file handle pointed to. The
> attachment fixes it.
Thanks, applied.
leo
Simon Glover
Thanks, applied.
Simon
Vladimir Lipskiy
>through the pasm code. This smells like makefile problems. Can you try
>the attached patch?
WORKS! I'm out of English words; I just run mandel.pbc in pdb
and it printed out such a cool Mandel bug or whatever(or maybe
even Leon Brocard's fingerprints, who knows). Wow!
>perl is running during the test keeping the file open. Parrot also
>tries to open this file, does not catch this error and failes badly.
>But why 'Can't spawn'?
Nevermind. PIO has no concern with "Can't spawn". While make test I get
this error every time after my windows 2000 spits out qq/Intsruction to
the address (e.g.) 0x00401a8c addressed to memory to the address
0x00000069. Memory can't be "read"/; I received the error either when
we had problems(at least on Win32) with printf formats in t/op/string.t.
For example on my computer a test based on this C-code
int main(int argc, char **argv) {
printf("ok %s", 's');
return 0;
}
will end up with the same "Can't spawn".
Vladimir Lipskiy
> Its not clear to me how this call should behave. PIO_win32_fdopen
> takes a Parrot_WIN32_Handle which is actually a void*.
To my mind the imlementation is fine.
> Using the numbers 0,1,2 in this call does not seem right
> here. Especially since we decided to drop the integer file handles
> (perl #22899).
The main problem here is that 0, 1, 2 make no sense in
windows. Win32 API uses handles of the type HANDLE,
which, as you already told, is actually void*, and not
file descriptors. I bet that PIO_stdio_fdopen doesn't
work either, since stdio makes use of FILE*, you know.
I like your PIOHANDLE abstraction, why not to intdroduce
yet another one but over the 3rd parameter of PIO_*_fdopen.
I presume it won't hurt us much. The abstraction could be
incarnated as a new pmc named parrotfd. Then we would be
allowed to have
inline op getfd(out PMC, in PMC) {
and
inline op fdopen(out PMC, in PMC, in STR) {
Beyond doubt this will solve the problem of fdopen
and we will be able to get rid of numbers forever.
The io_3.pasm test could look the following way
output_is(<<'CODE', <<'OUTPUT', "fdopen");
getstdout P0
getfd P1, P0
fdopen P2, P1, ">"
defined I0, P2
unless I0, nok
print P2, "ok\n"
close P2
end
nok:
print "fdopen failed\n"
end
CODE
ok
OUTPUT
What do you think?