dom0

Lack of seaworthiness in nodejs

Contrary to folklore, the Oracle JVM is one heck of a workhorse.

This is especially noticeable when adding text in the middle of a longer document. It seems as if it is laying out many subsequent pages in a blocking fashion, even if those pages are not visible.

Computer keyboards typically contain only one chip which has a combined USB-PS/2 port, scanner and a 8051 to glue things together. DIY keyboards normally just use any microcontroller with a built-in USB controller.

No, it really converts all iterables to lists (there is a utility function in the C API to do just that, because it's kinda hairy to do by hand. PySequence_ToList or so). Otherwise it would not be possible to calculate how much space is required beforehand, since iterables cannot be walked twice.

Do you mean immediate mode rendering by any chance? This is a bit different (but not that much) from what e.g. imgui does.

I found all I used (eagle, kicad, target, protel) not intuitive to use and not very user friendly (which is said about almost every CAD package), but within even that group there are massive differences in capability.

There really aren't any good ecad packages for low prices (at least not that I ever heard of it). All cheap packages are just glorified 2D drawing programs (e.g. eagle, target).

*hear hear! ;)

Not a big fan of Cython here... https://hn.algolia.com/?query=dom0%20cython&sort=byPopularit...

Exception handlers in CPython work by having an instruction store the offset to the start of the handler code which is stored on a stack attached to the frame (iirc). So the cost of a "try:" block is pretty low (for Python, anyway).

The handlers themselves are pretty basic, an "except SomeError" pretty much translates to "if isinstance(exc, SomeError):".

The reason join is fast for these cases is because join basically converts all iterables to a list first and figures out how much it has to join exactly.

The funny thing about "moving quickly in dynamic languages" is that it doesn't last. Refactoring code in a dynamic language gets difficult fast and is an entirely hopeless endeavour without a huge test suite (you obviously need tests on every level, because you can't refactor an interface and its test at the same time and still think it's working as intended).

Typed code may be slower and more cumbersome (to some) to write in the first place, but is usually much easier to maintain in my experience.

> and I frankly don't understand how people ran Python engineering projects of any significant size without it

Pretty much the first thing the Zope folks made was port Java interfaces to Python.

Considering that Zope projects were both relatively early and big in Python's life time, that might answer your question. (Plus, projects not using anything like it usually either have very large test suites, or are broken more frequently than working).

Yes, these are hard-wired logic and just a handful of bytes for two to four registers (at least input and accumulator registers, everything in BCD). Only more advanced calculators use floating point.

tup sounds similar to qbs. I found qbs to be a most amazing C++ build system, it's the only one I used that is

1) reasonably easy to use 2) very fast 3) very correct

Most build systems fail 3), usually 2) and often also 1).

> I'm having a hard time thinking of a use case for complex data structures in a build script. Can you give a real world example?

Look at how a modern build system (like qbs) organizes the build. It builds a declarative object graph describing the project and maps that to a dependency graph where each node can be a relatively complex object ("compile C++ file X using flags Y" or "link LargeSetOfFiles") annotated with modification data (like input file hashes). (Then it compares the dependency graph to what is found on the system and creates a list of commands to execute in order to bring whatever is on the system to the desired state, i.e. create an up to date build).

Looking at this thread of comments a couple hours later, clearly, no one has an idea (so any security cleams seem unbased).

AES being linear or not is wholly irrelevant for this.

I recommend you read this article: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

Not necessarily. Depending on the mode bitflips produce predictable results and a SSD probably does not authenticate blocks.

> I would expect to see database systems emerging that can GPGPU accelerate operations on tables to be way, way faster than what a CPU can handle.

Why do you expect that? Many DBMS operations that are not I/O limited are memory limited, and a GPU does not help you there (on the contrary, you get another bottleneck in data transfers to the small GPU memory). What can help is better data organization, e.g. transposed (columnar) storage.

No, Intel's approach is very different from GPUs, because Intel has a strong negative interest in making porting to GPUs easy (also, wide vectors are far easier to do in a CPU than a "GPU like model").

> We have been over 5ghz for a decade, it just takes ln2 to do it.

Non-x86 systems went over 5 GHz on air many years ago, e.g. IBM POWER.

Itanium was such a strange ... event. A complete outlier, it is even from today's perspective not easy to see why it happened.

I don't think GPUs are a particularly good solution for these, they aren't the future and won't be around for mass-deployment that much longer.

I never tried, but mmap and mincore could work (or not, as one of the many special cases in this area). I expect that's not a viable approach for this application, anyway :)

Cookies aren't restricted to paths as well.

> 10,000 MPGe ... 12,600 MPGe

(0.024 l/100 km, 0.019 l/100 km)

> 600-1000mpge

(0.24 - 0.4 l/100 km)