chadaustin

Yeah, I was disappointed by the lifted trace. It was only on the assembled one. The others all look fine to my untrained eyes.

Because I had low confidence in my circuit, I ordered the cheapest possible assembly. I assume hand-assembled or a mix, given one of each part.

I’m hoping to attempt hand assembly myself soon. Picked up a hot air station and a new set of parts from Digi-Key. :)

Good eyes! That’s a handy feature of this MCU: power-on boots start the application, not the bootloader. External resets switch to the bootloader if HWB is pulled low.

Give it a shot! I bet you could figure something out, maybe starting with this guide. https://teaandtechtime.com/custom-60-percent-bluetooth-keybo...

The AVR/Arduino boards boot instantly which is one of their big advantages here. I imagine the Pico will be the same.

The LaserJet 1012 was such a great printer! I think we spent $100 on ours back in 2004 and it lasted with frequent use until last year.

EdenFS makes it possible to query for hashes of files so any cached outputs can be looked up from the build cache without having to download the source control. There’s more to do here, but that’s a big benefit of having a custom filesystem.

It can be a big chunk of the cost of parsing JSON.

Hi, author here. Sometimes it's just like that. I loved my coworkers. I am (was?) bullish on the company. I thought they were doing a lot of great things. But there was plenty to improve at.

It was a confusing experience for myself and ultimately I quit of my own accord and found a job I was happier at.

You’re definitely warm. I worked at Dropbox around this time and there was very little C++ or systems experience in the building. I think it’s expertise they tried to build but for whatever reason didn’t. I work at Facebook now and the difference is night and day. FB does share a ton of code across platforms, and it doesn’t even feel controversial.

I don’t think Dropbox made a mistake in cutting out their shared C++ code, but I would caution against generalizing code sharing as a bad idea.

That usually means your build graph and target signatures are incomplete and you need to figure out where you have a dependency that you haven’t told SCons about.

I was on the original SCons team. It’s a lot of “python slow” but if someone build a daemonized version of the build graph that could be updated incrementally from filesystem change events it could be great. (A la Buck and Bazel)

That's one where we got lucky. We made the wrong decision, but it didn't matter because the distinction was invisible when using the higher-level abstractions (like coroutines) and combinators.

My opinion now is that JavaScript does it right: `.then` should _always_ defer the callback. BUT, it does come at a real performance cost. And for code that is performance-sensitive and can handle the callback running immediately, the API should support a `.thenImmediate` or something that will run immediately if possible.

Back in the mid 2000s at IMVU, I went deep on reading about E, EROS, Polyphonic C#, and Comega, which lined directly up with the problems we were having with asynchronous programming on the client.

Thus, I can point directly to E and friends as leading us to make such a successful, _correct_, asynchronous task engine.

It's funny to think about now. Promises and coroutines and promise pipelining and async are now well-explored, but at the time there wasn't much prior art to draw from, and everyone was figuring it out as they went. Do you synchronously block on futures? Should .then calls run on the calling thread if data was already available? How does cancellation work?

Once you have answers to those questions, you reach the higher-level ones: how do you structure your program so that asynchronous components can communicate? How do you unit test these interactions? What abstractions avoid needing to unit test every possible sequence of events?

We did a pretty good job and I feel blessed that we stumbled upon the E papers, leading us to create abstractions that stood the test of time.

Thanks Mark!

Netflix DVD has it.

This is the first I'm hearing that arbitrary function pointers converted to void* should be distinct on POSIX - do you have a reference?

Compiling C++ to asm.js with Emscripten is another weird architecture you might actually use these days.

Unaligned accesses don't trap with a SIGBUS or anything, they just round the pointer value down to an aligned address and read whatever that is.

Reading from and writing to NULL will generally succeed (just as on SGI).

Function pointers are just indices into tables of functions, one table per "function type" (number of arguments, whether the arguments are int or float, whether it returns an argument or not). Thus, two different function pointers may have the same bit pattern.

I listened to this episode yesterday. Several interesting points and discussion, and the political industrial complex is real, but I'm not 100% convinced by the argument that the two parties are a duopoly therefore they do not serve the public. While the political system basically ensures that there are only two parties, they rotate over time and adopt or discard ideas as the public needs them to.

Clay Shirky discusses this argument in https://medium.com/@cshirky/theres-no-such-thing-as-a-protes...

In general, Facebook allows people to pick their own teams. You go through bootcamp, interview teams and managers, and then pick what you want to work on. Can't hurt to reach out and see, at least!

Also, even the PHP/Hack code is way more delightful than any Java codebase I've touched. :P

That sounds to me like the most likely hypothesis in this thread.

I mean, the Linux manpage itself says it's stable and can be used, with the inode number, to uniquely identify a file. http://man7.org/linux/man-pages/man2/statfs.2.html

I'm not surprised, though. Fancy copy-on-write filesystems like btrfs have some other subtle gotchas. If you allocate (like, really, not as a hole) a big file on btrfs and mmap it for write, you might see a SIGBUS upon writing because btrfs needed to recompress a block and the new compressed block didn't fit where the old one did.

I've gained a new appreciation for the predictability and simplicity of ext4.

Yeah, the old installable MSDN Library was really great. I loved how they approached each topic with three types of documentation: tutorials, concept overviews, and types-and-functions references. I still have the CDs on my bookshelf because I can't bring myself to throw them away. :)

Microsoft was really good at developer documentation.

Apps like Dash and websites like devdocs.io come close to the same experience, at least.

If you sued Facebook, you would have lost the patent grant, but not the copyright. With the new license, there's no patent grant at all, so if any code in React is patented, you're in the same boat as you'd have been if you'd sued in the prior situation.

Edit: It seems like some consider MIT, unlike BSD, to have an implied patent grant based on its wording: https://www.scribd.com/document/46088081/Closing-the-Loophol...

(Disclaimer: I used to work at Dropbox)

I'm not a fan of a binary "open office or not" distinction: both can be done well. Dropbox's old office was the best open office I've worked in. Large desks, low employee per sq. ft. density, sound-absorbing foam on the (high) ceilings, teams spaced relatively far apart. The new Dropbox office was a slight regression. Smaller desks, slightly higher employee density, no sound-absorbing material. But it was still mostly fine.

IMVU's open offices back in 2012 or so sucked. Employees were packed together to the point that it was sometimes even hard to walk from point A to point B.

I feel like the most important office quality metrics are employee density and how well sound carries.

Whether or not there are useful collaboration surfaces matters too: cubicle walls are great for stickies and note cards. But that's solvable with easy access to dry-erase walls or dry-erase boards on wheels.

It's not one or the other, IMO. They're both useful tools. Unit tests for the bulk of my testing, and then property tests to do some light fuzzing against properties I want to hold.

Milo Yip (author of RapidJSON) has done fantastic work on validating the correctness of and benchmarking JSON parsers. The results listed there predate the current round of sajson optimizations and sajson's dynamic allocation mode, so it would be great to see them rerun.

Oh, didn't know that! Thanks.

Hi all, author here.

Several people have raised questions about SIMD. For many workloads, SIMD is obviously a huge win. But in my experience, for problems like this, the gains are marginal and the additional complexity often isn't worth it. e.g. Do you have a build-time option? Check at runtime at every call? Use templates to check at startup and run a different code path?

That said, it never hurts to try, so I implemented the fast string path in AVX2 (see https://github.com/chadaustin/sajson/commit/e87da27883ffe0a3...). It actually benchmarks slower than the scalar code: https://gist.github.com/chadaustin/6fe8d250ac8402ad70a724e7a...

I couldn't tell you why - it's possible something could be tweaked to make it actually execute faster, or that enabling -mavx2 causes other code to get slower, but I wanted to illustrate that enabling SIMD is not always an automatic go fast button.

I did look at the instructions generated and they seem reasonable:

    .LBB5_118:
        vmovdqu	ymm5, ymmword ptr [rbx - 32]
        vpcmpgtb	ymm6, ymm5, ymm0
        vpcmpeqb	ymm7, ymm5, ymm1
        vpcmpeqb	ymm8, ymm5, ymm2
        vpcmpeqb	ymm5, ymm5, ymm3
        vpxor	ymm5, ymm5, ymm4
        vpor	ymm6, ymm8, ymm6
        vpor	ymm5, ymm5, ymm6
        vpor	ymm5, ymm5, ymm7
        vpmovmskb	esi, ymm5
        test	esi, esi
        jne	.LBB5_148
        mov	rbp, rax
        sub	rbp, rbx
        mov	rsi, rbx
        lea	rbx, [rbx + 32]
        cmp	rbp, 31
        jg	.LBB5_118
        jmp	.LBB5_120

    .LBB5_148:
        add	rbx, -32
        bsr	eax, esi
        xor	eax, 31
        lea	rsi, [rbx + rax]
        mov	bl, byte ptr [rbx + rax]
    .LBB5_125:
        mov	r10, qword ptr [rsp + 24] # 8-byte Reload
        mov	r9b, byte ptr [rsp + 39] # 1-byte Reload
        sub	rcx, r8
        movzx	eax, bl
        cmp	eax, 34
        jne	.LBB5_127

I suppose it's also worth pointing out that, while string scanning is an important part of JSON parsing, the instruction histogram is generally spread across the entire parser. That is, a doubling in string parsing performance would only help overall parse times by 10-20% maybe.

Edit: Upon thinking about it, it's probably slower because there's a dependency chain through a pile of high-latency vector instructions all the way to the bsr (should be bsf, I fixed on the branch) to the next loop iteration's load. The branch predictor doesn't have much opportunity to help us out here. You could look at Agner Fog's tables and calculate the critical path latency of this loop, but I'm guessing it's not pretty.

PCMPISTRI and friends are great, but they're not very friendly to the problem described in the article, since they can only check membership in a 16-element set.

My first exposure to American Fuzzy Lop! What an amazingly easy tool to get running.

Fix is in the App Store! Update should come soon.

Yikes! I'll see if I can reproduce. Thanks for the bug report!