gtfierro

It could definitely be clearer, but if you click on the name of the operating systems on that page, they'll produce a little dialog that tells you how to run Cockpit.

You could, but you'd be competing with everyone else that's also making transactions so you'd need an incredible amount of computational power to outstrip that.

My understanding was that until the "elephant's foot" and other radioactive lava flows were found, everyone was under the impression that there was still fuel in the reactor, which carried the possibility of a second explosion. The existence of the lava flows instead indicated that everything had melted together and spread throughout the lower parts of the building: radioactive, but no longer prone to an explosion.

Another comment here mentioned a recent FAST paper talking about BtrDB, which can get ~16mil writes/sec (nanosecond timestamp, 8 byte values) on a single node, with near-linear speedup when clustering: https://blog.acolyer.org/2016/05/04/btrdb-optimizing-storage...

If you look at the "image" description files (e.g. http://essenmitsosse.de/pixel/scripts/zeus.px, linked by another comment), then it looks like the files define a set of constraints on the "components" in an image such as Zeus's arm , the bird beak, the cow's leg, etc. When the mouse moves, my guess is those constraints determine which components are rendered and where they appear on screen.

Any left? gtfierro225 AT gmail

Thanks in advance!

Going beyond this being a minor optimization that isn't going to matter for most people, my guess is that they probably don't reorder structs because it may not be what the programmer intended. When you start introducing mechanisms for altering how the compiler sees a certain piece of code (like a struct definition), then you also need to give the programmer a way of expressing which thing they want the compiler to do, like with __attribute__ in C. Adding that feature in a straightforward way would probably involve introducing more syntax, which Go wants to avoid.

The updated readme at http://llvm.org/svn/llvm-project/llgo/trunk/README.TXT mentions the following:

"llgo is under active development. It compiles and passes most of the standard library test suite and a substantial portion of the gc test suite, but there are some corner cases that are known not to be handled correctly yet. Nevertheless it can compile modestly substantial programs (including itself; it is self hosting on x86-64 Linux)"

so it has come quite a bit farther, it seems.