joshcorbin

So basically it's really similar to Niri, but with a widget framework and bar bolted into it, and a rather nice glass shader; imo it's not AI that made the "cost of building a desktop" collapse, but rather the iceberg of architecture and prior art that is the burgeoning scene of other tiling wayland compositors, like Niri, River, Hyprland, Sway, etc...

> Could you imagine if you found everything interesting? You’d spend years living in a basement curating a wiki of late Soviet military hardware or something.

Yes... imagine...

Tell me you've got little empathy for the autist mind without telling me...

Just wait until someone finally gets why CSI ( aka the “other escape” from the 8-bit ansi realm, which is now eternalized in unicode C1 block ) is written ESC [ in 7-bit systems, such as the equally now eternal utf-8 encoding

Further showing the advantage of the pythonic way, is that the above construction remains about as clear when you refactor it for better pruning:

    (
        (to_number(s, e, n, d),
         to_number(m, o, r, e),
         to_number(m, o, n, e, y))

        for d, digits in choose1(digits)
        for e, digits in choose1(digits)
        for y, digits in choose1(digits)
        if (d + e) % 10 == y

        for n, digits in choose1(digits)
        for r, digits in choose1(digits)
        if (n + r + (d + e) // 10) % 10 == e

        for o, digits in choose1(digits)
        if (e + o + (n + r + (d + e) // 10) // 10) % 10 == n

        for s, digits in choose1(digits, 0)
        for m, digits in choose1(digits, 0)
        if (s + m + (e + o + (n + r + (d + e) // 10) // 10) // 10) % 10 == o
        if (s + m + (e + o + (n + r + (d + e) // 10) // 10) // 10) // 10 == m)

Ends up being several order of magnitudes faster since it partially sums each place and prunes aggressively. You can eliminate the sub-expressions, but it has noise impact on the run time (likely due to trading off temporary tuples for cheap arithmetic):

    (
        (to_number(s, e, n, d),
         to_number(m, o, r, e),
         to_number(m, o, n, e, y))

        for d, digits in choose1(digits)
        for e, digits in choose1(digits)
        for y, digits in choose1(digits)
        if (d + e) % 10 == y

        for n, digits in choose1(digits)
        for r, digits in choose1(digits)
        if (n + r + (d + e) // 10) % 10 == e

        for o, digits in choose1(digits)
        if (e + o + (n + r + (d + e) // 10) // 10) % 10 == n

        for s, digits in choose1(digits, 0)
        for m, digits in choose1(digits, 0)
        if (s + m + (e + o + (n + r + (d + e) // 10) // 10) // 10) % 10 == o
        if (s + m + (e + o + (n + r + (d + e) // 10) // 10) // 10) // 10 == m)

I'm really still trying to come to terms with the opener: "It’s not like I deserve any credit for being smart. I didn’t do anything to make that happen. I’m also tall, but nobody compliments me on that. (Good job being tall!) Intelligence is an immutable characteristic that I have at times capitalized on and at other times let go to waste."

To my layman understanding of psychology, and especially what intelligence research has been uncovering over the last few decades, the exact opposite is the case: - intelligence is far from an immutable trait - we do a lot to influence our own intelligence (perhaps far more than we realize, since much of what we do is due to implicit socialization/upbringing)

If you're going to use an analogy to a physical characteristic, than I'd suggest using weight not height: yes there are relevant genetic traits, but they're only a fraction of the story.

One of my favorites: column -t

Examples include: $ df -h | column -t $ column -t -s: /etc/passwd

Even more interesting to me:

In [3]: ar = [1, 2, 3, 2, 4, 6, 3, 5 ,7, 3, 5, 8]

In [4]: %timeit zip([iter(ar)]3) 100000 loops, best of 3: 2.02 us per loop

In [5]: %timeit zip(ar[0::3], ar[1::3], ar[2::3]) 1000000 loops, best of 3: 1.37 us per loop

In [6]: %timeit zip((iter(ar),)3) 1000000 loops, best of 3: 1.34 us per loop

From which I conclude: - zipping slices is even more efficient, and arguably easier to grok - but you get about the same runtime by multiplying a singleton tuple rather than a list

However if you want to generalize the chunk size, multiplication seems to win out over slicing (with tuples still being more efficient than lists):

In [7]: chunk1 = lambda n, it: zip([iter(it)]n)

In [8]: chunk2 = lambda n, it: zip((iter(it),)n)

In [9]: chunk3 = lambda n, seq: zip(*(seq[i::n] for i in xrange(n)))

In [10]: %timeit chunk1(3, ar) 100000 loops, best of 3: 2.32 us per loop

In [11]: %timeit chunk2(3, ar) 1000000 loops, best of 3: 1.83 us per loop

In [12]: %timeit chunk3(3, ar) 100000 loops, best of 3: 3.55 us per loop

Also useful to hook BufLeave/BufEnter and WinLeave/WinEnter imo.

I'm still pondering the "how is this useful?" part... why are absolute numbers useful for you in insert mode?