6 ms·

I did not know about C-Reduce until just now, and I'm already hooked. This is basically like discovering git bisect for the first time. I'll have to stuff that

by jchw 2y ago

I did not know about C-Reduce until just now, and I'm already hooked. This is basically like discovering git bisect for the first time. I'll have to stuff that into the back of my mind until I run into something where it might fit.

__MatrixMan__ 2y ago
Same story, I can't wait to try this.
geon 2y ago
I ran into some issues with what might be compiler bugs in cc65, a C compiler for the 6502 processor (c64, NES, Apple 1). I might see if I can get this set up. Apparently VICE supports "printing" to a file on the host OS, so I could run my test on the emulator.
brightball 2y ago
...so I just discovered git bisect for the first time and this is pretty cool.
- crdrost 2y ago
  Yes! The actual commands that you have to search up to get it to run automatically without user input, take almost as long to put together as finding the bug that you're finding (in the 80% case, of course there are 20% cases that take forever) but there is something so satisfying about seeing the thing just humming along once you have it set, that just makes it so satisfying.
  - dataflow 2y ago
    > Yes! The actual commands that you have to search up to get it to run automatically without user input, take almost as long to put together as finding the bug that you're finding Funny, I just wrote the exact same thing only to scroll down and see you had the same opinion: https://news.ycombinator.com/item?id=42262579 https://news.ycombinator.com/item?id=42262579
    - crdrost 2y ago
      One nice thing is that, once it's in your shell history, doing it again is really easy. So on a big codebase I was working on, it really did help multiple times and saved more than the initial investment. The frustrating thing is, because it's in your shell history, you have to look it up again after you change jobs...
com2kid 2y ago
Doing this manually was part of my first job out of college on a C/C++ compiler team. Kind of amazing that there is automation that can accomplish the same thing!
pfdietz 2y ago
It's great when combined with random test input generators.
- eru 2y ago
  Yes, most property based testing libraries do this.
  - pfdietz 2y ago
    Hypothesis in particular has a very clever way to do test reduction. The key problem is that if your test generator is enforcing some constraint on the input, it's not necessarily the case that naive pruning will preserve the constraint. Hypothesis has a fairly general way of enforcing that the generated test input continues to satisfy constraints.
    - eru 2y ago
      Yes, Hypothesis is great. And 'shrinkray' mentioned elsewhere in the comments here seems to be by the same author.
dataflow 2y ago
> I did not know about C-Reduce until just now, and I'm already hooked. This is basically like discovering git bisect for the first time. I've known about git bisect for maybe a decade, and used it maybe... twice so far? And I think at least one of those times it took me longer to understand the command line options than it took to just do it manually. YMMV, maybe it's more useful in a larger collaborative codebase, but to me it sounds life-changing in theory but I haven't found it that in practice.
- jchw 2y ago
  It's pretty incredible if I'm trying to find a breakage in a repo I don't understand. Build's failing? Easy enough: git bisect start master v1.1 # Bisect from v1.1 to current master git bisect run cmake --build .build # Find the first commit where `cmake --build` returns non-zero. No need to bother trying to understand the error message, I can go make coffee instead and then just look at the commit that broke it. Also, this is really useful for and in conjunction with Nixpkgs. It's not as useful for personal projects because chances are it won't tell you anything you don't already know.
  - dataflow 2y ago
    > It's pretty incredible if I'm trying to find a breakage in a repo I don't understand. > Build's failing? Easy enough: > It's not as useful for personal projects How often do you run into this situation, though? For your scenario to arise, you need: (1) A repo you're unfamiliar with (which is already unusual for most people... most people spend most of their time working on repositories they've become familiar with) (2) The unfamiliar repo to use standard build commands you already know, which is basically never the case in my experience (even cmake-based projects almost always need variables defined with custom names I don't know beforehand, and the configuration process is so onerous I find the GUI easier) (3) An obscure enough breakage where the output is complete garbage (otherwise the compile error would just tell you the file and line, and git blame would tell you the commit directly) (4) Knowledge that this unfamiliar repo actually would have actually built on your machine at some point (which is often not the case because cmake isn't hermetic and breakages are often due to having the wrong toolchain installed) (5) For the problem to be a mere build error, as opposed to some running of the program that requires investing time to automate (6) For you to not have any sort of prior CI or other form of validation on your dependencies, because you apparently didn't catch even catch a build error when it was introduced (never mind automated testing) I could go on, but these set of circumstances are more or less indistinguishable from ~never to me.

by jchw 2y ago

__MatrixMan__ 2y ago

Same story, I can't wait to try this.

geon 2y ago

I ran into some issues with what might be compiler bugs in cc65, a C compiler for the 6502 processor (c64, NES, Apple 1). I might see if I can get this set up. Apparently VICE supports "printing" to a file on the host OS, so I could run my test on the emulator.

brightball 2y ago

...so I just discovered git bisect for the first time and this is pretty cool.

crdrost 2y ago
Yes! The actual commands that you have to search up to get it to run automatically without user input, take almost as long to put together as finding the bug that you're finding (in the 80% case, of course there are 20% cases that take forever) but there is something so satisfying about seeing the thing just humming along once you have it set, that just makes it so satisfying.
- dataflow 2y ago
  > Yes! The actual commands that you have to search up to get it to run automatically without user input, take almost as long to put together as finding the bug that you're finding Funny, I just wrote the exact same thing only to scroll down and see you had the same opinion: https://news.ycombinator.com/item?id=42262579 https://news.ycombinator.com/item?id=42262579
  - crdrost 2y ago
    One nice thing is that, once it's in your shell history, doing it again is really easy. So on a big codebase I was working on, it really did help multiple times and saved more than the initial investment. The frustrating thing is, because it's in your shell history, you have to look it up again after you change jobs...

com2kid 2y ago

Doing this manually was part of my first job out of college on a C/C++ compiler team. Kind of amazing that there is automation that can accomplish the same thing!

pfdietz 2y ago

It's great when combined with random test input generators.

eru 2y ago
Yes, most property based testing libraries do this.
- pfdietz 2y ago
  Hypothesis in particular has a very clever way to do test reduction. The key problem is that if your test generator is enforcing some constraint on the input, it's not necessarily the case that naive pruning will preserve the constraint. Hypothesis has a fairly general way of enforcing that the generated test input continues to satisfy constraints.
  - eru 2y ago
    Yes, Hypothesis is great. And 'shrinkray' mentioned elsewhere in the comments here seems to be by the same author.

dataflow 2y ago

> I did not know about C-Reduce until just now, and I'm already hooked. This is basically like discovering git bisect for the first time. I've known about git bisect for maybe a decade, and used it maybe... twice so far? And I think at least one of those times it took me longer to understand the command line options than it took to just do it manually. YMMV, maybe it's more useful in a larger collaborative codebase, but to me it sounds life-changing in theory but I haven't found it that in practice.

jchw 2y ago
It's pretty incredible if I'm trying to find a breakage in a repo I don't understand. Build's failing? Easy enough: git bisect start master v1.1 # Bisect from v1.1 to current master git bisect run cmake --build .build # Find the first commit where `cmake --build` returns non-zero. No need to bother trying to understand the error message, I can go make coffee instead and then just look at the commit that broke it. Also, this is really useful for and in conjunction with Nixpkgs. It's not as useful for personal projects because chances are it won't tell you anything you don't already know.
- dataflow 2y ago
  > It's pretty incredible if I'm trying to find a breakage in a repo I don't understand. > Build's failing? Easy enough: > It's not as useful for personal projects How often do you run into this situation, though? For your scenario to arise, you need: (1) A repo you're unfamiliar with (which is already unusual for most people... most people spend most of their time working on repositories they've become familiar with) (2) The unfamiliar repo to use standard build commands you already know, which is basically never the case in my experience (even cmake-based projects almost always need variables defined with custom names I don't know beforehand, and the configuration process is so onerous I find the GUI easier) (3) An obscure enough breakage where the output is complete garbage (otherwise the compile error would just tell you the file and line, and git blame would tell you the commit directly) (4) Knowledge that this unfamiliar repo actually would have actually built on your machine at some point (which is often not the case because cmake isn't hermetic and breakages are often due to having the wrong toolchain installed) (5) For the problem to be a mere build error, as opposed to some running of the program that requires investing time to automate (6) For you to not have any sort of prior CI or other form of validation on your dependencies, because you apparently didn't catch even catch a build error when it was introduced (never mind automated testing) I could go on, but these set of circumstances are more or less indistinguishable from ~never to me.