muth02446

If you think, no problem, I use another channel:

"US: Ordering electronics from overseas? WATCH OUT! Global entry revocation!"

https://www.reddit.com/r/GlobalEntry/comments/1x4c062/us_ord...

If you are satisfied with an approximation of "DISTINCT", there is a facinating probabilistic algorithm by Flajolet and Martin

https://en.wikipedia.org/wiki/Flajolet%E2%80%93Martin_algori...

which fits on 10 lines and does not require sorting. Improved versions of it are LogLog and HyperLogLog.

The incremental linking part sounds pretty hackish to me and I wonder what the price is in increased code complexity and maintenance effort. It also does not mention how it deals with the patching of debug information.

Without nuclear, your country will remain vulnerable to:

4) renewable energy disruptions, e.g. supervolcano eruption, large meteor strike

Separate compilation is one solution to the problem of slow compilation.

Binary patching is another one. It feels a bit messy and I am sceptical that it can be maintained assuming it works at all.

I think a much better approach would be too make the compilers faster. Why does compiling 1M LOC take more than 1s in unoptimized mode for any language? My guess is part of blame lies with bloated backends and meta programming (including compile time evaluation, templates, etc.)

> Unfortunately you can't really statically link a GUI app.

But is there any fundamental reason why not?

> Also, if you happened to have linked that image to a.out it wouldn't work if > you're using a kernel from this year, but that's probably not the case ;)

I assume you refer to the retirement of coff support (in favor of elf). I would argue that given how long this obsolete format was supported was actually quite impressive.

Wasn't there also DLL hell on Windows?

My understanding is that very old statically linked Linux images still run today because paraphrasing Linus: "we don't break user space".

Shamless plug: http://cwerg.org

Pros: * uses Python and recursive descent parsing * separates front and backend via an IR * generates ELF binaries (either x86 or ARM) * meant for real world use

Cons: * more complex * not written in a tutorial style

Surely, you are joking about the "little" part.

The Dwarf 5 document is over 400 pages long (c.f. https://dwarfstd.org/doc/DWARF5.pdf).

What I am curious about: where zfs checksum failures the only symptom of the bad disks or where there SMART failures as well?

I am in a similar situation and my solution was to switch to PWAs. I translated the apps from Java to Dart and rolled my own UI with straight forward HTML.

My apps do not use notifications which seems to be an issue with PWAs. A real downside for me is the lack of a simple i18n story and I will likely roll my own.

On the plus side: * PWAs can be easily packaged into an APK using: https://www.pwabuilder.com/ * my apps can now be used on IOs and regular web browsers

Each new decoder represents an increase in attack surface which is why not all video/audio formats supported by ffmpeg are enabled in Chrome. This is despite Chrome having ffmpeg as a depency. [caveat: this was the status quo when I last checked a couple of years ago]

The key to unlocking a 10x improvement to compilation speeds will like be multithreading. I vaguely remember that LLVM struggled with this and I am not sure where it stands today. On the frontend side language (not compiler) design will affect how well things can be parallelized, e.g. forward declatations probably help, mandatory interprocedural anaylyses probably hurt.

Having said that, we are in a bad shape when golang compiling 40kLOC in 2s is a celebrated achievement. Assuming this is single threaded on a 2GHz machine, we 2s * 2GHz / 40kLOC = 100k [cycles] / LOC

That seems like a lot of compute and I do not see how this cannot be improved substantially.

Shameless plug: the Cwerg language (http://cwerg.org) is very focussed on compilation speeds.

I am puzzled that they not already have moved to the web. Also speaking off the cuff: what are the main reasons for using word documents in government? If it is mostly communication with other parts of the government or the public, shouldn't this be email which requires very little functionality compared to word.

I can see niche cases, like laws where you want change tracking or very long reports but that does not seem to apply to most government employees. Somehow I feel I missing something big, maybe there is a lot of automation built around word documents?

Another small language is Cwerg [1] (tutorial: [2]) A C-like low level language with a Python inspired syntax.

The frontend has a self imposed line budget of 10kLOC.

[1] http://cwerg.org [2] https://github.com/robertmuth/Cwerg/blob/master/FE/Docs/tuto...

I view nuclear as a prudent diversification of energy sources: What happens if some supervolcano erupts, and because of the ashes significantly less sunlight reaches the surface of the earth. Presumably, there will also be less wind then.

If you do embedded work, you often want to be in total control of all memory allocations. So it is good to know that the compiler will not produce some invisible heap allocations and there is a useful subset of the standard libray that does not use them either.

Aren't there other oil-rich nations that essentially have UBI and could serve as a data point.

there are also atomicity issues

This reminded me of two other recommendations:

1) write a pretty printer early on (I had one for the s-expr based syntax and one for the concrete syntax I introduced later) This will allow you to automatically apply the syntax changes on the example code you have written in your PL with only very little programming

2) instead of parser generators use recursive descent + Pratt parsing Pratt parsing is a little bit magical at first but it is easy to develop a working intuition without understanding all the details of the algorithm.

I almost did ;-)

I added a few improvements to help with legibility which made it bearable to program with sexpr.

But arithmetic expressions and (chaining of) unary operators was just too painful, e.g.

(= (. (^ ptr) file) ...)

instead of

ptr^.field = ...

While working on my systems PL, Cwerg, I adopted a "syntax last" approach:

For the longest time the syntax was just glorified s-exprs. This made it much easier to focus on the semantic choices and improved iteration times and willingness to experiment since the parser changes were always trivial.

I highly recommend this approach for new PLs.

Shameless plug for another relatively small compiler written in Python with no dependencies: http://cwerg.org

I can commiserate. I did some bootstrapping of gcc 10 years ago and it was the most miserable experience ever. You make a change somewhere. Kick off "make" and 20 min later you get some bizarre error in some artifact that is hard to find, generated by a build system that is impossible to trace.

A self-hosting Cwerg will hopefully be much easier to bootstrap because of its size. But until then, why do you need the (continuous) bootstrapping. You can use a cached version of the bootstrapped C++ compiler or cross compile.

I think you are generally correct but the two examples you gave "triggered" me ;-)

What damaged would there be if gcc or LLVM did decide to not support x87 anymore. It is not much different from dropping an ISA like IA64. You can still use the older compilers if you need to.

Similarly, what is varargs used for? Pretty much only for C and its unfortunate printf, scanf stdlib calls. If a backend decides not support C, all this headache goes away. The problem is, of course, that the first thing every new backend designer does is to write a C frontend.

Ultimately, the plan for Cwerg is to be self-hosting, so C++ is just another stepping stone. I am curious about the issues with C++17 (vs say C++11) though.

About using C++:

Cwerg is NOT going "all in" on C++ and tries to use as little STL as possible. There are some warts here and there that C++17 fixes and those are used by Cwerg - nothing major. There is also a lightweight C wrapper for Cwerg Backend.

About not using C:

I do not get the fetishizing of C. String handling is just atrocious, no concept of a span, no namespaces, poorer type system, etc. Cwerg is actually trying to fix these.

If Cwerg was written in C instead of C++, a lot of the constructs would become MACRO-magic.

About Backends:

Currently supported are: 64 bit ARM, 32 bit ARM (no thumb), 64 bit x86 There are no plans to support 32 bit x86

Shameless plug for another similar system: http://cwerg.org Less ambitious with a focus on (measurable) simplicity.

Made something similar for Basic Vocabulary (Spanish and English so far):

* https://www.appicenter.net/Apps/VocabES/ * https://www.appicenter.net/Apps/VocabEN/

Uses Spaced Repetition and Audio but is not personalized which is less of an issue for basic words. The hard part is getting good example sentences and "cross links". I had though about use AI for that but have not followed through.

What does that mean for all the existing simulations that use the "wrong" values?

BTW: are there any open source climate models/simulations?

IIRC Waymo only offers their service in certain places and does not use highways. Was this controlled for?