Sebastien Marie <sema...@online.fr> writes: > On Fri, Nov 16, 2018 at 01:28:35PM +0100, Sebastien Marie wrote: > >> On Fri, Nov 16, 2018 at 10:13:24AM +0200, Timo Myyrä wrote: >> > >> > Ok, here's new diff to fix the tests to use new binary names. >> > Though there seems to be some issue with the tests, now the tests get >> > stuck on >> > 'ports test' phases 'fast' test on my amd64. Could somebody check how the >> > test >> > function with other arches? >> >> with plain chicken-5.0.0, I have no problem with tests (on amd64). >> >> I will retest it with the rename. > > Here, it is fine (amd64). > > ======================================== port tests ... > == ports == > (PASS) Initially, output string is empty > (PASS) output can be extracted from output string > (PASS) closing a string output port has no effect on the returned data > (PASS) writing to a closed string output port is an error > slow... > 0.33s CPU time, 15924/2656 mutations (total/tracked), 1/999 GCs > (major/minor), maximum live heap: 544.02 KiB > fast... > 0s CPU time, 56/13 mutations (total/tracked), 0/1 GCs (major/minor), maximum > live heap: 543.85 KiB > > > Procedures check on TCP ports being closed > > tcp-addresses...OK > tcp-port-numbers...OK > tcp-abandon-port...OK > > > Procedures check on output ports being closed > > write...OK > fprintf...OK > print-call-chain...OK > print-error-message...OK > print...OK > print*...OK > display...OK > terminal-port?...OK > newline...OK > write-char...OK > write-line...OK > write-u8vector...OK > flush-output...OK > file-test-lock...OK > file-lock...OK > file-lock/blocking...OK > write-byte...OK > write-string...OK > > > Procedures check on input ports being closed > > read...OK > read-char...OK > char-ready?...OK > peek-char...OK > terminal-port?...OK > read-line...OK > read-u8vector...OK > read-u8vector!...OK > file-test-lock...OK > file-lock...OK > file-lock/blocking...OK > read-byte...OK > read-token...OK > read-string...OK > read-string!...OK > > Embedded NUL bytes in filenames are rejected > > > read-line string port position tests: > > (PASS) advance row when encountering delim > (PASS) reaching limit sets col to limit, and does not advance row > (PASS) delimiter counted in limit > (PASS) EOF reached > > read-string!: > > (PASS) peek-char won't influence the result of read-string! > (PASS) read-string! won't read past buffer if given #f > (PASS) read-string! reads the requested bytes with #f > (PASS) read-string! won't read past buffer if given #f and offset > (PASS) read-string! reads the requested bytes with #f and offset > (PASS) read-string! reads until the end correctly > (PASS) read-string! leaves the buffer's tail intact > (PASS) after peek-char at EOF, read-string! doesn't mutate the buffer > (PASS) read-string! won't read past buffer if given size > (PASS) read-string! reads the requested bytes with buffer size > (PASS) read-string! won't read past buffer if given size and offset > (PASS) read-string! reads the requested bytes with buffer size and offset > (PASS) read-string! reads until the end correctly with buffer size > (PASS) read-string! leaves the buffer's tail intact > (PASS) read-string! at EOF reads nothing > (PASS) read-string! at EOF doesn't mutate the buffer > > line endings: > > > string port: > > (PASS) \n > (PASS) \r > (PASS) \r\n > (PASS) eof > > file port: > > (PASS) \n > (PASS) \r > (PASS) \r\n > (PASS) eof > > custom port: > > (PASS) \n > (PASS) \r > (PASS) \r\n > (PASS) eof > 36 tests completed in 7.128 seconds > 36 (100.00%) tests passed > 0 (0.00%) tests failed > -- ports -- > > > TOTALS: > 36 tests completed in 7.128 seconds > 36 (100.00%) tests passed > 0 (0.00%) tests failed
Hmm, odd. For me it always get stuck on port tests after printing the fast: ======================================== port tests ... == ports == (PASS) Initially, output string is empty (PASS) output can be extracted from output string (PASS) closing a string output port has no effect on the returned data (PASS) writing to a closed string output port is an error slow... 0.12s CPU time, 15924/2656 mutations (total/tracked), 1/999 GCs (major/minor), maximum live heap: 544.04 KiB fast... 0s CPU time, 56/13 mutations (total/tracked), 0/1 GCs (major/minor), maximum live heap: 543.87 KiB I don't have a clue yet what could cause this. Could it be hardware thing as ryzen laptops aren't that well supported yet. The test worked without the name change on this laptop in any case. Timo
