Earlier quoted context omitted.
Its cousin diff is also very handy.
Not a command line guru, but this looks interesting. Does it compare outputs of two commands? How does it do it?
$ ls diff diff /dev/fd/62 /dev/fd/63Bug #915: Please help
21–30 of 97 posts
Re: Bug #915: Please help
#22Earlier quoted context omitted.
Its cousin diff is also very handy.
Not a command line guru, but this looks interesting. Does it compare outputs of two commands? How does it do it?
It is called process substitution and specific to Bash (not POSIX shell compliant). The output of the commands in parenthesis will become runtime (file) inputs for the diff command.
More: https://www.gnu.org/software/bash/manual/html_node/Process-S...
Re: Bug #915: Please help
#23Earlier quoted context omitted.
Its cousin diff is also very handy.
Not a command line guru, but this looks interesting. Does it compare outputs of two commands? How does it do it?
diff compares files line by line, here we just redirect the output of cmd1 and cmd2 via you might want to read into redirection on the commandline, it's amazingly powerful
Re: Bug #915: Please help
#24Earlier quoted context omitted.
Its cousin diff is also very handy.
Not a command line guru, but this looks interesting. Does it compare outputs of two commands? How does it do it?
It might be easiest to view it like so:
$ echo The command above with >(grep something) does the same thing, just with the other end of a pipe.
Re: Bug #915: Please help
#25Earlier quoted context omitted.
Its cousin diff is also very handy.
Not a command line guru, but this looks interesting. Does it compare outputs of two commands? How does it do it?
The
$ echo $ cat EDIT: Heh, 5 different replies within the same 60 second window.
Re: Bug #915: Please help
#26Earlier quoted context omitted.
Its cousin diff is also very handy.
Not a command line guru, but this looks interesting. Does it compare outputs of two commands? How does it do it?
Yes. You're directing the STDOUT of each command as a FILE into diff. Diff takes two files, thus the duplication.
Re: Bug #915: Please help
#27As mentioned on the Github issue [1], I'd suspect their SQLite optimizations: self.execute("pragma journal_mode=off").close() # This pragma makes writing faster. self.execute("pragma synchronous=off").close() I've always used WAL journaling mode, and NORMAL synchronous mode. [1] https://github.com/nedbat/coveragepy/issues/915
I have tried removing the two pragmas, and the problem still happens.
Neither of those make much sense as the cause anyway. Both sacrifice database consistency if the hosting process crashes or os crashes or reboots due to power failure, but with something like a coverage database, neither is particularly worrying. Worst case the users nukes the db, and reruns the tests.
Even if removing those pragmas fixed things, it feels likely that would just be hiding the issue instead of fixing it.
Disk io errors are not supposed to happen in sqlite except in cases like: accessing a corrupted database, drives failing or running out of disk space, bad permissions on some folder sqlite needs to write to.
So unless the test case involves a python process crashing or getting killed, I question if this is actually a bug in your your code.
I feel like this being some bug in either sqlite, or in the file systems used by docker (specifically by behaving in some manner not anticipated by sqlite).
With those optimizations, the only remaining sqlite disk IO should be the database itself, and the temp store. Since I stronly suspect the error you are getting is coming from sqlite, it would be helpful to know which of those two disk io cases it is.
Perhaps you can try the pragma to force the temp store to be in memory? The results of that might help us know if the disk io error is in reading/writing the database file itself, or if it is in reading/writing temp files.
Knowing that could narrow things down a bit.
Re: Bug #915: Please help
#28This is an editorialized title and as far as I know it's not even accurate. The author maintains, but did not create coverage.py. (Edit: Original title has been changed, so this comment is no longer necessary.)
Looking at the commit history, he is the author of almost all the code written in the last ten years. Even if there was someone before him (who was it? I couldn't find any reference to them), how could we not consider him the author of the project by now?
The original title made reference to Ned as the "creator of coveragepy", which specifically means the person who created it. The original author was Gareth Rees, according to Contributors.txt [1], and Ned Batchelder took over in 2004.
I don't mean it to suggest that Ned has a lessor role than creator, just that the post's title was changed to add inaccurate information. I figured that if the moderators saw this and decided that the context of the author's role in Coverage was important, they could update the title to reflect his actual role.
[1] https://github.com/nedbat/coveragepy/blob/master/CONTRIBUTOR...
Re: Bug #915: Please help
#29Earlier quoted context omitted.
Not a command line guru, but this looks interesting. Does it compare outputs of two commands? How does it do it?
It might be easiest to view it like so: $ echo The shell spawns two commands connected to pipes, then replaces those with a file that represents the other (read) side of that pipe. The command above with >(grep something) does the same thing, just with the other end of a pipe.
It's not actually a pipe. >, This is explained in more detail here:
https://askubuntu.com/questions/172982/what-is-the-differenc...
Re: Bug #915: Please help
#30Earlier quoted context omitted.
Looking at the commit history, he is the author of almost all the code written in the last ten years. Even if there was someone before him (who was it? I couldn't find any reference to them), how could we not consider him the author of the project by now?
The original title made reference to Ned as the "creator of coveragepy", which specifically means the person who created it. The original author was Gareth Rees, according to Contributors.txt [1], and Ned Batchelder took over in 2004. I don't mean it to suggest that Ned has a lessor role than creator, just that the post's title was changed to add inaccurate information. I figured that if the moderators saw this and d…
Sorry, I missed the obvious place to look into it.