Alexander Bandukwala

It seems like we have the technology for Star Wars level droids

just one more type parameter bro... just one more....

Seems that way 🙃

What if I added just one more type parameter

How good does Lego think my eyes are?

Is the new Iberia haircut just the caesar?

Does Cookie Crisp go in the cookie aisle or the crisps aisle

Should Graham crackers be in the cookie aisle or the cracker aisle

I just want an upper bound on input size and make sure everything is linear in terms of that.

Honestly, my main case is just if I can guarantee specific HTTP requests are done in constant time that would be great.

I’d like some totality checking. More specifically I’d like some built in time complexity checking.

Is it Friday yet?

Github pr 99/99 files viewed

😮‍💨

Lists should be whitespace delimited and commas should be whitespace

Based off of news coverage you'd think Luka Doncic has lost 300lbs this off-season.

Yeah, it seems like you would want CI to then do something special if the test stop failing, which is some pretty specific behavior. Either way I think this is probably better to also work on your local machine so having it as a first class feature in the test runner makes sense.

Yeah, I've done that too. Problem is if you don't address it soon the branch gets stale, and you still don't notice if someone else happens to fix the bug.

Not sure I understand. You still need to decide if the expected output is the “correct” version or the current bug.

The objective is to fix it in the future. The issue with a ticket is that the bug might be fixed without updating the ticket and often ticket descriptions aren't descriptive enough to fully explain the bug.

When AI stands for All In

This seems great. Looks like there's at least one person that was trying to add it to alcotest github.com/mirage/alcot...

🙏that I don't get nerdsniped into writing a testing framework.

No, but the first test that fails is the one that prints all of the test output. The bigger issue is I don't want to dig through and see if I've broken anything accidentally.

Yeah, we have enough known issues that I'm not working on a single bug at a time. So I'd rather be able to run the remaining tests.

I thought about this but I feel a little wary convincing everyone else I'm working with to do the same.

Sweet, I'll probably just copy this. We're not making our own test runner so I might just end up using test failures for it.

I know want a test runner with user-defined test-result statuses.

Does it scream loudly in some way if it passes? Curious if there's some way to remove the known failure once it's no longer failing.

I've toyed with marking it as skip if it's failing and mark it as a failure if it passes just so I know to check.

Option 2 feels weird because you're locking in broken behavior, but it makes accidental fixes visible and you can link to a bug report for context.

Option 1 is clean: you write the correct test up front and just enable it once the bug is fixed. But skipped tests are easy to forget and you can't tell if you've changed the existing behavior.

How do y’all handle writing tests for bugs that still exist?

1. Write a test for the expected (fixed) behavior and mark it as skipped/ignored

2. Write a test for the current broken behavior, with a comment explaining the bug

Without