Search
483 results for “zirias”
-
And here's the upcoming "feature" for #dos2ansi v1.2: Attempt to format #SAUCE comments nicely. 🙈
It seems to be common practice to wrap comment lines in the middle of a word, so here's an attempt to be "smart" with this, adding an (optional) formatting heuristic:
* Empty lines are alway printed as is
* Same for lines containing "drawing" characters (anything >= 0xb0 in #cp437)
* Otherwise, if the last character of a line *and* the first of the next line are non-space, it's assumed to be one word
* Formatted lines are filled with as many complete words as possible, preserving spaces except at the end of the line
* More than two spaces at the end of a (raw) line are interpreted as a line breakHere are two real examples of the result, while the second already shows some classic shit-in-shit-out case (to fix this, I'd probably need a language model 😂)
-
And here's the upcoming "feature" for #dos2ansi v1.2: Attempt to format #SAUCE comments nicely. 🙈
It seems to be common practice to wrap comment lines in the middle of a word, so here's an attempt to be "smart" with this, adding an (optional) formatting heuristic:
* Empty lines are alway printed as is
* Same for lines containing "drawing" characters (anything >= 0xb0 in #cp437)
* Otherwise, if the last character of a line *and* the first of the next line are non-space, it's assumed to be one word
* Formatted lines are filled with as many complete words as possible, preserving spaces except at the end of the line
* More than two spaces at the end of a (raw) line are interpreted as a line breakHere are two real examples of the result, while the second already shows some classic shit-in-shit-out case (to fix this, I'd probably need a language model 😂)
-
And here's the upcoming "feature" for #dos2ansi v1.2: Attempt to format #SAUCE comments nicely. 🙈
It seems to be common practice to wrap comment lines in the middle of a word, so here's an attempt to be "smart" with this, adding an (optional) formatting heuristic:
* Empty lines are alway printed as is
* Same for lines containing "drawing" characters (anything >= 0xb0 in #cp437)
* Otherwise, if the last character of a line *and* the first of the next line are non-space, it's assumed to be one word
* Formatted lines are filled with as many complete words as possible, preserving spaces except at the end of the line
* More than two spaces at the end of a (raw) line are interpreted as a line breakHere are two real examples of the result, while the second already shows some classic shit-in-shit-out case (to fix this, I'd probably need a language model 😂)
-
And here's the upcoming "feature" for #dos2ansi v1.2: Attempt to format #SAUCE comments nicely. 🙈
It seems to be common practice to wrap comment lines in the middle of a word, so here's an attempt to be "smart" with this, adding an (optional) formatting heuristic:
* Empty lines are alway printed as is
* Same for lines containing "drawing" characters (anything >= 0xb0 in #cp437)
* Otherwise, if the last character of a line *and* the first of the next line are non-space, it's assumed to be one word
* Formatted lines are filled with as many complete words as possible, preserving spaces except at the end of the line
* More than two spaces at the end of a (raw) line are interpreted as a line breakHere are two real examples of the result, while the second already shows some classic shit-in-shit-out case (to fix this, I'd probably need a language model 😂)
-
Little roadblock on the way, I can't install a #poudriere jail of #FreeBSD 13.2-RELEASE #armv7 using ftp ... the required dist files just aren't there on the mirrors 😞
But hey, you can always build yourself from source 😎 so ... waiting again. I expect this to work as well, but we will see.
-
Indeed, sanity-checking the new #Linux-native #GCC for #FreeBSD's #Linuxulator shows it works perfectly fine at least for C, and using static #libgcc (because I removed the libgcc_s.so file, should really be packaged separately) 🥳
So, to complete the toolchain, next steps will be separate ports for libgcc and libstdc++, should be possible to build these with this native gcc, we will see!
-
Indeed, sanity-checking the new #Linux-native #GCC for #FreeBSD's #Linuxulator shows it works perfectly fine at least for C, and using static #libgcc (because I removed the libgcc_s.so file, should really be packaged separately) 🥳
So, to complete the toolchain, next steps will be separate ports for libgcc and libstdc++, should be possible to build these with this native gcc, we will see!
-
Indeed, sanity-checking the new #Linux-native #GCC for #FreeBSD's #Linuxulator shows it works perfectly fine at least for C, and using static #libgcc (because I removed the libgcc_s.so file, should really be packaged separately) 🥳
So, to complete the toolchain, next steps will be separate ports for libgcc and libstdc++, should be possible to build these with this native gcc, we will see!
-
Indeed, sanity-checking the new #Linux-native #GCC for #FreeBSD's #Linuxulator shows it works perfectly fine at least for C, and using static #libgcc (because I removed the libgcc_s.so file, should really be packaged separately) 🥳
So, to complete the toolchain, next steps will be separate ports for libgcc and libstdc++, should be possible to build these with this native gcc, we will see!
-
Another little update on this endeavor .. native #Linux #GCC for #FreeBSD's #Linuxulator finally builds! 🥳
Still needs some "love" in detail (like, correct path for man files).
And also, I have to find a way to package #libgcc separately, cause most software built for Linux using GCC will need it, and it doesn't make sense that everything pulls in the whole GCC as a dependency ...
Well, maybe tomorrow then 🙈
-
Another little update on this endeavor .. native #Linux #GCC for #FreeBSD's #Linuxulator finally builds! 🥳
Still needs some "love" in detail (like, correct path for man files).
And also, I have to find a way to package #libgcc separately, cause most software built for Linux using GCC will need it, and it doesn't make sense that everything pulls in the whole GCC as a dependency ...
Well, maybe tomorrow then 🙈
-
Another little update on this endeavor .. native #Linux #GCC for #FreeBSD's #Linuxulator finally builds! 🥳
Still needs some "love" in detail (like, correct path for man files).
And also, I have to find a way to package #libgcc separately, cause most software built for Linux using GCC will need it, and it doesn't make sense that everything pulls in the whole GCC as a dependency ...
Well, maybe tomorrow then 🙈
-
Another little update on this endeavor .. native #Linux #GCC for #FreeBSD's #Linuxulator finally builds! 🥳
Still needs some "love" in detail (like, correct path for man files).
And also, I have to find a way to package #libgcc separately, cause most software built for Linux using GCC will need it, and it doesn't make sense that everything pulls in the whole GCC as a dependency ...
Well, maybe tomorrow then 🙈
-
@sourcerer @vermaden speaking of audio, the mess (really) started when #Linux devs deemed their #OSS variant "unfixable" and started with #ALSA. Introducing a shared lib here (libasound) lead to tighter coupling. And it got worse adding complex layers of "sound servers" on top.
#FreeBSD's native audio interface is still good old OSS/USS (based on /dev/dsp). It offers good quality, low latency AND "software mixing" of multiple playback clients out of the box, invalidating the reasons that in Linux world, the breaking change towards ALSA *had* to be done.
Still, what we see *now* is a decreasing number of applications supporting OSS, just because Linux typically doesn't offer it any more. 🙄
So far, I could make everything I needed work using either #sndio (a somewhat minimal sound server originating from #OpenBSD), native OSS, #SDL, and (rarely needed) ALSA using the OSS backend...
-
@walkerb Just for completeness, flicker-free graphics on the #C64 aren't achieved *only* by drawing speed. Like on any platform where you update some "framebuffer" that's used live by the gfx chips, even the fastest drawing routing will show flickering when executed at the "wrong" raster beam position.
So, you also have to care about #vsync (or: "race the beam"): only start drawing some area after the raster beam passed it.
-
@CyDeFect @FiLiS all of these are missing too many details to tell anything about them. Except for #CIFS (although you probably don't even want that but #SMB3 instead, #Linux just kept tthe "CIFS" name although supporting SMB3), all #FreeBSD offers is indeed #SMB1. Whether this is an issue or not depends on your scenario and environment. I just offer my shares via #NFS as well, problem solved for me.
BTW, #seamonkey was removed mainly because of a #python2 (EOL for a long time) build dependency. IIRC this is meanwhile solved, so the port *could* be readded, it's just someone would have to do it and maintain it. There's an inofficial port available, you'll find it on the forums.
-
@CyDeFect @FiLiS all of these are missing too many details to tell anything about them. Except for #CIFS (although you probably don't even want that but #SMB3 instead, #Linux just kept tthe "CIFS" name although supporting SMB3), all #FreeBSD offers is indeed #SMB1. Whether this is an issue or not depends on your scenario and environment. I just offer my shares via #NFS as well, problem solved for me.
BTW, #seamonkey was removed mainly because of a #python2 (EOL for a long time) build dependency. IIRC this is meanwhile solved, so the port *could* be readded, it's just someone would have to do it and maintain it. There's an inofficial port available, you'll find it on the forums.
-
@CyDeFect @FiLiS all of these are missing too many details to tell anything about them. Except for #CIFS (although you probably don't even want that but #SMB3 instead, #Linux just kept tthe "CIFS" name although supporting SMB3), all #FreeBSD offers is indeed #SMB1. Whether this is an issue or not depends on your scenario and environment. I just offer my shares via #NFS as well, problem solved for me.
BTW, #seamonkey was removed mainly because of a #python2 (EOL for a long time) build dependency. IIRC this is meanwhile solved, so the port *could* be readded, it's just someone would have to do it and maintain it. There's an inofficial port available, you'll find it on the forums.
-
@CyDeFect @FiLiS all of these are missing too many details to tell anything about them. Except for #CIFS (although you probably don't even want that but #SMB3 instead, #Linux just kept tthe "CIFS" name although supporting SMB3), all #FreeBSD offers is indeed #SMB1. Whether this is an issue or not depends on your scenario and environment. I just offer my shares via #NFS as well, problem solved for me.
BTW, #seamonkey was removed mainly because of a #python2 (EOL for a long time) build dependency. IIRC this is meanwhile solved, so the port *could* be readded, it's just someone would have to do it and maintain it. There's an inofficial port available, you'll find it on the forums.
-
Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳
Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!
They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).
Ok, no #scons yet, didn't need it so far 🙈
-
Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳
Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!
They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).
Ok, no #scons yet, didn't need it so far 🙈
-
Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳
Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!
They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).
Ok, no #scons yet, didn't need it so far 🙈
-
Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳
Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!
They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).
Ok, no #scons yet, didn't need it so far 🙈
-
@thindil I was talking about maintenance pain for devs btw. I assume much of it stems from having *most* of #LinuxKPI in the base kernel (where it actually belongs), but GPL-parts in the port, and also some fixes even duplicated (because the port must work on systems that didn't receive the fix from the main branch of base yet). With everything in the base kernel, you could maintain it in one place, and MFC fixes as a whole (and, if needed create ENs to also update RELEASE versions).
Of course, everyone wants a "reasonable" small base, discussions often evolve around what "reasonable" exactly is 😎