dnouri

Oh that sounds neat. I'll need to check out your extension!

Nice! I'm curious to hear how you're mapping `read` and `write` to Emacs buffers. Does that mean those commands open those files in Emacs and read and write them there?

Let me also drop a link to the Pi Emacs mode here for anyone who wants to check it out: https://github.com/dnouri/pi-coding-agent -- or use: M-x package-install pi-coding-agent

We've been building some fun integrations in there like having RET on the output of `read`, `write`, `edit` tool calls open the corresponding file and location at point in an Emacs buffer. Parity with Pi's fantastic session and tree browsing is hopefully landing soon, too. Also: Magit :-)

Interesting question. However, I haven't worked with those kinds of tests before.

It looks like there's two pytest plugins at least to support you with that:

- Mutatest: Python mutation testing: https://mutatest.readthedocs.io/

- Mutagen: https://github.com/timpaquatte/pytest-mutagen

Let me know how it goes.

I covered a gap by blogging about: Modern Python CI with Coverage in #2025

Let me know in the comments if you think it's useful.

From the table of contents:

    Our toolchain
        py-cov-action: GitHub-native coverage
            The two-workflow pattern for fork PRs
        pytest-xdist: Parallel testing by default
        uv: Fast package management
    Six critical gotchas
        Gotcha #1: Using coverage run -m pytest with xdist
        Gotcha #2: Missing relative_files = true
        Gotcha #3: Hidden files excluded from artifacts
        Gotcha #4: Fork PRs can't post comments
        Gotcha #5: Missing pytest-cov plugin
        Gotcha #6: E2E tests with subprocesses contribute 0% coverage
    Complete working example
        .github/workflows/ci.yml
        .github/workflows/post-coverage-comment.yml
        pyproject.toml configuration
    Verifying your setup
        Check relative paths
        Verify artifact upload
        Test fork PR comments
        What success looks like
    Migration notes
        From Codecov/Coveralls
        From pip to uv
    Next steps
    Resources

An interesting idea. Yes, you can usually use a convnet with any number of channels per pixel.

The nice thing about these convolutional neural nets is that they're not convoluted at all. ;-) It's basically feed the raw data, in this case spectrograms. Traditional approaches in this field are usually much more convoluted, because they involve a complex feature extraction part. Which tends to be specific to a certain species.

And third-place winner of the second whale challenge :-) https://www.kaggle.com/c/the-icml-2013-whale-challenge-right...

This second challenge actually featured a different dataset with different hydrophones used etc. But even without retraining (which was rather trivial to do at that point; the hard work of finding the right hyper parameters had already been done), I would have still scored well above 90%. And I think Nick Kridler reported the same.

So overfitting yes, but not too much considering there was a different sensor.