mcejp

Maybe it works at a certain (small) scale. And if you don't care about being able to find the question again in 1 week / 6 months / 10 years.

Of course I still care :) Thank you for sharing this technique, I will try it out.

I should have included a disclaimer -- I agree that textures and sprites are excellent, but they come from asset packs (for this same reason I cannot redistribute them in the source release). Only the crossbow placeholder is self-made.

I don't have any issue with paid asset packs, I would gladly build the entire game with third-party art, but there is only so much of it in the necessary style, resolution and quality.

Wouldn't you need a fully 3D map for that?

Over the years I have been frustrated by binary and XML formats that make data only accessible via a single program (or by me wasting time manually converting each file, or by me writing a file format conversion program).

For me, the frustration is version control. Native spreadsheet formats (xlsx/ods) are binary, so un-diffable. Plaintext formats like CSV/TSV play nice with Git, but come at a high cost in ergonomics: there is no way to preserve formatting such as column widths and formulas are usually discarded on save. Moreover, Excel/Calc don't really like it when you overwrite an open file from another program.

MtCellEdit seems to be a step in the right direction, but still leaves a good part of the itch unscratched.

I am mildly impressed that the floppy drive is not a supply chain liability nowadays.

I would agree that the flying has become "unreasonably" cheap given the negative externalities, but if we are talking about traveling over distances of >500 km, the alternatives are rarely compelling -- unless you are lucky enough have a direct high-speed-rail connection to your destination.

It is true that Hy really shines in those cases where it adopts an existing Python feature and adds meaningful quality-of-life improvements: anonymous functions without limitations; multiple iteration in for-loops; relaxed character set for identifiers. Things that seem completely obvious, once you have them.

It also demonstrates that elegance in a Lisp-on-Python is reached in a very different way than elegance in a stand-alone language, since it becomes an art of making the best out of what is already there.

I would like to make the observation that as Hy matured over the years, instead of accumulating syntactic sugar and special cases to grow more Lispy, less Pythony, it seems to have generally gone the opposite way. That is, becoming a thinner syntactic abstraction of Python's feature set, focusing on the essentials that cannot be emulated in any other way (macros)

A few examples from recent releases:

- "match" is just native Python "match" -- it doesn't even polyfill for pre-3.10 Python versions (in the TypeScript world this would be unthinkable)

- "foo?" used to mangle to "is_foo" as a special case, but this has been removed

- "hy.eval" has been overhauled to be more like Python's "eval"

- nice-to-have but non-essential utilities ("unless") get often pushed out into the Hyrule package

For me this direction was counter-intuitive at first, but it has some very nice outcomes; for one, it simplifies the learning curve when coming over to Hy from Python, and it makes it easier to consistently interact with Python packages (arguably the main reason to use Python in the first place!)

Or maybe it's just a matter of simplyfing maintenance of the language; IIRC, "let" took like 4 attempts to get right :)

In any case, congratulations on this great milestone!

Not to discourage you from building your own, but Joplin seems to already tick all or at least most of your boxes -- in fact, I was surprised that it was was not addressed in the first article.

CERN ;)

Billions of iPhone sales show that people clearly want the same.

It could as well be showing that they are only willing to endure the same. The truth is - we cannot know, since an iPhone cannot be bought without the App Store and vice versa.

I've heard the same, but I'm not able to find this clause in the Guidelines: https://developer.apple.com/app-store/review/guidelines/#in-...

Hello, colleague!

For folks who might be interested in more details on this: The _cross section_ allows you to quantify the frequency of a specific event occurring in your chip when bombarded by a specific particle (or class of particles). For example, in a case of an SRAM, you might want to calculate the cross-section for bit flips due to 24-GeV protons. The result that you get will be in units of cm^2; you can also interpret it as the physical surface area of the chip, multiplied by the probability (0..1) that any 1 particle passing through will trigger an event. Let's say you measure a cross section of 0.01 mm^2. Then if you expose that component to a flux of 10^3 particles/cm^2/sec, you will get an average of 1 event every 10 seconds.

The cross-section is only valid for one combination of the (event type, particle, energy) tuple. But often in dosimetry, errors on the order of 20% are acceptable, so we can "abuse" the results a bit. Within one manufacturing lot of chips, the cross-sections should be reasonably consistent. Typically you would estimate the mean and variance by measuring a few samples from the lot.

Then, to accurately measure a radiation field using these findings, you would generally need to measure the flux of every particle-energy combination separately. This is impractical, and for SEE* concerns we generally get away with distinguishing thermal neutrons and high-energy hadrons (which are separated by several orders of magnitude in energy). For this, it is sufficient to have 2 types of SRAM where each has a dominant cross-section for one of the particle classes of interest.

To measure the type of radiation that causes long-term gradual damage (TID) such as X-ray and gamma rays, you would use a different principle of measurement altogether (RadFET, P-i-N diode, floating-gate dosimeter...)

Radiation measurement can be fun!

[*] single-event effects, including bit flips and latch-ups

"trivially"?

If you prefer to read code on GitHub: https://github.com/mcejp/IRONSIDES