Searching txt.sour.is

Twts matching #0
Sort by: Newest, Oldest, Most Relevant
prologic
twtxt.net
 (2w ago)
↳ In-reply-to » It is such a nice feeling that Mu is such a capable little language 😅 And I decided to write code code in Mu by hand 🤚 haha 🤣 and start solving Project Euler problems, like Problem 8 which works out to be a nice elegant solution in Mu:

Oh man wow 😮 Problem 9 was quite hard 😱 I had to build two new functions in the Mu stdlib for computing combinations and permutations, but then the combinations of range(1000) for triples such as a + b == c is enormous! So i had to write iterator versions of these to do lazy evaluation. Anyway solution follows:

#!/usr/bin/env mu

// Special Pythagorean Triplet

import "iter"

fn usage() {
  print("Usage:", args()[0], "<n>")
}

fn sqr(x) { x * x }

fn main() {
  if len(args()) < 2 {
    usage()
    exit(1)
  }

  n := must(int(args()[1]))
  print("n:", n)

  // For a < b < c and a + b + c == n, both a and b are strictly less
  // than n/2. Generate only (a,b) combinations and derive c directly. This
  // keeps the search lazy and reduces n=1000 from C(999,3) = 165,668,499
  // candidate triples to C(499,2) = 124,251 candidate pairs.
  pairs := iter.combinations(iter.range(1, n / 2), 2)

  triples := iter.map(pairs, fn(xs) {
    a := xs[0]
    b := xs[1]
    return [a, b, n - a - b]
  })

  // Enforce b < c; a < b is already guaranteed by combinations over an
  // increasing range, and a + b + c == n holds by construction.
  triples = iter.filter(triples, fn(xs) {
    return xs[1] < xs[2]
  })

  // Euler 9 has one answer for n=1000. find() stops the entire upstream
  // iterator chain as soon as the first Pythagorean triple is found.
  answer := iter.find(triples, fn(xs) {
    return sqr(xs[0]) + sqr(xs[1]) == sqr(xs[2])
  })

  print(answer)

  if answer != nil {
    print(answer[0] * answer[1] * answer[2])
  }
}

main()

⤋ Read More
prologic
twtxt.net
 (2w ago)

It is such a nice feeling that Mu is such a capable little language 😅 And I decided to write code code in Mu by hand 🤚 haha 🤣 and start solving Project Euler problems, like Problem 8 which works out to be a nice elegant solution in Mu:

#!/usr/bin/env mu

// Largest Product in a Series

import "fp"
import "sys"

fn usage() {
  print("Usage: cat |", args()[0], "<n>")
}

fn products(xs) {
  return fp.reduce(xs, 1, fn(x, y) {
    if y == nil {
      return x
    }
    return x * y
  })
}

fn main() {
  if len(args()) < 2 {
    usage()
    exit(1)
  }

  s := must(sys.read_all(0))
  if len(s) == 0 {
    usage()
    exit(1)
  }

  n := must(int(args()[1]))
  r := fp.max(fp.map(fp.sliding(fp.map(s, int), n), products))
  print(r)
}

main()

⤋ Read More
movq
www.uninformativ.de
 (5w ago)

I am sooooooooooooooooooooooooooooooooooooooooooooooooOOOOOOOOOOOOOOoooooooooooooooo tired of “fast-moving” software. ruff changed a ton of stuff and now all my code bases “need fixing”. Blah.

And SemVer is worth nothing if your 4 year old program with over 16’000 commits is still at “version 0.x”. Blah!

Everything is horrible.

⤋ Read More
prologic
twtxt.net
 (6w ago)

Does this seem right to you so far @david@daiwei.me ? 🤔

2026/07/18 02:55:52 sync-reaper: observe-only pass — 1145 namespaces, 3 anchored, 1089 undatable, 0 idle candidate(s), 0 reaped

So far only 3 users of the Twtxt App have achieved their device settings with a recovery key? 🔑

⤋ Read More
movq
www.uninformativ.de
 (7w ago)

I really think I should go back to Java.

Writing programs in Python is so exhausting. I want a compiler and I want static typing. No, linters and type checkers and IDEs are not good enough. Compilers catch way more errors in advance.

Rust is also exhausting. They’re constantly adding language features and, at the same time, the runtime library remains tiny and you need 3rd party libraries for everything. Many of those are still at version 0.x (SemVer!) and you can’t rely on anything. Often times, you need the latest Rust nightly compiler.

Go is … I don’t like it. And huge binaries.

I like C as a language, but it’s too fragile. I want to have a proper HashMap every now and then.

None of the above have good GUI libraries, at least not on Linux.

And then there’s Java. This is my fractal renderer that I wrote over 17 years ago:

https://movq.de/v/fcd3c4e557/vid-1784121825.mp4

It’s fast. It has a GUI with custom widgets and those weren’t even hard to make. It still works without changing a single line of code. The source code files have timestamps from 2009 and I just noticed that the JAR file I’m using in the video was compiled in 2010.

Java as a language is relatively easy to learn and to master. There are few surprises. The source code organization with packages is good. Java API docs are clear and well written.

The JVM ramp-up times have improved considerably:

https://movq.de/v/e7314e521e/vid-1784121998.mp4

This isn’t like the Dark Ages anymore. Might even be usable for some CLI tools.

The only thing where Java really sucks is anything close-ish to the kernel. Try issuing an ioctl() … I couldn’t have made my TUI framework in Java, but then again, I wouldn’t have needed to because Swing already exists and it just works.

⤋ Read More
lyse
lyse.isobeef.org
 (7w ago)

Hurray, I can now press gg instead of g to go to the top in tt. Much better! :-) Other multi-key combinations are also easily possible now.

I should probably write a real article about this at some point, but here we go. The only downside with my new key binding system is that it breaks tview’s established pattern. You’ve got an InputHandler(), that is implemented using WrapInputHandler(…). It typically then directly implements the switching logic depending on the key press. Something like this:

func (w *Widget) InputHandler() func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
    // WrapInputHandler allows for intercepting key events with SetInputCapture(…)
    // from the outside for customization. This handles the default key bindings.
    return t.WrapInputHandler(func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
        switch event.Key() {
        case tcell.KeyRune:
            if event.Modifiers() == tcell.ModNone {
                switch event.Rune() {
                case 'k':
                    w.scrollUp()
                    return // we already handled the event, stop processing

                case 'j':
                    w.scrollDown()
                    return
                }
            }
        }

        // We didn't handle the key event. Maybe the parent
        // widget knows what to do with it.
        if handler := w.parent.InputHandler(); handler != nil {
            handler(event, setFocus)
        }
    })
}

From the outside, you can intercept and either stop or continue the widget’s original key handling with a potentially rewritten key event using SetInputCapture(…):

w := NewWidget()
// customized or additional key bindings
w.SetInputCapture(func(event *tcell.EventKey) *tcell.EventKey {
    switch event.Key() {
    case tcell.KeyUp:
        // Rewrite the event, so the "cursor up" key is an alias
        // for the vim key binding "k", that is handled by the
        // wrapped input handler above. (I know, I know, this is a
        // completely unrealistic example, why would anyone use
        // cursor keys when there are vim key bindings available?!)
        return tcell.NewEventKey(tcell.KeyRune, 'k', tcell.ModNone)

    case tcell.KeyRune:
        if event.Modifiers() == tcell.ModNone {
            switch event.Rune() {
                case 'q':
                    app.Stop()
                    // we already handled the event, do not pass it
                    // to the wrapped input handler above
                    return nil

                case 'r':
                    toggleMessageReadStatus()
                    return nil
            }
        }
    }

    // we didn't handle the event, pass it to the wrapped
    // input handler above
    return event
}

Since they all expect a single key, I’ve noticed that using multiple dedicated KeyBindings of mine on these different levels kinda breaks multi-key handling with common prefixes. The outer-most KeyBinding captures the prefix, but it can’t transfer it to the inner one if not handled by the outer one. At least not without some more (potentially ugly) changes. So, I now have to work with just a single KeyBindings object for the entire widget chain (if it consists of multiple other widgets or the regular input handler and input capture are in the game). The outside needs to register all its key bind customizations or extensions at the same level that the original widget handles its default ones. Doable by exposing the widget’s KeyBindings instance, but not pretty. You always have to keep this in mind.

With the KeyBindings, it will look like that:

type Widget struct {
    parent tview.Primitive

    // make it available to children or the outside either by
    // direct field access or by providing a getter method
    KeyBindings *bind.KeyBindings
}

func NewWidget() *Widget {
    w := &Widget{KeyBindings: &bind.KeyBindings{}}
    w.KeyBindings. // default key bindings
        Bind0(bind.KeySequence('k', w.scrollUp).
        Bind0(bind.KeySequence('j', w.scrollDown)
    return w
}

func (w *Widget) InputHandler() InputHandler() func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
    return t.WrapInputHandler(func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
        // also note the missing support for focus transfer at the moment
        event = w.KeyBindings.Capture(event)
        if event == nil {
            return
        }

        if handler := w.parent.InputHandler(); handler != nil {
            handler(event, setFocus)
        }
    }
}

And then from the outside, or in a child widget:

w := NewWidget()
w.KeyBindings. // additional or customized key bindings
    Bind1(bind.KeySequence(tcell.KeyUp), func(*tcell.EventKey) *tcell.EventKey {
        return tcell.NewEventKey(tcell.KeyRune, 'k', tcell.ModNone)
    }).
    Bind0(bind.KeySequence('q'), app.Stop).
    Bind0(bind.KeySequence('r'), toggleMessageReadStatus)

When directly working with tview primitives that are not part of custom widget implementations, the following works well so far:

textView := tview.NewTextView().
    SetWordWrap(true).
    SetText("…")
    SetScrollable(true)
textView.SetInputCapture((&bind.KeyBindings{}).
    Bind0(bind.KeySequence('q'), app.Stop).
    Bind1(bind.KeySequence('g', 'g'), func(*tcell.EventKey) *tcell.EventKey {
        return tcell.NewEventKey(tcell.KeyHome, 0, tcell.ModNone)
    }).
    Capture)

I need to sleep on this some more.

Also, writing very long messages like this one is really not all that fun in tt’s editor. I should absolutely provide a way to shell out to vim.

(Took me about one and a half hours to compose, holy crap. But not only because of not using vim. Although, that might have saved me a quarter hour or so for sure. Proof-reading this message also uncovered quite a few bugs in my real documentation. So, that’s a big win!) Good night!

⤋ Read More
prologic
twtxt.net
 (7w ago)

🥳 Finally! After nearly 4 years, yarnd v0.16.0 “Silver Sojourner” is out! 🚀 Twt Hash v2, SQLite FTS5 search, HTMX-powered UI, first-time setup wizard and literally hundreds of bug fixes 🐛

Release notes: https://git.mills.io/yarnsocial/yarn/releases/tag/0.16.0

Upgrading is fully automatic — the Twt Hash v2 migration re-fetches all feeds on first start, so expect the first cycle to be a bit heavier. Images on Docker Hub as prologic/yarnd:0.16.0 👌

cc @kat@yarn.girlonthemoon.xyz @abucci@anthony.buc.ci @shinyoukai@yume.laidback.moe @eldersnake@we.loveprivacy.club 🙏

⤋ Read More
movq
www.uninformativ.de
 (8w ago)

@GabesArcade@gabesarcade.com The no-JS part is one thing, but you also have to disable the (nowadays common) forced-HTTP-to-HTTPS-redirect, because those old browsers can’t do modern crypto. And make sure that your webserver serves the correct page even if no Host header is sent by the client. And don’t even think about serving UTF-8 or even just putting utf-8 in the content type. 😅 And for the JPEG thumbnails I pass a special flag to ImageMagick so that IBM Web Explorer from OS/2 won’t trip. 🤣 And always use link rel="stylesheet" for CSS, because some browsers render inlined CSS as literal text. And … probably more that I forgot by now. 😂

@david@daiwei.me Not sure, actually. Let’s see. Those are the ones where I still have the original disks (or have bought them on eBay again):

  • SuSE Linux 6.4 (it’s a massive 7 CD distro with a huge manual, best thing ever)
  • OS/2 2.1
  • OS/2 Warp 3 (red and blue spine because $reasons)
  • OS/2 Warp 4
  • PC DOS 7
  • MS-DOS 6.22
  • Windows 3.1
  • Windows for Workgroups 3.11
  • Windows 95 C
  • Windows 98
  • Windows NT 4 Workstation (still in the mail, though 😅)
  • Windows 2000
  • Windows XP Professional (last Windows I ever used on my private PCs)

(Plus a few “classic” office products as can be seen here: https://movq.de/blog/postings/2024-05-23/0/POSTING-en.html )

⤋ Read More
lyse
lyse.isobeef.org
 (8w ago)
↳ In-reply-to » The mentioned go.{mod,sum} change is already part of tview 0.42.0. After implementing Set/GetDisabled(…) and PasteHandler(), tt starts up fine and seems to work without issues.

After updating to tview 0.42.0, I also sadly noticed, that the tview.Modal now clears the background and doesn’t simply draw over the already present widget. So, I decided to write my own Dialog widget. This endeavor lead me down the path to actually bring back a custom Button implementation, too. When the button is focused, it surrounds the button text with [ and ]. When not in focus, the brackets are removed. Much better than before (https://twtxt.net/conv/qx3vz4a):

Image

I also use the same buttons in the compose view, too.

⤋ Read More
lyse
lyse.isobeef.org
 (9w ago)
↳ In-reply-to » Fuck me! I tried to upgrade tview and the first thing I notice is a shitload of added dependency versions:

The mentioned go.{mod,sum} change is already part of tview 0.42.0. After implementing Set/GetDisabled(…) and PasteHandler(), tt starts up fine and seems to work without issues.

⤋ Read More
movq
www.uninformativ.de
 (9w ago)

Interesting, HTTPS is almost twice as slow as plain HTTP on my server (~72 ms vs. ~135 ms):

$ hyperfine -r 50 "curl -so /dev/null 'http://movq.de/blog/postings/2024-05-23/0/t/word11a.jpg.jpg'"
Benchmark 1: curl -so /dev/null 'http://movq.de/blog/postings/2024-05-23/0/t/word11a.jpg.jpg'
  Time (mean ± σ):      72.7 ms ±  17.2 ms    [User: 6.2 ms, System: 4.8 ms]
  Range (min … max):    49.5 ms …  99.7 ms    50 runs

$ hyperfine -r 50 "curl -so /dev/null 'https://movq.de/blog/postings/2024-05-23/0/t/word11a.jpg.jpg'"
Benchmark 1: curl -so /dev/null 'https://movq.de/blog/postings/2024-05-23/0/t/word11a.jpg.jpg'
  Time (mean ± σ):     135.5 ms ±  28.9 ms    [User: 17.8 ms, System: 5.6 ms]
  Range (min … max):    93.2 ms … 198.5 ms    50 runs

⤋ Read More
movq
www.uninformativ.de
 (10w ago)
↳ In-reply-to » @movq Yeah, that would also be fine with me. I certainly do like the "arbitrary" in your comment.

@lyse@lyse.isobeef.org Mhm, yeah, I also think I like date := time.Date(2026, time.June, 19, /**/ 17, 0, 0, 0, time.UTC) the most. 🤔 (My only gripe with this is that it isn’t obvious whether the third 0 is milli-, micro- or nanoseconds. These days it’s probably nanoseconds, but you never know.)

⤋ Read More
lyse
lyse.isobeef.org
 (10w ago)
↳ In-reply-to » @lyse Oh wow, we’re talking about such a detailed level. 🤔

@movq@www.uninformativ.de Yeah, that would also be fine with me. I certainly do like the “arbitrary” in your comment.

While writing the article, I also thought about something like that:

date := time.Date(2026, 6, 19,
    17, 0, 0, 0, time.UTC)

Or possibly:

date := time.Date(
    2026, 6, 19,
    17, 0, 0, 0, time.UTC,
)

But it’s four lines for a damn timestamp. I also contemplated whether a comment acting as a separator is all that’s needed:

date := time.Date(2026, 6, 19, /**/ 17, 0, 0, 0, time.UTC)

I might like that the most. Not entirely sure yet. It kinda feels like a hack, but still a little elegant. Add your comment on top and we’re golden. Maybe?

I deliberately excluded them as this only distracted from the points I wanted to make. And I also realized that this example was just not ideal at all. Perhaps I should add them nevertheless?

If I ever invented a programming language, a much more human readable timestamp representation of some sort, RFC 3339 or very close to that would be part of that language. Something along the lines of /pattern/ for regexes in certain languages.

⤋ Read More
movq
www.uninformativ.de
 (10w ago)
↳ In-reply-to » In the light of current events, I will first consult my pillow and only then write an article about readable code.

@lyse@lyse.isobeef.org Oh wow, we’re talking about such a detailed level. 🤔

I agree with most of what you said.

I probably would have written it like this:

// Arbitrary reference date.
//                   Y  m   d   H  M  S  nano
date := time.Date(2026, 6, 19, 17, 0, 0, 0, time.UTC)

Would this be better or worse? 😅

⤋ Read More
movq
www.uninformativ.de
 (11w ago)
↳ In-reply-to » Speaking of UIs, this is how Thunderbird looks now:

@lyse@lyse.isobeef.org

But it’s Windows, it doesn’t have a place in my heart.

The older I get, the more I’m glorifying anything pre XP. 😅 But that’s only because everything today is so horrible.

Well, not anything pre XP. 3.0 or newer would be nice, because Windows 2.x was still pretty bare bones:

https://movq.de/v/00162b9df8/

(OS/2 was great, though, except for the lack of a good file manager.)

⤋ Read More
lyse
lyse.isobeef.org
 (11w ago)

@movq@www.uninformativ.de Regarding https://movq.de/blog/postings/2026-06-16/0/POSTING-en.html:

In my opinion, the KDE 3.5 menu was organized way better than the Windows Start menu. Granted, a typical KDE installation had much more applications to offer, too. So, there was more need to get it right. And it probably was also later in time.

Isn’t Notepad++ and Python cheating!? :-D

Crazy story on the clock’s seconds. I never heard of that before. Neat.

Yeah, UI these days is horrible. (That’s why my own TUIs suck, too!)

⤋ Read More
lyse
lyse.isobeef.org
 (11w ago)
↳ In-reply-to » @lyse Is it this one? https://github.com/rivo/tview It’s almost 10 years old but hasn’t seen a 1.0.0 release yet? 🤔

@movq@www.uninformativ.de Yes. The author tries hard not to break existing code, but apparently he did this time. In his defense, it’s not an official release, I just updated to master. Which is exactly what I always did in the past as there are no real versions (I even think that in one ticket he wrote years ago that master is always stable). That has finally changed a year ago, though: https://github.com/rivo/tview/releases/tag/v0.42.0

⤋ Read More
movq
www.uninformativ.de
 (11w ago)
↳ In-reply-to » Every now and then, I think that I have carefully proof-read my message enough times and hit the "Add message" button in tt. But then, in the message tree, I spot another missed typo. My process is then to go to my twtxt.txt and fix it by hand. However, I still have to clean up tt's cache. This is rather tidious:

@lyse@lyse.isobeef.org Is it this one? https://github.com/rivo/tview It’s almost 10 years old but hasn’t seen a 1.0.0 release yet? 🤔

⤋ Read More
lyse
lyse.isobeef.org
 (11w ago)
↳ In-reply-to » Oh boy, I absolutely hate this stupid trend of not writing changelogs anymore! Why the fuck would one seriously consider it to be a viable option to just let some shitty bot spew all merge requests on a goddamn GitHub release?! First of all, these merge request titles suck balls. The order of the changes in this "changelog" is completely random (well, probably merge time, which is as useless as the dick on the Pope). They are not grouped by anything at all. Additions, changes, removals, deprecations, etc. randomly mixed up in one giant list. And then "Add feature X", seventeen kilometers further down "Revert 'Add feature X'". Fuck you! Don't include this shit in the first place!

@movq@www.uninformativ.de You may want to include another antipattern to avoid in your article:

  • bump $same_dependency from 1.0.0 to 1.0.1
  • bump $same_dependency from 1.0.1 to 1.0.2
  • bump $same_dependency from 1.0.2 to 1.1.0
  • bump $same_dependency from 1.1.0 to 1.2.0

⤋ Read More