Re: [dev] [dmenu][bug report] Second instance invisible
On Fri, Sep 22, 2023 at 12:22:25PM +0100, Christopher Lang wrote:
> I'm guessing that when the second dmenu opens, the first one is still
> fading out and this stops XCreateIC from working as intended?
Worth noting that according to the docs XCreateIC() may return NULL -
something that isn't checked for in dmenu. Perhaps you're getting a NULL
ic due to your config? Does the attached patch make any difference?
- NRK
>From defc910ce1fa51e3031af19abae8c70b3b8b8106 Mon Sep 17 00:00:00 2001
From: NRK
Date: Fri, 22 Sep 2023 23:42:10 +0600
Subject: [PATCH] check for XCreateIC failure
---
dmenu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/dmenu.c b/dmenu.c
index 40f93e0..a38e7b5 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -696,6 +696,8 @@ setup(void)
xic = XCreateIC(xim, XNInputStyle, XIMPreeditNothing | XIMStatusNothing,
XNClientWindow, win, XNFocusWindow, win, NULL);
+ if (xic == NULL)
+ die("XCreateIC failed");
XMapRaised(dpy, win);
if (embed) {
--
2.41.0
Re: [dev] [dmenu][bug report] Second instance invisible
NRK writes: > On Thu, Sep 21, 2023 at 02:02:12PM +0100, Christopher Lang wrote: >> I run the following shell command: >> seq 2 | dmenu && seq 3 | dmenu >> The first dmenu instance opens as expected. I hit the enter key and a 1 >> is printed. However, the second dmenu instance does not appear. > > Cannot reproduce on my system, tried on unpatched master branch and v5.2. > The 2nd dmenu instance appears just fine after the first one closes. > > If you can consistently reproduce, then attach gdb to the 2nd instance > (via `gdb --pid`) and try to inspect what might be going wrong compared > to a non-buggy case. > > - NRK I have discovered that the following line in my .xinitrc was causing the problem. xcompmgr -n -f -I 0.1 -O 0.1 -D 8 & Specifically, the fading effects (-f,-I,-O,-D). With these disabled, dmenu works fine. I tried attaching gdb to the second instance using the method you described, but it just sits on XNextEvent. And if I start the second dmenu with gdb already attached (i.e. seq 2 | dmenu && seq 3 | gdb dmenu), then the additional delay before the second dmenu opening means the error wont occur. I'm guessing that when the second dmenu opens, the first one is still fading out and this stops XCreateIC from working as intended? -- Christopher
Re: [dev] getting rid of cmake builds
Hi, On Fri, Sep 22, 2023 at 05:08:15PM +0200, Mattias Andrée wrote: > > You can used make to run ./configure automatically, all you need to do is > simply > rename Makefile to makefile.in, let ./configure run `ln -s makefile.in > makefile` > and create a new file named Makefile containing: > > .POSIX: > .DEFAULT: > ./configure > $(MAKE) -f makefile $@ I used this technique in scc at the beginning (in my case for inclusion dependencies, not for configurE), but it was a bit confusing for people and then I switched it to other solution that I think is worse. Maybe it is time to go back and use this solution again. Regards,
Re: [dev] getting rid of cmake builds
NRK writes: > On Fri, Sep 22, 2023 at 04:07:15PM +0200, Roberto E. Vargas Caballero wrote: > > can you explain me how you solve the problem of duplicated static > > symbols? > > It's not as big of a problem you're making it out to be. Neither dwm or > st for example has duplicated static symbols. No duplicate static symbols, no. It's far worse than that: st/st.c:#define IS_SET(flag)((term.mode & (flag)) != 0) st/x.c:#define IS_SET(flag) ((win.mode & (flag)) != 0) Matthew
Re: [dev] getting rid of cmake builds
On Fri, 22 Sep 2023 15:54:59 +0200 Laslo Hunhold wrote: > On Thu, 21 Sep 2023 16:05:17 +0200 > David Demelier wrote: > > Dear David, > > > It's near to impossible to convert a CMake project to make > > automatically, CMake is almost like a scripting language given the > > numerous of things you can do with it. > > > > Keep in mind that plain make (POSIX) is enough for really simple > > projects but can come limited when going portable. Although the use of > > pkg-config helps there are various places where you will need to pass > > additional compiler/linker flags. For those I like GNU make even > > though its syntax is somewhat strange at some points. > > > > Which projects are you referring to? > > the "POSIX makefiles are not easily portable" aspect hasn't been true > for a long time. Check out the build system of my project libgrapheme. > It is 100% POSIX make and portable across all BSDs, macOS, Cygwin, > MinGW and of course Linux, including automatically naming and embedding > the semantic version as specified in the Makefile. This is done by > providing a very simple ./configure script that automatically modifies > config.mk and tells the user when they are working from a system that > hasn't been ported to yet. You can used make to run ./configure automatically, all you need to do is simply rename Makefile to makefile.in, let ./configure run `ln -s makefile.in makefile` and create a new file named Makefile containing: .POSIX: .DEFAULT: ./configure $(MAKE) -f makefile $@ I think running ./configure isn't a big deal, however this technique is also very useful if you want to automatically generate rules and variables for Makefile. it's especially powerful because make(1posix) expressly states that `-f -` shall be interpreted as using stdin as the makefile. Extremely occasionally POSIX make can feel like it's not enough or at least not efficient enough (at write time or build time), and GNU make can fix these issues, however using this double makefile technique, all of these can be addressed (of course not always as nicely as non-standard features can). Just look at this beauty: https://codeberg.org/maandree/simple-icon-theme/src/branch/master/Makefile > > libgrapheme has automatic unit tests and code generators written in > C99, so it's probably a very extreme example. You could easily adapt a > library project using the libgraphmee configure+config.mk+Makefile as a > basic template. > > Feel free to contact me if you have any questions. > > With best regards > > Laslo > > [0]:https://git.suckless.org/libgrapheme/ >
Re: [dev] getting rid of cmake builds
On Fri, Sep 22, 2023 at 04:07:15PM +0200, Roberto E. Vargas Caballero wrote: > can you explain me how you solve the problem of duplicated static > symbols? It's not as big of a problem you're making it out to be. Neither dwm or st for example has duplicated static symbols. And it's easily solvable by having a slightly more descriptive name (avoiding unnecessary global variables also reduces chances of collision). > Can you explain me where is the complexity? I've already given a list of things on my initial post. But if I need to repeat one of them: Dependency tracking is easily the biggest problem that incremental builds introduce. Which is something that: a) your tiny example makefile did not tackle b) dwm makefile gets wrong as it does not track drw.h nor util.h (dmenu also fails to track util.h as well). Aside from that, unity-build only requires a compiler. A Makefile additionally requires (i) a Make implementation (ii) (usually) a posix compliant shell. Also this conversation feels like it's going in circles with me having to constantly repeat things I've already said, so I'll say this: If you're already convinced that a makefile is better than a unity build, then that's fine. I'm not interested in forcing you to use something else. Nor am I interested in fighting some editor^W build-system war. But I've tried out both makefiles (both simple and "complex" ones) and unity-build and *my* conclusion is that the latter is significantly simpler and superior for small projects - and I've given a list of reason on my initial post. If someone thinks those are valid reasons, then try it out. If not, then don't. - NRK
Re: [dev] getting rid of cmake builds
On 23/09/22 04:27PM, Страхиња Радић wrote: > ...according to sloccount[1]... [1]: https://dwheeler.com/sloccount/ signature.asc Description: PGP signature
Re: [dev] getting rid of cmake builds
On 23/09/22 07:27PM, NRK wrote: > And this is no longer the 50s, we have enough memory to build a couple > thousand line of code without *requiring* splitting things into multiple > intermediate object files to avoid going OOM (even with bloated > compilers like gcc/clang with optimization enabled). It's not about memory, it's more about how easy it is for a human to navigate the source code. Of course, cscope and ctags exist, and reducing the number of lines of code is desired, but it is not always possible to reduce a program below 1k lines of code, so it needs splitting into several units. For example (according to sloccount[1]), my patched dwm fork has ~3.3k lines of C code across 5 .c files, my patched st fork has ~4.9k lines of C code across 2 .c files, and slstatus has ~2k lines of C code. My own programs are close to those numbers: some have up to ~5k lines of code combined only in .c files. signature.asc Description: PGP signature
Re: [dev] getting rid of cmake builds
Hi, On Fri, Sep 22, 2023 at 07:27:25PM +0600, NRK wrote: > $ make > # ... builds st > $ make CFLAGS="-g3 -fsanitize=address,undefined" > # ... builds nothing because make doesn't take CFLAGS changes into > account. > > I've seen some (hacky) ways to dump the flags into a file to trigger > re-build more reliably. But as I've said, it's a solution to a self-made > problem. I don't think a build system should care about it. The build system should care only about building what is required with the set of flags that you pass in the command line. This is derivated from the UNIX principle "Mechanisms, not policy" [1]. What happens if I want to apply the set of flags to only one file? If you want to build everything with a different set of flags just clean and build. This is very well summarized in the quote "Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things" [2] > There is no shell script involved. You invoke the compiler directly with > whatever flags you please. There's no need to track dependencies or > flags. Did you see any flags in my example? If I want debug symbols then I just write `make CFLAGS=-g`. and it knows what is the compiler to be used. I don't want to know anything about compiler or set of options, I just want to execute make and get the binary. > And this is no longer the 50s, we have enough memory to build a couple > thousand line of code without *requiring* splitting things into multiple > intermediate object files to avoid going OOM (even with bloated > compilers like gcc/clang with optimization enabled). That is just another version of "it works for me". Don't assume anything about build hosts. If you don't like it you are free of using jave instead, I am pretty sure java programmers would like more this kind of things. > Incremental builds are not free. And for small projects, the complexities > they bring is (IMO) much higher compared to the benefits (which are > either non-existent or negligible for small projects). Do you think the Makefile that I wrote was complex? It was just a list of objects. Can you explain me where is the complexity? and also, can you explain me how you solve the problem of duplicated static symbols? Regards, [1] https://www.linuxtopia.org/online_books/programming_books/art_of_unix_programming/ch01s06_3.html? [2] https://quotefancy.com/quote/1711236/Douglas-Gwyn-Unix-was-not-designed-to-stop-you-from-doing-stupid-things-because-that
Re: [dev] getting rid of cmake builds
On Fri, Sep 22, 2023 at 12:33:15PM +0200, Roberto E. Vargas Caballero wrote: > In a Makefile (in a good well written) you only have to pass a > different CFLAGS value Either I haven't communicated properly, or people are not reading clearly. In either case, here's a practical example using a fresh ST repo: $ make # ... builds st $ make CFLAGS="-g3 -fsanitize=address,undefined" # ... builds nothing because make doesn't take CFLAGS changes into account. I've seen some (hacky) ways to dump the flags into a file to trigger re-build more reliably. But as I've said, it's a solution to a self-made problem. > but in the shell script There is no shell script involved. You invoke the compiler directly with whatever flags you please. There's no need to track dependencies or flags. And this is no longer the 50s, we have enough memory to build a couple thousand line of code without *requiring* splitting things into multiple intermediate object files to avoid going OOM (even with bloated compilers like gcc/clang with optimization enabled). Incremental builds are not free. And for small projects, the complexities they bring is (IMO) much higher compared to the benefits (which are either non-existent or negligible for small projects). > that is not about build systems, is about software design: This is true. But it is also true that when people have a hammer in hand, everything looks like a nail. When someone start off with an over-complicated build system, they tend to also end up over-engineering the software architecture as a result of the build system making it easy to over-complicate things. - NRK
Re: [dev] [dmenu][bug report] Second instance invisible
On Thu, Sep 21, 2023 at 02:02:12PM +0100, Christopher Lang wrote: > > I have experienced the following bug on both arch linux and void linux. > dmenu and dwm are both installed with config.h equal to config.def.h. > > I run the following shell command: > seq 2 | dmenu && seq 3 | dmenu > The first dmenu instance opens as expected. I hit the enter key and a 1 > is printed. However, the second dmenu instance does not appear. It > remains invisible, but still accepts my keyboard input, behaving as if > it were visible. I hit enter again, what I typed is printed and the > shell command terminates with exit code 0. > I too cannot reproduce this with the latest commit "7ab0cb5ef0e1", neither on OpenBSD nor on void linux. It would be useful to know which patches you've applied and what the contents of your config.h actually are. Have you already tried to use the current master with default settings? -- Best Regards, Tom Schwindl
Re: [dev] getting rid of cmake builds
Hi, On Fri, Sep 22, 2023 at 04:06:25PM +0600, NRK wrote: > On Fri, Sep 22, 2023 at 11:18:47AM +0200, Страхиња Радић wrote: > > ./build.sh > > But in short: you simply include any `.c` file into one. There's zero and then you get name collisions because all the static symbols are compiled in a single translation unit. > problem adapting to a different compiler or compiler flags. In fact, > it's *easier* to do than a makefile (which I also said on my previous easier than in a Makefile? In a Makefile (in a good well written) you only have to pass a different CFLAGS value, but in the shell script you have to edit the shell script itself. > $ gcc -o exe src.c > $ clang -o exe src.c # no need to "clean" anything > > Doing cross-platform is also easy by just making your core application > "platform-agonistic" and having the "platform layer" provide platform > specific functionality. For example, here's a hypothetical > `app-windows.c` file: that is not about build systems, is about software design: OBJS = main.o src-$(SYS).o SYS = posix app: $(OBJS) $(CC) -o $@ $(LDFLAGS) $(OBJS) if you compile in posix, then you only use `make`, if you compile in windows you use `make SYS=windows`. Makefiles are really simple, but for some reason that I don't understand people like to write horrible and complex Makefiles. Regards,
Re: [dev] getting rid of cmake builds
On Fri, Sep 22, 2023 at 11:18:47AM +0200, Страхиња Радић wrote: > ./build.sh I did not advocate for `build.sh`. And the wikipedia article I linked explains how unity-builds works pretty well already: https://en.wikipedia.org/wiki/Unity_build But in short: you simply include any `.c` file into one. There's zero problem adapting to a different compiler or compiler flags. In fact, it's *easier* to do than a makefile (which I also said on my previous mail). $ gcc -o exe src.c $ clang -o exe src.c # no need to "clean" anything Doing cross-platform is also easy by just making your core application "platform-agonistic" and having the "platform layer" provide platform specific functionality. For example, here's a hypothetical `app-windows.c` file: #include "app.c" // platform-agonistic application // ... // now add windows specific functionalities and // an entry point (i.e main function) below. And the same for a "app-posix.c". And then you compile in a single command, for example: $ cc -o exe src-posix.c# on posix platforms $ cl src-windows.c [...] # on windows with msvc without requiring mingw or similar - NRK
Re: [dev] getting rid of cmake builds
On 23/09/22 03:09PM, NRK wrote: > Some tend to argue that this "doesn't scale", but as I said, this is for > small projects. And the chances of your small project turning into the > next linux kernel [2] with 30M LoC is probably not high. So don't create > new *actual problems* by trying to solve an imaginary one. The moment there is a new compilation unit, or several of them (but still way below "30M LoC" -- say, utils.c, screen.c and utf8.c), this quickly becomes tedious to type for every unit and a program. And then one puts those commands in ./build.sh. And then it occurs that one needs to adapt to a different compiler, different flags, different PREFIX and so on and ./build.sh gradually becomes less elegant than, say, a mkfile. signature.asc Description: PGP signature
Re: [dev] getting rid of cmake builds
On Fri, Sep 22, 2023 at 10:00:56AM +0200, Страхиња Радић wrote: > How does it decide when rebuilding is needed? Does it track dependencies and > how? IMO in small projects, these are problems that should be *avoided entirely* instead of creating them and then solving it. E.g you can have a simple unity build [0] that builds everything in a single translation-unit via a single compiler command: $ cc -o exe src.c This requires: - No build system whatsoever. - No dependency tracking. - No need to run `make clean` or similar when changing compiler flags (e.g adding Sanitizers, testing with more aggressive warnings or optimization flags etc). - Usually faster full builds (even compared to parallel make) due to not having to re-parse the same system headers again and again along with avoiding other fixed costs. - Nearly as fast as incremental builds or at least not noticeably slower that would hamper developer productivity (reminder: for small projects). - Better warnings due to compiler (and static analyzers) being able to look across TU boundaries. [1] - Simple build makes it easier to use other tools on the project such as static analyzers or fuzzers. Some tend to argue that this "doesn't scale", but as I said, this is for small projects. And the chances of your small project turning into the next linux kernel [2] with 30M LoC is probably not high. So don't create new *actual problems* by trying to solve an imaginary one. [0]: https://en.wikipedia.org/wiki/Unity_build [1]: you can add LTO to overcome this. But then your incremental builds will usually become _significantly slower_ because LTO (as of now at least) makes the linking process extremely slow. [2]: *even in* large projects, unity builds are still useful to speed up compilation. For example the infamous linux kernel "fast header" patches included reducing TUs by, "consolidating .c files": https://lore.kernel.org/lkml/ydifz+lmewets...@gmail.com/T/#u - NRK
Re: [dev] getting rid of cmake builds
On 23/09/22 10:26AM, Sagar Acharya wrote: > You can have inputs like > > ./build.dash rebuild > > which first cleans earlier compiled files and builds. All of the build systems I listed support cleaning and rebuilding as well. > Dependencies would go into logic of shell script, it can have > check_dependencies which checks for files. Normally as you code a shell > script! Of course, one could rewrite any build system, with varying degree of difficulty, in shell script if needed, but then one would a) still write build scripts (Makefiles, .do files...) in that build system, and b) that would be suboptimal. Shell script is not a general-purpose programming language. Just some of the drawbacks of using shell script is that it is a slow, insecure, interpreted language with limited expresiveness. Above all else, it was not designed to be a general-purpose programming language. P.S: https://git-send-email.io/top-posting.html signature.asc Description: PGP signature
Re: [dev] getting rid of cmake builds
You can have inputs like ./build.dash rebuild which first cleans earlier compiled files and builds. Dependencies would go into logic of shell script, it can have check_dependencies which checks for files. Normally as you code a shell script! Thanking you Sagar Acharya https://humaaraartha.in/selfdost/selfdost.html 22 Sept 2023, 13:31 by cont...@strahinja.org: > On 23/09/22 09:50AM, Sagar Acharya wrote: > >> A better way to build is to write a build.dash script >> > > Some elaboration is needed. > > In what way would this shell script be better than the make systems I listed? > How does it decide when rebuilding is needed? Does it track dependencies and > how? >
Re: [dev] [dmenu][bug report] Second instance invisible
On Thu, Sep 21, 2023 at 02:02:12PM +0100, Christopher Lang wrote: > I run the following shell command: > seq 2 | dmenu && seq 3 | dmenu > The first dmenu instance opens as expected. I hit the enter key and a 1 > is printed. However, the second dmenu instance does not appear. Cannot reproduce on my system, tried on unpatched master branch and v5.2. The 2nd dmenu instance appears just fine after the first one closes. If you can consistently reproduce, then attach gdb to the 2nd instance (via `gdb --pid`) and try to inspect what might be going wrong compared to a non-buggy case. - NRK
Re: [dev] getting rid of cmake builds
On 23/09/22 09:50AM, Sagar Acharya wrote: > A better way to build is to write a build.dash script Some elaboration is needed. In what way would this shell script be better than the make systems I listed? How does it decide when rebuilding is needed? Does it track dependencies and how? signature.asc Description: PGP signature
Re: [dev] getting rid of cmake builds
A better way to build is to write a build.dash script It would simply execute in shell. I use this method. It is extremely readable and manageable. Ofc, it cannot be used for other softwares where bloatware is used! Thanking you Sagar Acharya https://humaaraartha.in/selfdost/selfdost.html 22 Sept 2023, 10:17 by cont...@strahinja.org: > On 23/09/21 09:42AM, LM wrote: > >> I build a lot of common libraries and programs from source. Many of >> them are switching to cmake. I'm not a fan of cmake. For one thing, >> it's so complicated to build from source code that I can't bootstrap >> the build of cmake itself. I really would prefer to build as many of >> > > I agree. Anyone who tries to build a LFS system (or a derivation of it) will > inevitably come across the beast that is cmake. When creating build scripts > for > "roll my own" static musl distro, Galeb[1], I came to several conclusions: > > * cmake is a bloated mess (understatement), takes ages to build > * It being written in C++ is part of the reason for the above > * cmake can't properly figure out static library dependencies, in some > cases they still need to be configured manually > > When it comes to the choice of a build system, I know of a number of options > which are way better than cmake (in no particular order): > > - djb redo > - POSIX make > - Plan9 mk > > On topic, I'm afraid I haven't come across any automated converters, and as > others have stated, it probably isn't even possible. I think it would be > easier > to write build scripts for packages using cmake in a simpler build system > from > scratch. > > > [1]: https://strahinja.srht.site/galeb/ >
