Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 14 16:25
    Snaipe commented #301
  • Sep 13 19:26
    Snaipe commented #302
  • Sep 13 19:21
    Snaipe commented #302
  • Sep 13 17:36
    MrAnno commented #301
  • Sep 13 17:35
    MrAnno commented #301
  • Sep 13 15:28
    kugel- commented #302
  • Sep 13 15:26
    kugel- commented #302
  • Sep 13 15:14
    Snaipe labeled #302
  • Sep 13 15:14
    Snaipe labeled #302
  • Sep 13 15:14
    Snaipe labeled #302
  • Sep 13 15:14
    Snaipe assigned #302
  • Sep 13 15:14
    Snaipe opened #302
  • Sep 13 14:55

    Snaipe on actions

    ci: setup basic actions yaml (compare)

  • Sep 11 08:33
    MrAnno opened #301
  • Sep 03 18:13
    Fumesover closed #300
  • Sep 03 18:13
    Fumesover commented #300
  • Sep 03 18:02
    Fumesover edited #300
  • Sep 03 18:02
    Fumesover edited #300
  • Sep 03 17:32
    Fumesover opened #300
  • Aug 26 18:59
    4lph4-Ph4un closed #298
Dominik
@kaidowei
just a normal ubuntu 14.04
and the coworkers system is linux mint version... I don't know
Franklin Mathieu
@Snaipe
it's more probable that I screwed up the message passing in a very subtle way
but in the meantime, consider using explicit assert messages for these assertions
Dominik
@kaidowei
yes, we're doing that already
Franklin Mathieu
@Snaipe
otherwise you'll also get hit by the cost of transfering a +8 << 20 bytes assert message
I wonder
maybe the default message for these assertions isn't the best choice
the default message could only pass a minimal diff of both data
Dominik
@kaidowei
yeah, catting the whole file might not be the best idea
diff is a cool idea
but relies on external libs/programs
Franklin Mathieu
@Snaipe
also, it's hardly an inline display
plus, it assumes that the file/strings aren't binary data
Dominik
@kaidowei
right
Franklin Mathieu
@Snaipe
which also makes me realize that there should really be assertion functions to compare a file to a byte array
not all files are text
Dominik
@kaidowei
:+1:
Dominik
@kaidowei
@Snaipe we need to use an old compiler (gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2)
Dominik
@kaidowei
and it works for c, but not c++

we identified

        stdio_sync_filebuf(stdio_sync_filebuf&& other) = default;
        stdio_sync_filebuf& operator=(stdio_sync_filebuf&& other) = default;

to be the problem. when commented out, our cpp tests compile

are those really important?
can we guard them with # if __cplusplus > 199711L?
Franklin Mathieu
@Snaipe
@kaidowei sure, but how are your tests compiling without C++11? Does GCC 4.5.2 support c++11 lambdas?
Dominik
@kaidowei
yes
"Improved experimental support for the upcoming C++0x ISO C++ standard, including support for raw strings, lambda expressions and explicit type conversion operators."
Dominik
@kaidowei
btw what are those lines for? doesn't the compiler set default by default?
Franklin Mathieu
@Snaipe
the default implements these operations with std::move, rather than operator=.
as for why these lines are there, the old implementation of the sync filebuf used a std::unique_ptr, so both lines were needed for the move semantics
now they are just there for correctness with the C++11 standard
putting them in conditionals is fine
Dominik
@kaidowei
mkay, thanks :)
Dominik
@kaidowei
http://pastebin.com/3diuCx5k if you're interested
Dominik
@kaidowei
@Snaipe are there any news about the fix? :)
I mean the fix for the looooong strings
Franklin Mathieu
@Snaipe
Haven't really got the time to work on criterion this week (kernel programming courses are taking most of my time), but I'll see to it at least this weekend
Franklin Mathieu
@Snaipe
So, I was able to track down why the bug is happenning
this happens because write(2) is atomic only if the input data is less than the size of the pipe buffer
fixing this would require me to rewrite the I/O layer, so I can't fix this for a patch
and the current bleeding branch doesn't have the issue anyways
Dominik
@kaidowei
You could change the way, the message is created. 'First diff is in line XYZ' and maybe show the string around that line.
Anyway, is there a date, when bleeding is becoming stable?
Franklin Mathieu
@Snaipe
This wouldn't really fix the underlying problem, because statistics should get the full payload
as for bleeding, I'm still considering what needs to be done, since there are a few issues with nanomsg currently
the projects doesn't have any maintainer, so any issues down the line with the library will have to be my responsibility
I'm considering rewriting my own I/O library for that purpose, but I don't really want to lose months on it either
(and even less so if nanomsg is still a near perfect fit and quite stable.)
Dominik
@kaidowei
@Snaipe in the documentation http://criterion.readthedocs.org/en/master/parameterized.html
the code for Passing multiple parameters is bugged
if I use that, criterion gives my test garbage