Search
296 results for “zirias”
-
@zirias you may like #LibertyEiffel then! It's compiled @wollman @rubenerd @dexter
-
-
One of the ways I help avoid failures with raidz1 is by replacing HDD when they get to around 5 years old, or they start showing errors. Also, monthly scrubs helps ensure that the drives are getting fully utilized regularly which helps keep things healthy/accelerate detection of failures.
-
I have one little piece of custom platform-specific code in #qXmoji.
Background is that #Qt's QFileSystemWatcher doesn't work correctly on #NFS (and probably other network filesystems). It uses some platform mechanism (e.g. inotify on #Linux, kqueue on #FreeBSD) internally, so exact behavior probably depends on the platform. On FreeBSD, it *seemed* to work, but only when the change to the file on NFS is done from the local machine. 🙄
Now regarding this code:
https://github.com/Zirias/qxmoji/blob/master/src/bin/qxmoji/nfsdetect.c
-- I still have doubts.▪ Should it check for other filesystems as well? Which ones?
▪ Will this construct checking for 'BSD4_4' in <sys/param.h> reliably detect every OS derived from 4.4BSD (assuming a POSIXy system that *has* sys/param.h)?
▪ Should it have implementations for *other* POSIXy systems than 4.4BSD-descendants and Linux?
▪ Why the hell is there no standard for checking the *filesystem* a file resides on? 🧐😁 -
#qXmoji v0.7 released!
https://github.com/Zirias/qxmoji/releases/tag/v0.7
This brings several improvements, mainly in the build system, but the major change is support for localization, with translated Emoji names imported from #Unicode #CLDR. I added a German translation, see screenshot. Once again, I'd appreciate more translations, the process to translate is documented here:
https://github.com/Zirias/qxmoji/blob/master/TRANSLATE.mdUpdated FreeBSD port:
https://people.freebsd.org/~zirias/patches/0001-x11-qxmoji-Add-new-port.patch -
#qXmoji is now completely translatable, and fully localized for 🇩🇪.
So, here comes a request for contributions 😁 (pretty please 🙃):
More languages would be nice! Therefore I documented the process to add them here:
https://github.com/Zirias/qxmoji/blob/master/TRANSLATE.md -
Adding features in a module with clear boundaries is so much more fun!
I just added different modes for using #Qt's #moc to my new USES=qt in my #gmake framework ... Testing it with #qXmoji (my new #X11 #emoji #keyboard) in the mode that just includes moc-generated stuff, and it works like a charm. No more extra compilation steps for moc, this whole build log now looks nicely short (screenshot: build from entirely clean git checkout) 🥳
https://github.com/Zirias/qxmoji/commit/928bc8a1cc0fd1a54908bda13ba31042ed6b1471
-
I'm one of these mad guys refusing to pull some "modern" buildsystem (like cmake or meson) into my projects, yet also dislike the complexity and overhead of autotools ... so I created my own "buildsystem" many many years ago, which is basically a #gmake (#GNU #make) framework using "eval" to generate rules on the fly.
Over the years, I piled up features in there as I needed them for current projects. The result is (although it still "worked") chaos. 🙈 More and more, I'm having trouble understanding my own code, and changing things is almost guaranteed to also break things. 🙄
I now decided to refactor a lot, giving some structure to that mess, and took inspiration from #FreeBSD's #ports framework by introducing a "USES" concept to load optional parts. So far, this seems to turn out well, it also gives the opportunity to better document that stuff given the clear responsibility of each USES, see e.g. the one handling installation of freedesktop.org stuff:
https://github.com/Zirias/zimk/blob/master/lib/uses/fdofiles.mk
-
I now added a screenshot of #qXmoji on github. People need to see screenshots for some reason (I'm no exception) 😄
I wanted "default looks", so, disabled any #Qt theming and thought #fvwm3 with default config should be a very nice match for a tool targeting "plain #X11", and firing up a #Xephyr session, I was quite surprised how polished fvwm3's default config looks nowadays, even integrating #stalonetray when available 👍
I still prefer my custom config, but nevertheless, great job 🙂
-
#qXmoji v0.6 released!
https://github.com/Zirias/qxmoji/releases/tag/v0.6
This brings a *lot* of improvements and fixes, the most relevant being immediate persistence of settings and watching the settings file for external changes. To make this feasible also for restoring the history, a lot of work went into generating static emoji data that can be used efficiently (e.g. containing a hash table to find an emoji quickly).
BTW, this even works on #NFS, so if you have your home shared and you're running qXmoji on two machines as the same user, the history will auto-update in both instances 🥳
-
#qXmoji v0.5 released!
https://github.com/Zirias/qxmoji/releases/tag/v0.5This brings a *few* of the ideas I had:
🔹Add a "single instance" mode (configurable)
🔹Add a "tray icon" (configurable behavior)
🔹Add an "About" dialog
🔹Enforce using Qt's "xcb" platform
🔹Fix detaching on startup, add a flag (-d) to prevent itPretty usable as it is I hope ... although one could of course improve a lot (but have you heard of the 80-20-rule?) 🫣
Screenshot from #KDE this time, no particular reason, I'm still running #fvwm here 😎
-
Guess I *did* enter "shady areas" writing commit messages like this:
https://github.com/Zirias/qxmoji/commit/2a404cd195619265559f9cced21f89ce3d129f40
In theory, all #EWMH window managers should behave the same, I thought ... 😂🙈
-
Found a small bug, #xcb requests were synchronously checked, but this only works when calling the _checked() flavor of them ... 🙈
Fixed in #qXmoji v0.4
Also added a clear button to the search field, this seems somewhat useful 😉
-
🥳 #qXmoji v0.3 released 🍻🍕
Now there are the "basic" features you'd expect from an emoji keyboard:
✅ Search as you type
✅ Recently used -
#qXmoji v0.1 and v0.2 released 😎
Functionally the same (just clickable emojis in tabbed groups, display size and wait-time for restoring the X11 keyboard map configurable), but v0.2 has correct README info and build-fixes, so Qt tools are found without fiddling with make variables 🙈 so, use v0.2 😎
-
That's the thing that you're missing.
"full terminfo support" *is not* solely just providing the libraries, in the world that we live in, as there are things that do not need the libraries. It's actually not unreasonable to find independent implementations that *just* require the identical data files, which ironically are not part of the standard. Because the world can and does code to *them* not to (n)curses or even to libterminfo.
-
That's the thing that you're missing.
"full terminfo support" *is not* solely just providing the libraries, in the world that we live in, as there are things that do not need the libraries. It's actually not unreasonable to find independent implementations that *just* require the identical data files, which ironically are not part of the standard. Because the world can and does code to *them* not to (n)curses or even to libterminfo.
-
Actually you did: "Using termcap/terminfo directly nowadays means using curses." I hope that you understand the point that I was making, now. I don't want to belabour it. (-:
Things come along that expect either the #termcap compatibility functionality of #terminfo and break on true termcap, or the existence of true terminfo databases. Not often enough to press #FreeBSD to change, it appears, but still on a regular basis.
-
You said: "Using termcap/terminfo directly nowadays means using curses. All the libraries needed for that are provided by curses (and nothing else)."
That's wrong. There are things around that don't use (n)curses and access #terminfo directly. (n)curses isn't the one-and-only abstraction that everyone uses. The world needn't write to it, and cases come along again and again where providing (n)curses libraries isn't enough. One has to provide the exact same database.
-
@JdeBP @mpts I never said there was no software using #terminfo databases directly, I just don't follow your argument this was a problem on #FreeBSD. These files are provided from a port/package, just install it (when "porting", add a run-dependency) 🤷♂️
I certainly see the need why people come up with something like this. The "classic" implementations force you to add silly "singleton" stuff like this:
https://github.com/Zirias/dos2ansi/blob/c606482c1723273dfd1251acd0d466f69a0ae58e/src/bin/dos2ansi/ticolorwriter.c#L51
... which wasn't a problem here, but as soon as you'd go multithreaded, you'd have to properly lock-guard this, and even worse, say you'd want some service serving different clients with different terminals simultaneously, you'd have to spawn a child process for each and every client 🙄 -
You haven't experienced nearly enough softwares. (-:
There have been alternatives to those, that are binary compatible with the #terminfo database files, but that are otherwise designed from scratch, for years now. As I said, #NeoVIM used one.
I have this vague memory that go goes its own way on this, too, but I might be mis-remembering. I've definitely seen over the years several ground-up implementations outwith C and C++ development.
-
It might be worth checking how well Write-Progress and its ilk work with only #termcap. And colourization of the error stream and suchlike.
-
Wrong. There are libraries around that don't use (n)curses and access #terminfo directly. I remember this pain with NeoVIM and FreeBSD some years back. #NeoVIM used one of these non-curses libraries that provided direct access to terminfo.
(n)curses isn't the one-and-only abstraction that everyone uses.
-
That's not enough. There are plenty of things that use #termcap/#terminfo directly without using (n)curses. And as you've seen there are cases where the two aren't exactly the same.
There is a persistent very slow trickle of instances where people come along with something new, which works with terminfo (or its termcap compatibility shims) on every other operating system, and true termcap turns out to be a gotcha in some subtle way. Because no-one targets it any more.
-
-
And now, the full docs for #dos2ansi v2.0 are available online as well:
https://zirias.github.io/dos2ansiIMHO manpages are an awesome documentation format. And with a little bit of "responsive" #CSS, they're well usable on a mobile as well -- I wished the typical "online man" sites would do something like that 😉
-
Released: #dos2ansi v2.0
https://github.com/Zirias/dos2ansi/releases/tag/v2.0The real "visible change" is documentation. #showansi now got a manpage as well, and the one for #dos2ansi improved a lot. Also better build instructions and some updates/corrections in the README. With these docs, you can hopefully make it do exactly what you want 😉
Also, the build system (my own homebrewn #GNU #make framework) got lots of improvements and fixes.
https://github.com/Zirias/zimk/ -
I'm planning to create a release #dos2ansi v2.0 soon, which will have more or less the feature set of v1.8, but with complete and helpful documentation for everything. Main work left to do for that is to add more text to the manpages 😉
At least, the tool I wrote for generating docs now has everything I'll need for that!
-
Here's a quick demo how the new documentation generation in #dos2ansi works 😎
https://github.com/Zirias/mkclidocScreenshots:
- Input format (on github)
- help (-h) output (on #Windows)
- manpage (on #FreeBSD)Might make sense to add some #HTML output as well, e.g. for the Windows binary package... 🤔