I wasn't while cycling, it was when resting or at night sleeping. Could have been dehydration related, but i usually drink a LOT during and afterwards.
No sure about brain harm. But I used creatine for a few months and I got cramps in an intensity like I never experienced before.
I then decided it was not worth it for a few watts of cycling FTP increase. So I would not consider it harmless for everbody, but this sideeffect seems pretty rare.
Nice, but it's too late I needed a different API for future use in my custom sprintf so I made mulle-dtostr (https://github.com/mulle-core/mulle-dtostr). On my machine (AMD) that benchmarked in a quick try quite a bit faster even, but I was just checking that it didn't regress too badly and didn't look at it closer.
Can anyone comment on the "You can exceed the amperage specs" ? I made myself a little case study using 4x1W panels and using them in series and parallel. I got the distinct impression that running panels in parallel is better in not so bright conditions compared to a single panel. Whereas a serial configuration made it worse. Since the sun doesn't shine here that much. Running in parallel seems to be preferable, but it would slightly exceed the amperage spec of a few converter i sampled.
People should get on the bike and start cycling for real (like burn 200W an hour). Their perception of glucose will flip 100%. Suddenly glucose is like the fuel to your body, that you can't cram enough into. Which means white bread in the morning, croissants (and coca cola with sugar) will be your friends. Quite frankly a much better lifestyle.
I have been using https://github.com/marty1885/landlock-unveil on Linux for about two years now on my stock Ubuntu kernel. I am not sure, why this hasn't become more popular. It's also rootless sandboxing (and it does `unveil` like OpenBSD I guess). I use it to confine builds of third party software with success.
Cool. I forgot to mention, that I am truncating the hash down to 32 bits to hopefully generate tighter CPU instructions. At these few bits, collisions are still rare enough, but they are a concern.
Now my understanding of the choice of prime is that, you are "weighing" the input bits and the computed bits, that will form the hash. So in case of identifiers its very likely that bit 7 of the input is always 0 and say maybe bit 4 is statistically more likely to be 1 by some margin. The other input bits would have some entropy as well. I would expect that certain (imperfect) primes would then aid me to get a better use of the 32 bit space and therefore less risk of a collision for my Objective-C runtime.
I am using fnv-1a to hash Objective-C method selectors, which are generally just identifier characters and zero or multiple ':'. At the time of my research, fnv-1a had the least collisions over my set of "real life" selectors. I think, it could be worthwhile some time, to try out other constants for maybe even less collisions. Is your list of good primes available ? (And maybe also those that are not quite perfect)
I think for sports, I could wrap all the various mulle-sde and mulle-bashfunction files back into one and make it > 100K lines. It wouldn't even be cheating, because it naturally fractalized into multiple sub-projects with sub-components from a monolithic script over time.
I tried it on two of my git repositories, just to see, if it could do a decent commit summary. I was very pleasantly surprised with the good result.
I was unpleasantly surprised, that this already cost me 175 credits. If I extrapolate this over my ~100 repositories, that would already put me at 8750, just to let it write a commit message for release day. That is way out of free range and basically would eat up most of the $99 I would have to spend as well. My subscription price for cody is $8 for a month. Pricing seems just way off.
I would assume this is completely standard. The ear doctor I went to, and that guy was noone "fancy", did this and that must have been more then 10 years ago.