Re: [dev] alternatives to C: Ada, Rust, Pascal
On Fri, Jun 21, 2024 at 06:48:53PM +0200, Страхиња Радић wrote: > Дана 24/06/21 10:45AM, Greg Reagle написа: > > Rust also has some good safety and ease-of-use features. It is very > > big and complex with a lot of features (compared to C). > > Previous thread, now necroed: > > https://lists.suckless.org/dev/2104/34265.html > > > * * * > > Rust sucks. It was made by Big Tech (Mozilla) and aggressively > advertised as a replacement for C. There are numerous "replacements" > for Unix tools rewritten in Rust, all following the same "mainstream > dev" pattern. Rust appears to be the number one largest programming language package in Gentoo, with a 314MB download (155MB for the binary version). GHC is probably second place, at 147MB, unless you count LLVM and Clang together, which would be 250MB. I'm sure it's this big for a very good reason, but when compiling a compiler takes all day, and then it crashes because it ran out of RAM or hard disk space or whatever, it just makes me a bit sad. > C needs no replacement. C is a mature, standardized language (unlike > Rust), tightly intertwined with Unix and Unix-like systems as described > by POSIX. It would be nice, though. I'm generally in favor of having more good things. > Pascal is a language tailored for introductory level programming. It > was used in high school and freshman university courses here in the > late 90s and early 2000s. I don't know of any examples of serious > software written in Pascal. The original Pascal as conceived by Niklaus Wirth in 1970 is worth checking out, if you're interested in computing history. Maybe. Most "serious" Pascal software is probably actually written in Delphi, an object-oriented GUI-equipped dialect created by Borland. Check out FreePascal if the idea of writing C++ with one hand tied behind your back sounds appealing to you. > Ada was already mentioned in your previous thread that I linked above, > as an alternative to Rust if one cares about "safe" languages. It was a > heavily extended version of Pascal made for the use of USAF. Ada is theoretically interesting, but I think enjoying using it requires a very specific type of personality. Check it out if you get a thrill from filing out tax forms. > * * * > > Safety is overrated. The more "safe" a language is, the less it can do. > The more the programmer is "protected" from "shooting himself in the > foot", the less control he has over the program. The most powerful > language is assembler/machine code, and C is very close. > -- Storkman
Re: [dev] [dwm][st] why use ints over bools?
On Fri, Jun 21, 2024 at 10:12:15PM +0200, Mattias Andrée wrote: > On Fri, 21 Jun 2024 21:14:19 +0200 > Markus Wichmann wrote: > > > Am Thu, Jun 20, 2024 at 11:53:45PM +0200 schrieb Страхиња Радић: > > > Given that, why complicate code by introducing a separate, superfluous, > > > type? > > > > Let me offer a counterpoint: Expressiveness. If I make a function return > > a bool, then everyone from the world's worst junior dev to Ken Thompson > > himself will be able to see at the very first glance that the function > > is returning a boolean value. If I make a function return an int, that > > is not so clear. > > Expressiveness is great, but _Bool is more than just an expression of > intent. If _Bool was nothing more than a typedef of int, it would be great. > > However, in the real world, I also find that boolean isn't expressive enough > and enum is needed. This is because people do silly things like returning > true or false, without it being obvious that the function should even return > anything at all, Doesn't the function having a return type make it obvious that it returns something? > do indicate for example if the function was successful, > or the action was completed or need to be made again, or if the action > modified the stated (could be true if the state was not modified or true > if the state was not modified). If I have a function like "bool is_cromulent(foo)", I'd expect it to return true when foo IS cromulent (or 1 if the return type is int). Are you saying it should return cromulence_t with values either IS_CROMULENT or IS_NOT_CROMULENT? > > [...] Not so long ago, this very list opined that C89 is the only true > > C standard [...] If there was a new poll, I demand a recount! -- Storkman
Re: [dev] gtk2 without atk
On Thu, Jan 11, 2024 at 09:46:15PM +, stefan1 wrote: > > Hi dev ml readers. > I am going to shill some of my software on this list after getting it to > a decent point. > > I present to you, gtk2 without atk and forced accessiblilty: > https://github.com/stefan1/gtk2 > > And for those who want to use gtk3: > https://github.com/stefan1/atk > > Is anyone else here interested in this? > Does anyone have similar projects? Nice. I'm going to try this at the nearest opportunity, though I vaguely remember some config scripts explicitly checking for atk and dbus even though the application wasn't using them directly in any way... -- Storkman
Re: [dev] [license] gpl issues
On Thu, May 04, 2023 at 09:05:39AM +0100, Ray Garner wrote: > Hi > > I've been using suckless tools such as dwm and st for a while now and > think theyre great, my question is to do with software licenses. > > I'm curious about licensing and was wondering why suckless tools are > released under MIT rather than an alternative like GPL. Is it just to make > it compatible with more other software? Since I'm a hobbyist programmer and not a hobbyist lawyer, I just go by word count. If nothing else, it's a 100% objective standard. My current best choice is 0-clause BSD, which beats MIT by about 60 words. > Also, the GPL is included on the on the cat-v.org list of harmful software but > without explanation. Does anyone here know if its considered harmful for > compatability reasons or something else? > > Anyway, thanks for the programs. > > Cheers > Ray > -- Storkman
Re: [dev] [dwm] with SIGCHLD commit, dwm cannot launch dmenu_extended.
On Sat, Apr 08, 2023 at 04:28:15PM +0200, p...@mailbox.org wrote: > Hello everyone, > > I bind keyboard shortcut to launch dmenu_extended[1] in dwm, what works > flawlessly before the `Use sigaction(SA_NOCLDWAIT) for SIGCHLD > handling` [1] commit, since dmenu_extended does not change anything here, > is this a regression or bug introduced with this commit or > dmenu_extended need to adapt to conform the change? thanks. >From sigaction(2): > A child created via fork(2) inherits a copy of its parent's signal > dispositions. > During an execve(2), the dispositions of handled signals are reset to the > default; > the dispositions of ignored signals are left unchanged. This would explain why running programs affected by this through st works, since it runs "signal(SIGCHLD, SIG_DFL)" before executing the shell (st.c:715). Adding "signal(SIGCHLD, SIG_DFL)" before execvp in spawn() at dwm.c:1657 fixes anki and mpv with youtube-dl for me. > > [1] https://github.com/MarkHedleyJones/dmenu-extended/ > [2] > https://git.suckless.org/dwm/commit/712d6639ff8e863560328131bbb92b248dc9cde7.html >
Re: [dev] [dwm] Bluetooth XF86 keys not working
On January 17, 2023 3:03:52 AM UTC, Anskrevy wrote: >I've got XF86XK_AudioPlay bound in my config.h with the necessary >include file, and this hotkey works when I use my keyboard. However, >when sent from a pair of bluetooth headphones the hotkey isn't >triggered. I've got the following xev output which shows the two keys >are slightly different > This was actually recently fixed. https://git.suckless.org/dwm/commit/89f9905714c1c1b2e8b09986dfbeca15b68d8af8.html
Re: [SPAM Warning!][dev] [dwm] view() and toggleview() functions
On January 16, 2023 11:21:57 AM UTC, A Farzat wrote: >Btw, on the email subject it says [SPAM Warning!]. Is it anything I need >to be concerned with? Spam filters hate the .xyz TLD because it's supposedly "frequently used by spammers". I don't know why single out that one in particular, but it's enough for some servers to send perfectly legitimate mail straight to hell even if your mail server isn't on any actual blacklist. > >Thanks for clarifying! > >- Farzat
Re: [dev] [tabbed] utf8 characters not displayed in tabs
On Tue, Aug 30, 2022 at 10:23:44PM +0600, NRK wrote: > On Tue, Aug 30, 2022 at 05:36:31PM +0200, Hiltjo Posthuma wrote: > > " > > The font fallback in dwm and dmenu is handled via libsl (i.e drw.c) and > > it's a huge mess [0]. > > > > The way it works is also very inefficient (it calls XftFontMatch() for > > every single "unknown" code-point). The `nomatches` cache is merely > > there to stop the bleeding and is not really a proper fix. > > " > > > > This part specificly. The tone if very whiny. > > I see; the intention there was to just describe/explain why I think > replicating drw is not a good idea. It wasn't meant to be whiny. > > > It doesn't help complaining the code is a mess or improper without > > proposing a patch. > > The "proper" way (IMO) would be to build up a list of fonts which would > be capable of representing as many code-points available in the system > *right at startup* - instead of checking each unknown code-point as we > go. I'm a big fan of pre-calculating this list before compiling the program. > This way if the code-point cannot be found within the list; we'll know > right away that it's a missing glyph and there won't be any need to call > XftFontMatch for each "unknown" code-point. In my text editor, I just use a static pre-configured list of font names. It's very efficient, since there's only like four of them, and Xft keeps a bitmap of supported code-points in every loaded font. I can define exactly which fonts I want it to use without ever delving into the FontConfig XML Hell again. I suppose it's a difference in interpretation of what the "correct" behavior is. > The problem is, as I said, I'm not sure if it's even possible/feasible > with Xft/FontConfig as I'm not very familiar with those libraries. If > someone knows the answer, then feel free to speak up. There's the 'lang' and 'charset' properties, but more generally, the "set of fonts covering as wide variety of code-points as possible" ...is just the set of all installed fonts, isn't it? What exactly are we looking for here? If your question is simply "which code-points ARE NOT supported by ANY font", you could just iterate over all fonts and OR their charsets together. $ time fc-list '' fullname charset >/dev/null 0m00.06s real 0m00.05s user 0m00.01s system > If it is possible and someone can point out which routines I should be > looking at then I can try to take a crack at it. In case that's not > possible, then there's probably not a whole lot that can be done about > the situation. > > - NRK > - Storkman
Re: [dev] [dwm] Need help about gray windows of Java applications
On May 14, 2019 10:37:57 AM UTC, Enan Ajmain <3nan.ajm...@gmail.com> wrote: >Thanks. It worked. > >I've added `wmname LG3D` in xinitrc, but it doesn't work for some >reason. But I invoked in manually from bash before launching logisim >and it worked fine. I don't care about xinitrc, because I would have >liked to use this method only for that one application only anyway. Perhaps because you're not using xinit to start X? >I have checked the page for wmname in suckless.org and found this >method listed there. Would you mind explaining what LG3D is and why >this was chosen as opposed to anything else? And one more thing, if I >invoke `wmname LG3D` from one bash instance, it would not manipulate >the other windows, right? As the suckless.org page states, it is a property of the root window, so no. It will affect everything forever... until you restart X, or change the property again. That being said, I've had wmname LG3D in my .xinitrc for years now, and it's never interfered with anything as far as I can tell. As for what "LG3D" is, apparently it used to be some wacky Java 3D window manager back in the magical times when that sounded like a good idea. -- Storkman
Re: [dev] [dmenu] running shell scripts in dmenu
On January 4, 2019 12:20:42 PM UTC, Caio Barros wrote: >Em qui, 3 de jan de 2019 às 23:22, Martin Tournoij >escreveu: > >> Note there is a typo in that hashbang, > >oops! I was typing as I went :D. Actually in the original script I >didn't add the shebang #!/bin/sh, but I did it now So you didn't test this script? Are you sure it's actually executable? -- Storkman
