This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "UNNAMED PROJECT".
The branch, master has been updated
via e6d26ec09c2bcd2126416a58cb23af27318ec67e (commit)
via 5382e0fc1f5c30532b5b2b322601c9d4a8d4f982 (commit)
via dd1700a397379e9383b9577fca09738b3251fc7c (commit)
via 7783964bb92af9ef6a1d1d12a6b804aab48945b0 (commit)
from 0a8fae8d141c2cfa4387ffe9b35402d5b8cc85cd (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/osmo-pcu/commit/?id=e6d26ec09c2bcd2126416a58cb23af2…
commit e6d26ec09c2bcd2126416a58cb23af27318ec67e
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Mon Mar 27 00:13:14 2017 +0200
bitcomp test: use expected rc instead of 'verify' flag
The 'verify' flag is useless, we always want to verify everything. Replace
'verify' with 'expect_rc', expecting a specific decoding result per
test set.
When an error code was returned, cut short the loop and skip printing expected
vs. decoded bits.
This uncovers the fact that the first test marked as "invalid inputs" does
not
seem to be invalid after all, or at least does not produce an error to be
returned. For now, only uncover this fact, the fix shall be submitted later.
Change-Id: Icf815a8f1acb0e275463408450171df046879847
http://cgit.osmocom.org/osmo-pcu/commit/?id=5382e0fc1f5c30532b5b2b322601c9d…
commit 5382e0fc1f5c30532b5b2b322601c9d4a8d4f982
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Sun Mar 26 23:39:44 2017 +0200
bitcomp test: fix: also verify bits after decoded data
Before this, the expected data had seemingly random bits set after the end of
the expected decoding result. Make the test expect these extra bits as zero,
matching with the buffer initialization to zero.
In result_matches(), compare the full length of bytes instead of masking the
bits after the end of the decoded data (which caused us to not catch the wrong
expectation until now).
This fixes the underlying issues found in
http://lists.osmocom.org/pipermail/osmocom-net-gprs/2017-March/000876.html
[osmo-pcu 0.2.896-0a8f] testsuite: 4 failed
from: Arnaud ZANETTI
on: Fri Mar 24 09:53:53 UTC 2017
Change-Id: I2501208e2f8b4f709efbcadbd1057c086472c9e6
http://cgit.osmocom.org/osmo-pcu/commit/?id=dd1700a397379e9383b9577fca09738…
commit dd1700a397379e9383b9577fca09738b3251fc7c
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Sun Mar 26 23:21:16 2017 +0200
bitcomp test: fix: only one hexdump per log; use printf
The test wants to write multiline results, so it should use printf instead of
the logging system.
Split logs to only one hexdump per printf(). One cannot use osmo_hexdump twice
in one printf(); before this, one of the two hexdumps won, both dumps would
show as the same. Very bad for a regression test!
This uncovers a discrepancy between expected and produced results, proving that
the expected stderr output was not capable of uncovering test failures. The
test's check_result() function *has* always verified the decoded data, but only
up to the last decoded bit. Our expected data contains seemingly random bits
after the end of the decoded bits, but check_result() never compares those,
hence we don't catch that error. The extra bits should definitely be zero,
because the destination buffer is pre-initialized to zero -- fixed in a
subsequent patch.
This should cosmetically fix the build failure found in:
http://lists.osmocom.org/pipermail/osmocom-net-gprs/2017-March/000876.html
[osmo-pcu 0.2.896-0a8f] testsuite: 4 failed
from: Arnaud ZANETTI
on: Fri Mar 24 09:53:53 UTC 2017
The real fix will follow.
Change-Id: I24fc32eb55baaf22f9c6fdda917bfb8395d02b1c
http://cgit.osmocom.org/osmo-pcu/commit/?id=7783964bb92af9ef6a1d1d12a6b804a…
commit 7783964bb92af9ef6a1d1d12a6b804aab48945b0
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Sun Mar 26 23:12:26 2017 +0200
cosmetic: BitcompTest: make readable
In order to understand what the bitcomp test is logging, cosmetically rearrange
the code:
- memset bits_data before assigning to destination bitvec.
- use macro CEIL_DIV_8 to clarify what (x+7)/8 does.
- rename check_result() to result_matches() and return a bool,
also constify result_matches() args and pass a bitvec reference instead of
copying the bitvec struct.
- rearrange logging lines to make readable what is going on there.
- drop unused 'init_flag'
There are obviously errors like double hexdumps per log line, multiple newlines
in a LOGP statement and so forth: these shall be fixed by subsequent patches.
Change-Id: Id0da9d9b67f4713d3a67e3532ed44b8cb1bd1d08
-----------------------------------------------------------------------
Summary of changes:
tests/bitcomp/BitcompTest.cpp | 132 ++++++++++++++++++++++--------------------
tests/bitcomp/BitcompTest.err | 33 +++++------
2 files changed, 85 insertions(+), 80 deletions(-)
hooks/post-receive
--
UNNAMED PROJECT