Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 12 17:28
    Snaipe commented #304
  • Oct 12 12:13
    Snaipe commented #304
  • Oct 12 11:43
    Snaipe commented #305
  • Oct 12 00:25
    ntuDerekWang opened #305
  • Oct 09 10:43

    Snaipe on master

    (compare)

  • Oct 09 10:41

    Snaipe on bleeding

    Struct pointer references use -… (compare)

  • Oct 03 16:05
    vincentdupaquis commented #304
  • Oct 02 15:20
    vincentdupaquis commented #304
  • Oct 02 15:19
    Snaipe commented #304
  • Oct 02 14:58
    vincentdupaquis commented #304
  • Oct 02 14:56
    Snaipe commented #304
  • Oct 02 14:28
    vincentdupaquis commented #304
  • Oct 02 13:45
    vincentdupaquis commented #304
  • Oct 02 13:37
    vincentdupaquis commented #304
  • Oct 02 12:19
    Snaipe commented #304
  • Oct 02 10:52
    vincentdupaquis commented #304
  • Oct 02 10:49
    vincentdupaquis opened #304
  • Sep 26 21:38
    Snaipe commented #287
  • Sep 26 08:42
    am11 commented #287
  • Sep 25 14:48
    Snaipe commented #303
Franklin Mathieu
@Snaipe
if my memory of man pipe serves well, this shouldn't happen
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