rjmill · HackerTrans

Very nice! Independently of this thread, I was delighted to discover the cross references between pages. It makes a big difference.

rjmill

2 mesi fadiscuss

They've always resonated with me, maybe because I often work on legacy code. All this ancient technology that no one understands. Crazy rituals/incantations to get things done. People being afraid to skip steps, even if it probably isn't needed. The aversion to unconsecrated (non IT-supported) technology.

The machine spirits were the only part that felt "too magical" to me, but now we're well on our way. The Omnissiah's blessings be upon us.

(Let's just skip servitors. Those give me the heebie-jeebies.)

rjmill

3 mesi fadiscuss

Someone please explain the grapple leapfrog example and why that "exploit" is interesting. If my players tried that, I'd happily let them use their full turns to do some crazy trapeze act across the battlefield.

And then I'd remind them that they could have just dashed normally.

Moreover, how do the new rules close the "exploit"? You can still move 30ft while carrying someone. (60/2 - 30 vs 60 - 30*2) How is that difference meaningful in this case?

(Also, wouldn't you need something like rogue's dash-as-a-bonus -action to grapple and dash on the same turn?)

The article is pretty interesting overall but this example mystifies me. Am I missing something obvious?

rjmill

7 mesi fadiscuss

Odd, I don't see any mention of subprocess.run, the workhorse of python scripting.

Quick rundown for the unfamiliar:

Give it a command as a list of strings (e.g., subprocess.run(["echo", "foo"]).)

It takes a bunch of flags, but the most useful (but not immediately obvious) ones are:

  check=True: Raise an error if the command fails
  capture_output=True: Captures stdout/stderr on the CompletedProcess
  text=True: Automatically convert the stdout/stderr bytes to strings

By default, subprocess.run will print the stdout/stderr to the script's output (like bash, basically), so I only bother with capture_output if I need information in the output for a later step.

rjmill

8 mesi fadiscuss

> But isn't it true for JavaScript too?

I don't think so. It's been a while since I've bled on tricky async problems in either language, but I'm pretty sure in JS it would be

  [...]
  parent_before
  parent_after
  child_before
  [...]

In JS, there are microtasks and macrotasks. setTimeout creates macrotasks. `.then` (and therefore `await`) creates microtasks.

Microtasks get executed BEFORE macrotasks, but they still get executed AFTER the current call stack is completed.

From OP (and better illustrated by GP's example) Python's surprise is that it's just putting the awaited coroutine into the current call stack. So `await` doesn't guarantee anything is going into a task queue (micro or macro) in python.

rjmill

8 mesi fadiscuss

Not to dimish the achievement, but TFA is pretty clear about the limitations of the piece:

> I was able to get it working consistently, although it did lose 2-3 balls an hour and could only run for a few hours without the motor overheating.

IMO that's more impressive to hear than if he hadn't mentioned it at all. (I would have assumed more marbles getting lost.)

comments