HN user

mulle_nat

565 karma

Senior Mull - Mulle kybernetiK

twitter: @mulle_nat twitch : https://www.twitch.tv/mulle_kybernetik_tv blog : https://www.mulle-kybernetik.com/weblog

Posts25
Comments111
View on HN
newatlas.com 2y ago

All-in-one polychromatic LEDs replace RGB for sharper screens

mulle_nat
12pts2
felipec.wordpress.com 2y ago

The stupidity and arrogance of GNOME developers

mulle_nat
10pts3
mamoniem.com 3y ago

Behind the pretty frames of Diablo IV

mulle_nat
2pts0
www.techradar.com 3y ago

Apple just lost its lawsuit trying to ban iOS virtual machines

mulle_nat
636pts328
www.mulle-kybernetik.com 4y ago

Modern Bash (Zsh) Scripting – New Tricks for an Old Shell

mulle_nat
4pts0
www.mulle-kybernetik.com 6y ago

My C code works with -O3 but not with -O0

mulle_nat
177pts159
www.mulle-kybernetik.com 7y ago

The C standard library function atexit is broken

mulle_nat
99pts99
www.mulle-kybernetik.com 7y ago

The beauty of generic header-names

mulle_nat
11pts3
www.mulle-kybernetik.com 7y ago

Show HN: Mulle-match-to-cmake generate cmake files from the filesystem

mulle_nat
2pts0
www.mulle-kybernetik.com 7y ago

Show HN: Cross-platform Objective-C, now with IDE and dependency management

mulle_nat
7pts0
github.com 9y ago

Show HN: Edit Xcode build settings from the command line

mulle_nat
1pts0
www.mulle-kybernetik.com 9y ago

Various C Compilers disappointing optimization results

mulle_nat
2pts0
github.com 9y ago

Show HN: Mulle_sprintf, an extensible sprintf written in C

mulle_nat
2pts0
github.com 9y ago

Show HN: UTF8-16-32 analysis, conversion, classification library

mulle_nat
3pts0
github.com 9y ago

Show HN: A growable array in C

mulle_nat
2pts0
mulle-objc.github.io 9y ago

Show HN: Objective-C, a new beginning (new compiler, new runtime)

mulle_nat
3pts2
github.com 9y ago

Show HN: Mulle-container: Sets, hashtables, arrays and more – written in C

mulle_nat
5pts0
github.com 9y ago

Show HN: A Lock- and wait-free hashtable (and an array too), written in C

mulle_nat
24pts0
github.com 9y ago

Show HN: Access variable arguments in struct layout fashion in C

mulle_nat
1pts1
github.com 9y ago

Show HN: A lock-free, cross-platform solution to the ABA problem, written in C

mulle_nat
2pts0
github.com 9y ago

Show HN: Flexible C memory allocation scheme with leak checking

mulle_nat
52pts20
github.com 9y ago

Show HN: Cross-platform thread/mutex/tss/atomic operations in C

mulle_nat
6pts3
github.com 9y ago

Show HN: Cross-platform dependency manager using bash and cmake

mulle_nat
47pts27
www.mulle-kybernetik.com 9y ago

Mini_objc: A minimal Objective-C like runtime in less than 50 lines of code

mulle_nat
3pts0
www.mulle-kybernetik.com 10y ago

C Inheritance: putting functions into a struct

mulle_nat
1pts0

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.

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.

You can check out the project here: https://github.com/mulle-objc.

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.

Agreed. BOOL in Apple ObjC is a `char` though. That is a constant thorn in the side, when you are doing slightly more sophisticated stuff with argument passing and return values as you actually have to cast a lot (BOOL (*)(id, SEL, ...)).

As the implementer of an Objective-C dialect, I am considering to go the other route and elevate BOOL to NSInteger (sizeof( NSInteger) == sizeof( id) in my case).

Conceivably the compiler could (just) for @properties combine all the BOOL fields into a bitfield, so there would be less grousing about wasted space. Maybe or maybe not.

* https://developer.apple.com/documentation/objectivec/bool?la...

* https://github.com/iterate-ch/rococoa/blob/master/ObjcMsgSen...

Mullvad also states that it disabled the Firefox password storage feature, because it's supposedly insecure. But the articles supporting this view (i read) seem to be written by third-party password storage friends. Their arguments are weak (like "some managers used to do bla bla, which was insecure") and don't apply to Firefox. Is there a strong argument specifically against Firefox passwords and password sync ?

I never merge changes. I run my unison with `-batch -prefer newer`, so I never get queried. In the very, very rare case (like maybe once every few years), where I feel I lost a file to unison, I have to retrieve a backup. It would assume that in a multi-user setup, this could be trickier.

I use the git log to feed my changelog. I prefix the stuff that's supposed to go in the release notes with a asterix and the technical boring stuff is just a normal line. Then at release time I have a script that pulls the asterix prefixed lines from the change log into the RELEASENOTES.md. I wouldn't want to bother with more.

The author thinks the Telecaster is very hard to improve on. But the bridge design is ergonomically and technically really bad. There are small screws pointing out towards the strumming hand, just waiting to draw blood. And the intonation is only adjustable on string pairs.