@torvalds · Portland, OR
Linus Torvalds
- Merged PRs
- 72
- Reviews
- 56
- Repos
- 3
- Followers
- 297,753
- Merged
- 85%
torvalds/AudioNoise#28I'm not opposed to this, but I'd love to see some reference to this particular choice of asymmetric clipping function. This seems a reasonable approximation, but I'd have expected JAN 2026torvalds/AudioNoise#26Ok, I think I made a mistake in making the LFO be -1 .. 1 - most LFO users really seem to want a 0 .. 1 range instead. The -1 .. 1 range seemed to make some conceptual sense for a JAN 2026subsurface/libdc#44Is this offset actually guaranteed to be there? What if this isn't a diluent gas at all? IOW, maybe this all shouldn't be conditional on "version 0x24 and CC", but on 'idx' having FEB 2023subsurface/libdc#39.. and then use the helper here too.OCT 2022subsurface/libdc#39Can we add a "array_uint_endian(ptr, size, bigendian)" helper, and just use it here instead of this ugly thing? Please?OCT 2022subsurface/libdc#39Ugh. This is nasty. The 'S' will also trigger on 'STRING', and then we'll rely on that "type_size > 1" check to not do anything. So it works, but.. I'd rather you do something likeOCT 2022subsurface/libdc#36Note that while the parser doesn't look at the string, it *does* look at the model number you pass in. And I think subsurface will get the model number from the descriptor, and looJUN 2022subsurface/libdc#36Hmm. Now we have two entries with the exact same text for vendor/model. It's not obvious in the diff, because the previous entry is about ten lines earlier. It might work, but I'm JUN 2022subsurface/libdc#34This should use DC_ASSIGN_FIELD(), but it's not wrong as-is. I have no idea if those case values are right, but I assume you looked them up somewhere and it all looks sane to me.MAY 2022subsurface/libdc#34This looks fine, but that whole "garmin_parser_get_field()" thing should probably just be deleted, and it should use the standard dc_field_get() helper instead, since it uses all tMAY 2022subsurface/libdc#33Please don't add static variables for something like this. These could easily just be regular automatic variables on the stack with no downside.APR 2022subsurface/subsurface#3443Don't ask me. I didn't want to make changes outside of the actual git_info passing.APR 2022subsurface/subsurface#3443We initialize everything to zero with memset(info, 0, sizeof(*info)); in is_git_repository().APR 2022subsurface/subsurface#3443Nope. See the tests/testgitstorage.cpp and tests/testparseperformance.cpp. Neither of them have that 'git_info' thing for the cleanup phase.APR 2022subsurface/subsurface#3443This is the meat of the question. In many ways, it really would make sense to only save to a git repo that we opened earlier - if for no other reason than the fact that we need to APR 2022subsurface/subsurface#3316Ok, so here the new code did what the old code did. Which was always a bit odd, but at least it doesn't change behavior like above.SEP 2021subsurface/subsurface#3316See, here the old code made sense. It fixes up the one thing it says it should fix up. It does so badly, but still - sensibly. The new code says it clears sensor data, but that's nSEP 2021subsurface/subsurface#3316I don't think this code is sensible. Yeah, yeah, I realize it was copied from previous code, but that previous code wasn't really sensible either, and this change actually expands SEP 2021subsurface/libdc#29Hmm. I think Suunto serial numbers are actually fixed-length, so they _could_ start with a zero, and this will drop them. I doubt it matters in practice, and they have some meaningAUG 2021subsurface/subsurface#3290This looks wrong to me. mb_cstring() doesn't actually increase 'len' at all. It makes sure that there's enough _room_ for 'len', and adds a zero at the end, but the length remains JUL 2021