Re: [dev] C variants, compilers and completeness
On Mon 24 Jul 2023, Sagar Acharya wrote: > > I see C compilers recommended by suckless are: > > tinycc > simplecc > cproc > qbe > lacc > > Which variant of C do they offer? What are the differences and do they offer > sufficient features to express with a program completely? Whether they are sufficient depends on your use case. Everything else is covered in their documentation. https://bellard.org/tcc http://git.simple-cc.org/scc/file/README.html https://sr.ht/~mcf/cproc https://github.com/larmel/lacc
Re: [dev] Minimalist software. Should I care?
On Wed 05 Jul 2023, Nikita Krasnov wrote: > > > > I'm on this mailing list to stay in the loop on updates and patches to > > software I use. Not present evangelical arguments to someone who doesn't > > know what to believe in. > > [P]lus, it's not like it's too busy here anyways. Would you also remark on how empty your neighbour’s living room is as justification when you move your storage boxes into it? The list is certainly a lot busier with this thread on it than it was some time ago. Whether this is for the better or not I leave for others to decide. Some of us consider evangelism a disease. There is plenty on the website and elsewhere written about software minimalism. If using such software and the existing writing does not convince you, that is perfectly fine and you are no lesser of a human because of it and the existential angst is most likely unwarranted.
Re: [dev] [tabbed] utf8 characters not displayed in tabs
On Mon 29 Aug 2022, Seb wrote: > > I am using xterm under tabbed (v.0.6) and some of the polish > characters which are in the directory name are not displayed in the > tabs and the rest of the name is truncated, for instance: > > /home/seb/żółty is truncated to /home/seb/żó > > when I set the Xresource : > > *XTerm*utf8Title: True > > then the whole name is displayed with all polish characters but only > after I change directory to a new location, so the name in tab does > not refer to actual directory. I only started using tabbed the other day, but I also have issues with Unicode (in my case Japanese showing up as “tofu”). My intuition is that it is related to font loading and fall backs, so I am tempted to take a stab at it by comparing the font loading/handling between tabbed, dwm, st, and sent to see if I can spot any difference, as the latter three have no issues. If I am correct, it should not be an awfully difficult patch.
Re: [dev] [dwm] Incorrect resolution when turning on dual monitors
On Sat 07 May 2022, Yan Doroshenko wrote: > > Not sure if this is of any help, but I was having troubles with DWM on > two monitors as well, one screen was not recognized by DWM. > > A 1 second delay before running my screen layout script was enough to > fix it, here's an explanation: > > https://wiki.archlinux.org/title/xrandr#Setting_resolution_from_.xinitrc_doesn't_work Is the “right way” (tm) to do it not to set things up in your Xorg.conf though? I am assuming that your errors have something to do with the state of X when dwm is started, thus surely the way way to solve it should be to ensure that X is in the state you want *before* dwm is launched, no? I know the Xorg.conf syntax and documentation is a bit of a mess, but I have never encountered any issues interacting with a WM once I got it configured.
Re: [dev] Some direction with my project
On Fri 15 Apr 2022, Chibby Bromanson wrote: > On Fri, Apr 15, 2022 at 02:20:25PM +0200, Wolf wrote: > > On 2022-04-15 08:51:50 +, Hadrien Lacour wrote: > > > > > > Some implementation details: do you really need autohell when the only > > > thing > > > you use it for is to detect the presence of sys/xattr.h? That's only a > > > few lines > > > of sh calling cc to do the same. > > > Personally, I use POSIX sh to "augment" make with the usual stuff like > > > [un]install or what GNU make provides. > > > > Configure script provides lot more then detection though. I have yet to > > see a hand written make providing support for --program-prefix or > > --program-transform-name for example. For packaging software, these > > additional features are useful from time to time. > > This was the decision that I struggled with the most to be completely > honest. In the end though, this still ensures maximum portability and > greatly increases your chances of some kind soul packaging it up for > various platforms. Speaking as a package maintainer. I actually breathe a sigh of relief when I see a good old plain Makefile as I know that I am not about to have my understanding of obscure Autotools internals challenged in case something goes awry.
Re: [dev] requirements of build systems
On Tue 01 Feb 2022, NRK wrote: > On Mon, Jan 31, 2022 at 12:10:27AM +0200, Petros Pateros wrote: > > However, it was pointed out to me that relying on mtime can give wrong > > results, > > for example: > > (a) if the clock is set backwards or in case of insufficient granularity in > > mtime > > then a file that gets modified might have the same mtime > > (b) an mmap(2)-ed file can get modified but its mtime might not get updated > > soon enough > > How likely is it for these situations to occur in practice? If these are > practical problems, then it makes sense to solve them. Otherwise I think > it's best not to waste resource solving theoretical problems. Speaking for myself, I certainly have experienced issues with inaccurate timestamps on NFS for compute clusters where its use is very common. Not saying this as a supporter of NFS and the likes, just as evidence that it does occur in practice.
