bwhmather

This is the way, and why I wrote https://pypi.org/project/ssort/. Unfortunately you need to follow it up with shameless self-promotion or it doesn't work.

To add to this, experienced users will often start typing without looking based on what they trust the eventual state of the UI will be. Moving the cursor immediately makes it explicit that this should work.

This is following a more important rule which is "Never make keyboard input timing dependent!" I'm looking at you new Windows start menu and VS Code quick open.

You are not wrong! That certainly looks like the intention.

I'm also the happy owner of a StarLite Mk IV. The perfect travel laptop. Thin, light, fanless, excellent keyboard and touchpad, matt screen, rock solid chassis, good battery life. I'm dreading the day when it finally breaks as there's nothing comparable on the market today. I wish they could do another run.

Very different niche from the StarFighter but StarLabs make excellent machines.

I use this script, saved as `rerun`, to automatically re-execute a command whenever a file in the current directory changes:

    #!/usr/bin/sh

    while true; do
        reset;
        "$@";
        inotifywait -e MODIFY --recursive .
    done

For example, if you invoke `rerun make test` then `rerun` will run `make test` whenever you save a file in your editor.

Have pushed fix as version 0.10.0. Thank you very much for reporting.

By the way, I have raised a ticket to finalize method order before 1.0 release (https://github.com/bwhmather/ssort/issues/11). Please follow and comment if you would like to see a change.

I'll try to add some better ones over the weekend. This should be a start.

It is a bit backwards, but in exchange you get predictability

With backwards sorting you know that, unless there is a cycle, you can always scroll up from a call site to find the definition or down from a definition to see where it is used. With forwards sorting you can scroll down to find a definition, unless the function was imported, or used as a decorator somewhere, or called by something that was used as a decorator, or used in some other way that I haven't thought of.

My personal experience is that this predictability is hugely useful. It almost entirely obviates the need for jump-to-definition within a module, and gives modules a very obvious shape and structure.

Will do. Examples directory isn't terribly helpful as documentation as it mostly contains real code with problematic syntax (and compatible licensing) that tripped up ssort when I ran it on a copy of my pip cache. I will move it into tests to avoid confusion

Implementation details at the top. Python is a scripting language so modules are actually evaluated from top to bottom. Putting high level logic up top is nice when you just have functions, which defer lookup until they are called, but you quickly run into places (decorators, base classes) where it doesn't work and then you have to switch. Better to use the same convention everywhere. You quickly get used to reading a module from bottom to top.

isort only sorts imports. ssort will sort all other statements within a module so that they go after any other statements they depend on. The two are complementary and I usually run both.

One thing worth mentioning is that the `git blame` ignore file trick doesn't work as well with ssort as it does with black because the changes ssort makes tend to be much less local.

Yup, that's a bug. All assignments are treated as properties and moved to the top. Fix to follow shortly.

I've had the same problem with pydantic. Currently, properties are special cased and moved to the top. Everything else, including classes, is grouped with methods. Meta classes will end up somewhere in the middle, which is probably the worst possible case.

SSort is currently used for several hundred kilobytes of python so I'm wary, but if I'm going to make a breaking change before 1.0 then I think this is likely to be it.

Shameless plug: For people who like black, I've been working on ssort[0], a python source code sorter that will organize python statements into topological order based on their dependencies. It aims to resolve a similar source of bikeshedding and back and forth commits.

0: https://github.com/bwhmather/ssort

Commit history serves two largely separate purposes:

1) To provide a code-level record of what has changed in individual files and why.

2) To provide a high-level record of what features were introduced and what bugs were fixed over a period of time.

Often people will forget about one of them when arguing for a particular approach.

Squashing can make 2 easier but annihilates 1. Rebasing gives you 1 but makes 2 difficult, or requires that you track high level changes in an external system. In theory, approaches using merge commits can give you both but they are often difficult to apply in practice.

To access an equivalent amount of mass from the moon you would need to strip mine it to a depth of about 23.5km. On earth it would be about 1km. Your point about losing a lot of it as reaction mass still stands, but 4% of the moon is actually quite a lot.

The smoothsort variant of heap sort might be a better alternative. It can be implemented in-place like an ordinary heap sort, but unlike an ordinary heap sort the root will be at the end of the heap where you want the elements to end up when they've been popped. The whole array, including the fully sorted part, will remain a valid heap so you can continue to add new elements efficiently.

Option 1 is already provided. The sd_notify function is simply a convenience wrapper for sending messages on a socket specified by the NOTIFY_SOCKET environment variable.

See the notes in sd_notify(3) or https://lists.debian.org/debian-ctte/2013/12/msg00230.html for a simple alternative implementation. Admittedly could be better documented.

edit: point to notes section

See also http://academictorrents.com/ posted here a few months ago

For similar stuff, don't miss the link at the bottom to the blog of the designer behind the film:

http://www.gavinrothery.com/moon-blog-index/

Mandatory link to http://blog.okcupid.com/ Less story, more analysis.

It seems odd that they chose to post the logo as a jpeg. The compression artifacts stop it from appearing as crisp as it should be.