Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 10 14:41
    Snaipe commented #336
  • Jan 10 09:11
    Bensuperpc closed #335
  • Jan 10 09:10
    Bensuperpc commented #335
  • Jan 10 07:58
    hydrapolic commented #336
  • Jan 10 06:51
    kugel- commented #336
  • Jan 10 05:56
    Snaipe commented #333
  • Jan 09 23:55
    Snaipe commented #223
  • Jan 09 23:52
    Snaipe commented #335
  • Jan 09 23:45
    hydrapolic commented #336
  • Jan 09 23:44
    hydrapolic commented #337
  • Jan 09 23:31
    Snaipe closed #337
  • Jan 09 23:29

    Snaipe on bleeding

    api: fixed zero producing warni… (compare)

  • Jan 09 23:29
    Snaipe closed #330
  • Jan 09 23:28
    Snaipe commented #333
  • Jan 09 23:25
    Snaipe commented #336
  • Jan 09 23:23

    Snaipe on bleeding

    meson: Add/fix options to not-b… (compare)

  • Jan 09 23:23
    Snaipe closed #334
  • Jan 09 23:23
    Snaipe commented #334
  • Jan 09 23:21
    Snaipe commented #337
  • Jan 09 22:26
    hydrapolic opened #337
Ben Turrubiates
@bturrubiates
I haven’t been tracking development on Criterion so wasn’t aware of that change.
Also, that works great. :fire: :sparkles: Thanks
Btw, I looked at the docs for master on readthedocs and didn’t see anything about cr_skip_test, is that just because that change hasn’t made it into master / a stable release yet?
Franklin Mathieu
@Snaipe
yes
the latestdocs should mirror the most current edition
once the stable 2.3.0 release is out, the stable docs will be updated automatically
Ben Turrubiates
@bturrubiates
i hadn’t even noticed that option. thanks!
so I know you mentioned abort/cr_skip_test, but if i want to mark a test as failed if something fails during setup/teardown is abort the best option (or maybe something like cr_assert_fail?)
Franklin Mathieu
@Snaipe
abort is indeed the best solution right now. cr_assert and all of its variant actually longjmp()s, and the jmp_buf isn't setup during setup or teardown
if a initialisation condition fails often, perhaps it's best to actually include it in the test itself and itest it
failures in setup/teardown should probably either mandate a skip, or remain exceptional
also if you call abort in those functions you'll still be notified with a warning that the setup or teardown crashed, which reinforces the fact that it's an exceptional condition
Ben Turrubiates
@bturrubiates
well they shouldn’t fail, i put that stuff in setup/teardown because it’s boilerplate that a whole suite will share. but sometimes it’s useful to be able to error if something in setup/teardown fails. i think it makes sense for abort to be the most obvious choice
yeah, sounds good to me. they shouldn’t fail, if they did then something has gone wrong
Franklin Mathieu
@Snaipe
right. downright exiting for these conditions makes the most sense because you're not explicitely testing that failure
Ben Turrubiates
@bturrubiates
what is the —debug option supposed to do if TYPE is not provided?
the -h output seems to indicate that it’s optional
Franklin Mathieu
@Snaipe
@bturrubiates it chooses a debugging server appropriately depending on the compiler used
gcc/icc make it use gdbserver, clang makes it use lldb-server
Ben Turrubiates
@bturrubiates
Oh, that makes sense. The system I’m working on has clang but not lldb. So I’m getting something like:
bturrubi at blade11 :: ./src/usnic-av-tests -j1 --debug
[----] Criterion v2.3.0-rc1
[====] Running 2 tests from bind_ep:
criterion: Could not spawn test instance: No such file or directory
[1]    23360 abort      ./src/usnic-av-tests -j1 --debug
Franklin Mathieu
@Snaipe
Ah, I thought I made the "No such file or directory" message a bit clearer, but I must've forgot
It should definitely print that the debugging server could not be found
Ben Turrubiates
@bturrubiates
Cool, I don’t think lldb-server works on Linux yet
Franklin Mathieu
@Snaipe
I'm on archlinux, and it works quite well on my end
Ben Turrubiates
@bturrubiates

Oh, weird. I was going off of this paragraph:

LLDB is improving on Linux. While the debugserver has not been ported (to enable remote debugging) Linux is nearing feature completeness with Darwin to debug x86_64 programs, and is partially working with i386 programs. ARM architectures on Linux are untested. For more details, see the Features by OS section below.

Found here: http://lldb.llvm.org/status.html

Franklin Mathieu
@Snaipe
It's probably bleeding edge, as Arch is doing rolling releases
I did not realize that the debugging server wasn't quite ready yet
perhaps it would be better to fallback to gdbserver if lldb-server isn't there
Ben Turrubiates
@bturrubiates
Yeah probably. I used to use Arch, having access to the most up-to-date packages was really nice.
Also, has Criterion always created *.sock files in the tests working directory? Or is that new?
Franklin Mathieu
@Snaipe
it's a side effect of nanomsg, so it's new
Ben Turrubiates
@bturrubiates
Whenever I get that abort due to lldb-server not being found, I also get left with a criterion_$pid.sock
Franklin Mathieu
@Snaipe
there's a pull request pending to put them in /tmp
Ben Turrubiates
@bturrubiates
oh neat. what is nanomsg used for? IPC?
Franklin Mathieu
@Snaipe
on 2.2.x and earlier criterion used pipe() to communicate with the tests, but it caused problems when the pipe buffer overflowed
with nanomsg, the library uses a unix socket for that
Ben Turrubiates
@bturrubiates
is nanomsg in active development right now?
i remember reading something a while ago about nanomsg being a dead project.
Franklin Mathieu
@Snaipe
Yes. It had a bit of a "dead" period near january because of internal disagreements and the maintainer stepping down
but he stepped up again about 3 months ago iirc
Ben Turrubiates
@bturrubiates
oh, so they found a new maintainer?
oh, that’s good.
Franklin Mathieu
@Snaipe
Well we expected someone to step up, but no one did and the project was considered "dead"
I was considering changing for something else at that time, but surprisingly there wasn't any good fit
ZeroMQ is mainly C++ and I'd like the project to remain C-only (plus it wasn't fork-safe, whereas I made a patch for nanomsg to make it fork-safe)
I have a bit more liberty with regards to switching libraries now though, as the new sandbox code calls exec() and doesn't require fork safety
Ben Turrubiates
@bturrubiates
when you say sandbox are you referring to boxfort?
Franklin Mathieu
@Snaipe
yes
Ben Turrubiates
@bturrubiates
oh cool, i saw that but haven’t looked very much into it. looks interesting though
Franklin Mathieu
@Snaipe
BoxFort was designed to completely rewrite the sandboxing code of criterion (which consisted of fork() on unices and a reimplementation of fork() on windows)