> Yes; in the course of time, men will certainly travel to the moon. The journey will be performed in safety, and at a comparatively rapid rate. Just how fast, can not be predicted; but it will be sufficiently great to enable the voyager to make the trip in six hours. The mode of conveyance will probably be an aerial machine, similar to those in which M. Santos Dumont lately accomplished such wonderful feats at Paris. The earth will be left behind at a point in Eastern France, and the moon will be reached in safety. The return journey will be accomplished in five hours. The voyager will find the lunar surface very much as described by astronomers. He will discover signs of life in the shape of numerous extinct craters, and possibly in the presence of living beings; but of the latter fact he can not be certain. The moon’s atmosphere will be found to have an extent of about five miles. Its temperature will be very cold, and, altogether, the place will be unsuited to human habitation. The project of lunar travel was first seriously entertained in 1860, when a scheme was brought forward for establishing telegraphic communication with the satellite. Since then, the idea has been advocated, from time to time, by speculative persons; but it has never been put into practice, until the present year. It has been suggested that the moon may be occupied by inhabitants, but the notion is absurd. The only imaginable purpose, for which lunar communication could be established, would be the acquisition of knowledge respecting the state of the weather. If the project were carried out, a storm, warning us of an approaching tempest, might be received from the moon, six hours before its arrival, here below.

https://michae2.github.io/c-turtl/?dna=pfrbpplfpfpppcfppcfpc...

https://michae2.github.io/c-turtl/?dna=ffffffpffffffffpfffff...

https://michae2.github.io/c-turtl/?dna=pfrblffffffffffffplll...

Any comments or suggestions appreciated!

Comments URL: https://news.ycombinator.com/item?id=46455269

Points: 12

# Comments: 3

This bit at the end of the article seems to imply it’s possible, maybe with some tricks?

> We could also add support for arithmetic and composite atoms (like lists), which introduce some challenges if we wish to stay “Turing-incomplete”.

Comments URL: https://news.ycombinator.com/item?id=42403886

Points: 60

# Comments: 3

It's all contrived, of course, but the reason I would consider skill level to be a player attribute rather than a team attribute is that there could be free agents with a skill level but no team:

INSERT INTO player VALUES (10, 'Pavlo', 'AAA', NULL);

Then with enough free agents, you could imagine building a new team out of free agents that are all at the same skill level:

UPDATE player SET team = 'Otters' WHERE level = 'AAA' AND team IS NULL ORDER BY id LIMIT 3;

If an UPDATE has to retry halfway through, locks are held across the retry to help the system make progress. But as you point out, this could cause lock acquisition to happen in an unexpected order if new rows qualify during a retry. So far we haven't run into this, but we might need to provide an option for an UPDATE to drop locks on retry if deadlock turns into a bigger problem than livelock. It depends on the workload.

Here's a full timeline in PG (U1 for first update, U2 for second update):

0. U1 begins executing, establishes read snapshot, starts pg_sleep(5).

1. U2 runs to completion.

2. U1 wakes up after 5 sec, scans `player` using snapshot from step 0.

3. U1 filters `team = Gophers`, gets 4, 5, 6.

4. U1 locks 4, 5, 6.

5. U1 performs EvalQualPlan: re-scans latest version of those locked rows, which sees U2's write to 4 but not to 3.

6. U1 performs EvalQualPlan: re-filters those locked rows using latest version, gets 5, 6.

7. U1 writes new versions.

CRDB is easier to reason about: after U1 wakes up from the sleep, it sees that it conflicts with U2 and simply retries the entire statement.

There were many interesting design decisions, such as:

- whether to use multiple snapshots or a single snapshot per statement

- how to handle read uncertainty intervals

- how to incorporate SELECT FOR UPDATE locking into Raft

- how to handle SELECT FOR UPDATE subqueries

- how to prevent lost update anomalies between two UPDATEs

Some of the gory details are in the public RFC: https://github.com/cockroachdb/cockroach/blob/master/docs/RF...

This blog post just discusses the last point, but please AMA.

Comments URL: https://news.ycombinator.com/item?id=39948686

Points: 135

# Comments: 58

In addition to the loop-unrolling and bit-twiddling tricks that also show up in the fastest Java and C++ versions, some Go-specific things I learned were:

- unsafe.Pointer can be used to read memory without bounds checks

- many functions in the bytes and bits packages in the standard library are written in assembly

- debug.SetGCPercent and SetMemoryLimit to turn off GC

- runtime.LockOSThread to lock a goroutine to a thread

- print is slightly faster than fmt.Printf (but writes to stderr)

Also, it seems like in this system the speed of light is infinite, since every particle acts on every other particle each frame, regardless of distance. In CGoL there is a speed of light, since cells can only influence their immediate neighbors each frame.