If done with Electron, that will be 100 MB.

Or with Tauri, 5 MB. Which, amazingly, seems tiny.

I am always curious how different C programs decide how to manage memory.

In this case there are is a custom string library. Functions returned owned heap-allocated strings.

However, I think there's a problem where static strings are used interchangably with heap-allocated strings, such as in the function `string class_simple_name(string full)` ( https://github.com/neocanable/garlic/blob/72357ddbcffdb75641... )

Sometimes it returns a static string like `g_str_int` and sometimes a newly heap-allocated string, such as returned by `class_type_array_name(g_str_int, depth)`.

Callers have no way to properly release the memory allocated by this function.

Obviously they don't put the weight on the product main page, that is absolutely heavy.

The Helinox Chair Zero is the standard by which all backpacking chairs are compared https://helinox.com/products/chair-zero - and it is 1 lb 1 oz.

And then some people mod these chairs, like this similar one that was reduced to 13 oz. https://backpackinglight.com/forums/topic/chair-enlightening...

True, "nm" initially seemed to be nautical miles, but then this square meters thing appeared. The point is that "m" should be meters, but "mi" would be a more customary abbreviation for miles in the U.S.

"A single 1-kW jammer can take down GPS for a 300-nm radius.[...] A CRPA can shrink the effective radius of the 1-kW jammer to 3 nm. The jammer’s area of effectiveness is slashed from 280,000 m² to 28 m²."

An example of the kind of unit confusion that could crash a Mars orbiter?

I thought we were talking about nanometers and square meters here for a second. But this only makes sense if "m²" means square miles and "nm" means nautical miles. How about at least using "mi" for miles to reduce confusion?