thequux

Calendar apps expose all of the weird edge cases in dates and times. For a specific instance of a specific event that never needs to move, TAI will work. However, suppose that you schedule a meeting for 28 March at 13:00. You then move that meeting forward a week, crossing a DST switch. If you simply add 604800 seconds to the TAI, that meeting will be at 14:00, which is surprising. OK, easy enough to solve; convert the TAI back to the local timezone, add 7 to the day field (carrying into month and year, as needed), and you're good to go. Now suppose that the meeting was set up in the US, and you realized that you needed to reschedule the meeting while you were travelling in Germany. You get back to the US, and suddenly the meeting is an hour early, because DST rules aren't universal.

Worse, imagine a recurring meeting, every week at noon. You've got the TAI for the original instance, but as you cross a DST boundary, some places will shift according to DST and others won't, and thus you have half the attendees showing up at the wrong time.

Finally, TAI introduces the leap second bug for calendars. When you schedule a meeting for noon next year, you want that to happen at noon, not now plus however many seconds. If a leap second is introduced, you don't want that meeting to happen at one second before or after noon.

TBH, if you find yourself in a situation where you need to deal with calendar events, I recommend updating your CV.

Indeed, BFS, DFS, and A* are the same algorithm just with a different data structure to track unexplored nodes. BFS uses a FIFO queue, DFS uses a LIFO stack, and A* uses a priority queue (generally a heap)

One of the things that Data Matrix got right was being able to shift between encoding regimes mid-stream. Many character sets can be represented in radix-40 (so three characters per two bytes), and the occasional capital character can be handled by a shift byte. If you have a long string of digits, they can be encoded in 4 bits/char. You can even put raw binary in there if need be

Compiling an emulator is quite easy: have a look at simh. It's very portable and should just work out of the box.

Once you've got that working, try installing a 2.11BSD distribution. It's well-documented and came after a lot of the churn in early Unix. After that, I've had great fun playing with RT-11, to the point that I've actually written some small apps on it.

Huh, and in the case that e1 and e2 are large, the mantissa overflows into the exponent, multiplying the result by 2.

Indeed there isn't; 10 is not relatively prime to 2^32. However, 5 is (and therefore has a multiplicative inverse), so you can right shift and then multiply by the inverse.

With debian, is you develop on stable, you only need to do the upgrade song and dance every year and a half or so and upgrades rarely break anything. If you develop on unstable, you can use the snapshot archive to either upgrade 6 months at a time or move back to the next stable and then walk through stable releases.

This tends to be true of mamy of the artists that chart, but less so for indie bands. I see Major Parkinson's Blackbox and Magna Carta Cartel's The Dying Option as two of the best albums of the century so far, for example.

I've used Register4Less for over a decade and I've been thrilled with them. They're slightly more expensive than the cheapest options (by a buck or two), but this is more than made up for by the fact that they're the only registrar I've ever used who have proactively reached out about minor issues. Every time I've needed to email them, I've gotten a response from somebody who can fix the problem within minutes.

The manufacturer can't control or even predict purchase dates, so that leaves potentially unbounded support lifetimes. I'd be comfortable with the 10-year timer starting from date of last manufacturer though

It was originally written by Antoine de Saint Exupéry, on the topic of airplane design

It must be a length prefix or you're still vulnerable to length extension attacks. Suppose you had encoded "foo3"; the attacker could easily extend that to "foo3bar7".

Clearly you haven't looked at my CV. I spend about half my day reading this country or that one's regulations to make sure that the small bit of the worlds largest CSD (by at least one measure) that I work on follows the law, and I have the insatiable curiosity to read the rest of it as light bedtime reading. I know whereof I speak regarding financial systems. You don't.

Specifically, accounting law is old. Computers were used to automate what the bookkeepers did by hand, which was emphatically not floating point. At the end of an interest period, interest was computed and booked in rounded form. The next period, interest would be computed based on the number in the books, not the "floating point" number that was rounded from the last time interest was booked. More clearly: put 1c into a bank account earning 1% interest compounded daily. After 1000 years, that account will have precisely 1c in it, because there was never enough interest to earn at least one quantum. This is the difference between math and bookkeeping, and between the sort of math that passes for correct in an ERP system versus the sort of math needed by a bank.

Also, fixed point is not slow, at least not on the systems relevant to actual financial infrastructure. It's all on IBM Z, which has hardware instructions for fixed point decimal calculation because if it didn't, it would run like treacle.

I think that the conflict here is that you are asking which term nobody9999 prefers to be used to describe a group of people similar to them on a certain set of axes, whereas it seems that nobody9999 would prefer that there not be such a word because they'd prefer not to be grouped on that set of axes at all.

On a personal level, this reminds me of my own struggle to identify with the term "agender". At best, it's not incorrect. But it describes an aspect of myself that feels irrelevant to whatever context it's brought up in, almost to the point of being a category error. I am currently wearing a black shirt. Does this make me a black-shirt-wearer? Well, yes, but this tells you nothing about who I am. Better to describe me on a relevant axis: I am an engineer. I try very hard to be kind to everybody no matter what I think of them. I am an optimist. I enjoy sour beers. All of these are more relevant than asking what gender I identify with, because the fact of the matter is, I don't.

Extrapolate that to the disagreement between you and nobody9999 if you find it useful; I may have misunderstood the debate or nobody9999's point entirely and make no claim to represent their views.

You might be surprised at where fixed point is already used: * Finance software: if you're using floats, you're doing something horribly wrong. All balances are measured in integer multiples of some quantum; depending on the system, that may be cents, it may be 0.1 cents, or it may be 0.01 cents. Gradations finer than that simply do not exist, and integer overflow is both more likely to be noticed and more easily explained to be a bug than precision loss (and this matters when you have a regulator asking uncomfortable questions) * CAD software: floating point may make sense for simulations, but at least for PCB design, layout is done in fixed point. You need consistent precision across the board, and avoiding edge cases in your geometry kernel from precision issues makes everything much easier. Besides, with a 1µm quantum, 32-bit numbers are sufficient for a board 4km on a side. If you need larger, I would love to see your fab. * Robotics: maybe this one's just me, but expressing motion control algorithms in fixed point has saved me €1/part on more than a few occasions as a result of being able to use an MCU without hardware floating point. Compared to the €0.20/part saved by muntzing the rest of the circuit, the small amount of additional work was totally worth it.

Indeed, the tools for working with fixed point aren't great. C is a lost cause; the best you can do is name your variables things like velocity_12_4 and manually check that the precision lines up. Rust wasn't great when I tried, though const generics may have resulted in an improvement. C++ was, astonishingly enough, quite good; I made a header-only fixedpoint.h with a templated struct `fixed<type,size,precision>` and all inline operations. I get the impression that Ada would be even better, but I've yet to use it in anger.

Hugo, the organizer of Recon, has historically been willing to work with people who are attending on their own dime. I suspect that if you were to send him an email explaining your situation, you'd be very happy with the response you received.

It is an excellent conference that I've enjoyed every single time I've gone

Pulse was only really janky in the early years; by 2010 it was as solid as anything else in tech. Even then, it was absolutely an improvement over the previous system which either needed manual configuration per program to choose whether to use ALSA, OSS, EsoundD, or Arts with success of portaudio and other sound systems too keep things interesting. Even if you did get things working, I distinctly recall having to restart Firefox in order to play music because Firefox had the only available connection to the sound device.

It's also quite common in handwriting; ij in cursive looks exactly like ÿ, and even when the letters aren't all joined, that is a common ligature. When I studied Flemish as part of the integration course, all of the teachers wrote ÿ, and so I presumed that it was just the done thing.

I use Firefox on a ~2020 era Android, and not even a particularly great one at that. Works fine for me aside from a very few badly written sites, and certainly not any shower than chrome.

A hand-written SIMD wc is likely to be even faster than a state machine, but at the cost of orders of magnitude more work. The huge advantage of state machines are that they are a relatively generic approach that provides massive speedups nearly every time. A SIMD wc algorithm is a significant effort that can't be generalized, and is only likely to provide a 4x speedup or so: rarely worth it except in cases where the task is a performance hotspot for a lot of applications.

Most likely 9 track (https://en.wikipedia.org/wiki/9-track_tape)

In response to #2, consider that every material is fundamentally "springy"[1], and many engineering materials deflect a human-noticable amount when enough force to move them is applied. Thus, you can model every connection between an actuator and an object as a spring. When the actuator starts accelerating, it applies a force through that spring, which causes the spring to extend, and the force actually applied to the object is provided only by the extension of the spring. It's only once the spring is applying the same force as the actuator is that the two objects are moving at the same speed. However, at that point, the actuator and object are moving at different speeds, so the spring is still extending. As a result, you end up with an oscillation in the velocity of the object, which is almost never desirable. For a start, if one of the parts is metal, this causes fatigue, which will cause the part to fail much sooner. Secondly, you generally want the object being moved to follow a precise path, and that oscillation will show up as ringing[2]

[1] Yes, this is a vast oversimplification, but the model I'll build using it is reasonably accurate.

[2] Most 3d printing enthusiasts are familiar with this issue; e.g. https://www.simplify3d.com/resources/print-quality-troublesh... . However, most of the advice you see amounts to "make everything stiffer", which helps, but the real solution is to be less jerky.

The question here is whether it is better to silently guess at the author's intent or to loudly say "your intent isn't clear; try again".

I strongly believe that the second is the better approach for nearly all use cases. When I'm writing a grammar, I'm focused on the happy case and not on how the rules interact with each other. My intent was to write a grammar with only a single result, indeed, but if that's not what I've done, I'd want to know!

Either conditional looping (like the for loop in C) or recursion is enough for Turing completeness. Practically speaking, conditional looping generally requires mutable variable bindings, but I can imagine a SSA-based language where variables are unnecessary. With recursion, you have no need for mutability as the function call primitive gives you the variable rebinding you need.

Hammer's arena allocator is, in fact, hot garbage. The entire reason it's there in the first place is that I didn't want to get into the weeds integrating a GC when building a proof of concept that PEGs could work at runtime in C with replaceable backends, so I didn't bother tuning it much beyond "4k sounds like a good number".

To me, the valuable part of hammer was the idea that you could use a friendly PEG-like API and end up with an LALR or GLR parser, and that, I believe, was a resounding sucess.

On the other hand, the generated AST turned out to be even less pleasant to work with than I imagined, and the only part of the implementation that's worth salvaging is the bit reader and writer routines.

I think unions are great! I'm even a member of one, and have been known to encourage everybody else around me to unionize. Notably, though, I love in Belgium.

The American implementation of unions, on the other hand, is not great. While in the US, I've run into rules like not being allowed to plug something in because only union electricians are allowed to do that, and that's just one example among many. Police unions and teacher's unions are mostly known for making bad employees unfirable outside of egregious circumstances, and teacher's unions in particular don't seem to have improved pay or working conditions much.

I have no idea where the difference comes from, but for people who have only seen and interacted with the American system, I don't blame them for not liking unions

There is something blessed about red, green, and blue: they're close to an orthogonal basis for the L, M, and S receptors in our eyes. However, there's nothing particularly special about any particular set of R, G, and B primaries. In fact, there is no set of three primaries that are both physically realizable and completely cover the set of colors we can see. This is why different color spaces exist: for photos archiving and graphical work by professionals who understand color gamut limitations, ProPhoto gives you the ability to represent nearly any color you can perceive at the cost of being able to represent many colors that cannot exist. sRGB has primaries that are easy to make out of phosphor, so it was a good baseline that every monitor manufacturer could hit without needing fancy color correction hardware, but has a small gamut. Adobe RGB is designed to cover the CMYK gamut better than sRGB. And so on, and so on.

In particular, this is why you can't get HDR by just turning up the brightness: the primaries are different. The bright red isnt just brighter, it's "redder than red", and the same for the other primaries. Imagine an HSV color picker, but you can turn S up to 200%

Which, I suppose, is basically what you said, but I've spent the last couple days diving far further into color science than my little battery monitor really needs, so the details were on my mind.

Absolute mountains. Consider: Ruby is Smalltalk with alternative syntax and core library.

I'm only being a little bit flippant here; the only core language feature in ST that Ruby is missing is thisContext, and most of the things that end developers do with thisContext (continuations, exceptions, and the debugger) are natively supported by the standard library.

I assume that the grandparent meant "from the Dominican Republic" with slightly awkward grammar

Huh. I've been running btrfs on a number of systems for probably 12 years at this point. One array in particular was 12TiB of raw storage used for storing VM images in heavy use. Each disk had ~9 years of spindle-on time before I happened to look closely at the SMART output and realized that they were all ST3000DM001's and promptly swapped them all out. The only issue I've ever run into is running out of metadata chunks and needing to rebalance, and that was just once.