Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 24 18:56
    Wes974 commented #290
  • Nov 24 14:21
    Wes974 commented #290
  • Nov 17 12:42
    Nekyt closed #364
  • Nov 13 15:08
    Nekyt commented #364
  • Nov 13 14:27
    Nekyt commented #364
  • Nov 11 21:22
    Snaipe commented #364
  • Nov 11 20:35
    Nekyt commented #364
  • Nov 11 20:34
    Nekyt reopened #364
  • Nov 11 20:30
    Nekyt commented #364
  • Nov 11 20:30
    Nekyt closed #364
  • Nov 11 19:18
    Nekyt opened #364
  • Nov 08 08:18
    zcorniere opened #363
  • Nov 03 18:28
    madebr commented #336
  • Nov 03 18:28
    madebr commented #336
  • Oct 22 11:46
    risaldar closed #356
  • Oct 15 06:49
    khuang0312 edited #362
  • Oct 15 06:46
    khuang0312 edited #362
  • Oct 15 06:45
    khuang0312 edited #362
  • Oct 15 06:45
    khuang0312 opened #362
  • Oct 06 22:59
    Eazhi synchronize #361
Dominik
@kaidowei
where can I see the results of the cram test?
it just says, it failed
Franklin Mathieu
@Snaipe
oh, right, I'm assuming you don't have cram installed on your system
install cram 0.6 with sudo pip install cram==0.6 (or with --user if you don't want to install it in /usr)
Dominik
@kaidowei
I have... if I remember correctly, we had this conversation some time ago
Franklin Mathieu
@Snaipe
okay
in doubt, run make cram_tests
and to troubleshoot with ctest, you need to pass it an option
let me check which one
--output-on-failure
Dominik
@kaidowei
[100%] Built target criterion_samples
CMake Error at /*beep*/Criterion/.cmake/Modules/Cram.cmake:66 (message):
  Cram tests failed


make[3]: *** [cram_tests] Error 1
make[2]: *** [test/CMakeFiles/cram_tests.dir/all] Error 2
make[1]: *** [test/CMakeFiles/cram_tests.dir/rule] Error 2
make: *** [cram_tests] Error 2
Franklin Mathieu
@Snaipe
huh.
let me check on my end
oh, it's a bug in the cmake module, somehow
try export PYTHON_BIN=python3
and re-run the tests
I'll push a fix to address the case where PYTHON_BIN isn't set
Dominik
@kaidowei
yeah, works
Dominik
@kaidowei
mkay, did my part :)
Franklin Mathieu
@Snaipe
Thanks!
Dominik
@kaidowei
uuuh, just noticed, that the locale print sometimes prints "0,05" instead of "0.05"
do you think, xml parsers mind?
Franklin Mathieu
@Snaipe
oh, right
Dominik
@kaidowei
damn it
Franklin Mathieu
@Snaipe
well, according to the standard, xs:decimal needs a dot
actually, let me rephrase: the internet is telling me that the standard says that it needs a dot
Let me check for sure
so how do we fix that?
Franklin Mathieu
@Snaipe
well, you could swap the locale, but you'll have to restore it afterwards
Dominik
@kaidowei
that really stinks...
how did you do that for the other output providers?
Franklin Mathieu
@Snaipe
Other output providers doesn't have this restriction
and I didn't have any floats to print anyway, so that's why
Dominik
@kaidowei
that's not entirely true, the --tap option also prints floats
Franklin Mathieu
@Snaipe
I guess the cleanest way (as in, reusable for other output providers) would be to implement a compatibility function for this
yes, but tap doesn't have the restriction, iirc the time is part of a comment string
so using the locale here is the right thing to do
Dominik
@kaidowei
okay...
the jenkins tap parser had problems finding the time, but I guess that is a problem of the tap-format
(and the locale, maybe)
Franklin Mathieu
@Snaipe
this is precisely why I'm not testing the timestamps in cram
because the way to print time just isn't consistent
Dominik
@kaidowei
so the xml.t should be removed? (which is also not a good thing)
Franklin Mathieu
@Snaipe
no, but xml.t will probably not have time measurements anyway
I mean, time is disabled for tests because you can't really compare two times textually
well, you can, but I mean it's not reliable
because one test might take 1ms to complete one time, and 2ms the other time
Dominik
@kaidowei
okay... amend this pull request or make another one?