movq @www.uninformativ.de

Follow

Block / Report User

If this user/feed is violating this Pod's (yarn.meff.me) community guidelines as set out in the Abuse Policy, please report them immediately!

You are also free to Unfollow or Mute this user or feed. Muting will also remove that user/feed's content from your view and you will no longer see content from that user/feed anywhere.

@movq does not follow you (they may not see your replies!)

Recent Twts

Recent twts from movq

Why have these Unicode smilies never caught on, I wonder? 🤪

𜲦𜲩 𜲨𜲩 𜲦𜲧
𜲪𜲫 𜲮𜲯 𜲰𜲱

#hivf4vq

(#2p27wba) @lyse@lyse.isobeef.org

I assume you made the thing load quickly, didn’t you?

That’s the problem with Python. If you have a couple of files to import, it will take time.

I want this to be reasonably fast on my old Intel NUC from 2016 (Celeron N3050 @ 1.60GHz) and I already notice that the program startup takes about 95 ms (or 125 ms when there are no .pyc files yet). That’s still fine, but it shows that I’ll have to be careful and keep this thing very small …

Python 3.14 will bring lazy imports, maybe that can help in some cases.


#ukhs3rq

Well, you girls and guys are making cool things, and I have some progress to show as well. šŸ˜…

https://movq.de/v/c0408a80b1/movwin.mp4

Scrolling widgets appears to work now. This is (mostly) Unicode-aware: Note how emojis like ā€œšŸ˜…ā€ are double-width ā€œcharactersā€ and the widget system knows this. It doesn’t try to place a ā€œšŸ˜…ā€ in a location where there’s only one cell available.

Same goes for that weird ā€œĆ¤ā€ thingie, which is actually ā€œaā€ followed by U+0308 (a combining diacritic). Python itself thinks of this as two ā€œcharactersā€, but they only occupy one cell on the screen. (Assuming your terminal supports this …)

This library does the heavy Unicode lifting: https://github.com/jquast/wcwidth (Take a look at its implementation to learn how horrible Unicode and human languages are.)

The program itself looks like this, it’s a proper widget hierarchy:

https://movq.de/v/1d155106e2/s.png

(There is no input handling yet, hence some things are hardwired for the moment.)


#yiihgta

(#xwn45gq) @lyse@lyse.isobeef.org Well, I used SnipMate years ago (until 2012). IIRC, it’s more than just ā€œinsert a bit of text hereā€, it can also jump to the correct next location(s) and stuff like that. Don’t remember why I stopped using it.

Then I used nothing for a long time. Just before Christmas, I made my own plugin (… of course …), which does everything I need at the moment (and nothing more).

It can insert simple templates and then jump to the next location:

https://movq.de/v/67cdf7c827/sisni%2Dpython.mp4

And replace a string after insertion:

https://movq.de/v/67cdf7c827/sisni%2Dheader.mp4

(It’s not public (yet?) and it also uses vim9script, so I guess it wouldn’t work on your system.)


#f2cdpva

(#j5s5khq) @lyse@lyse.isobeef.org I’m toying with the idea of making a widget/window system on top of Python’s ncurses. I’ve never really been happy with the existing ones (like urwid, textual, pytermgui, …). I mean, they’re not horrible, it’s mostly the performance that’s bugging me – I don’t want to wait an entire second for a terminal program to start up.

Not sure if I’ll actually see it through, though. Unicode makes this kind of thing extremely hard. 🫤


#fazzzcq

(#gslvc3q) @prologic@twtxt.net That might be a challenge, at least in 16-bit Real Mode: The OS follows the model of COM files on DOS, i.e. the size of the binary cannot exceed 64 KiB and heap+stack of the running program will have to fit into that same 64 KiB. šŸ˜… (The memory layout is very rigid, each process gets such a 64 KiB slice.)

And in 64-bit Long Mode, there is no ā€œkernelā€ yet. The thing in the video is literally just a small bare-metal program.

But some day, maybe. 😃


#q6pehia

My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).

Here I’m running a little C program (compiled using normal GCC, no Watcom trickery):

https://movq.de/v/b27ced6dcb/los86%2D64.mp4

https://movq.de/v/b27ced6dcb/c.png

Next steps could include:

  • Use Rust instead of C for that 64-bit program?
  • Provide interrupt service routines. (At the moment, it just keeps interrupts disabled.)

#gslvc3q