[dev] Replace ranlib(1) calls?
Hi all, I've noticed that we use the non-standard ranlib(1) program to create symbol tables for archives created by ar(1). This affects, as far as I can tell, every creation of static libraries we have. ranlib(1) is, in fact, legacy. It was used to create symbol tables for archives before ar(1) was able to do that by itself. POSIX now specifies that ar(1) should create a symbol table by default, when there is at least one recognized object file[1]. Additionally, the `s` option exists which does exactly the same as ranlib(1)[2]. We could replace the ranlib(1) calls with: ar rcs files... which not only makes the creation of static libraries more portable, but also simpler. [1] https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/utilities/ar.html [2] https://sourceware.org/binutils/docs/binutils/ranlib.html -- Best Regards, Tom Schwindl
Re: [dev] Replace ranlib(1) calls?
Hi, On Fri, Jul 22, 2022 at 05:26:52PM +0200, Roberto E. Vargas Caballero wrote: > Hi, > > On Wed, Jul 20, 2022 at 12:23:01PM +0000, Tom Schwindl wrote: > > ranlib(1) is, in fact, legacy. It was used to create symbol tables for > > archives > > before ar(1) was able to do that by itself. > > POSIX now specifies that ar(1) should create a symbol table by default, when > > there is at least one recognized object file[1]. Additionally, the `s` > > option exists > > which does exactly the same as ranlib(1)[2]. > > Well, I disagree about ranlib to be obsolete. Ar is guaranteed to add an > index in COFF and ELF systems, but not in a.out. I also know that 99.99% > of the people will ignore such systems, but I personally care about them. > Also, using ranlib doesn't harm so I personally don't see the advantage > of removing it. The main "problem" here is that ranlib(1) isn't a standardized tool, so there is no guarantee on what its behaviour will be or whether it exists at all. We assume it's there because it always has been or GNU and LLVM include it. Relying on a utility which isn't defined by the specification we're using doesn't make much sense to me. Especially if there *is* a *defined* flag which does exactly the same thing as ranlib(1). Bothering with systems which do not comply with "our" standards (by which I mean POSIX) isn't worth it, unless there are concrete plans and good reasons to support them (at least in my opinion). > > > ar rcs files... > > > > which not only makes the creation of static libraries more portable, > > but also simpler. > > More portable? It is just the opposite, if you use ranlib you can support > systems where ar doesn't create an index in the archive (for example if > you use scc ar :P). > Again, you'd have to rely on a tool which isn't defined. If a system says it's POSIX compliant, we can assume that the `-s' option exists, but there is no standard which tells us whether ranlib(1) is available or not. We'd have to introduce exceptions and thus increase the complexity to support edge cases because *they* do not comply to standards. -- Best Regards, Tom Schwindl
Re: [dev][dvtm] Hidden state bug (repost from hack...@suckless.org)
Hi, On Wed Aug 31, 2022 at 9:50 PM CEST, wrote: > Hey. When I launch dvtm via something like "DVTM_TERM=st dvtm", dvtm seems > to open, but then - the 1st tab is hidden. If I do MOD+s, it becomes > unhidden, and everything seems to be like it should be. Now, this is only > for the 1st tab, and this isn't a problem if in the previous command I do > "dvtm_status" instead of "dvtm".. A bit puzzled. While at it - does anyone Setting "BAR_AUTOHIDE" in your `config.h' to "false" should do the trick. -- Best Regards, Tom Schwindl
Re: [dev] dwm 6.4 bug
Hi, On Tue Oct 25, 2022 at 5:03 PM CEST, spaceman wrote: > Hi, > > While compiling dwm on slackware 15 I get the following (with > _FORTIFY_SOURCE=3): And therein lies the catch. The call to strncpy(3) copies the symbol of the currently selected layout to the layout symbol (ltsymbol) which will later be printed to the bar. The maximum length of this symbol is 16 chars and normally this isn't an issue since those symbols do not consist of large strings. But in case someone decides to create a longer symbol text, this would overflow. Given that we compile with -Wall, the compiler would probably emit a warning and the user should notice his mistake. However, a length check & truncation of the last char doesn't seem harmful at all. Thoughts? > In file included from /usr/include/string.h:519, > from dwm.c:29: > In function 'strncpy', > inlined from 'arrangemon' at dwm.c:400:2, > inlined from 'arrange' at dwm.c:394:3, > inlined from 'arrange' at dwm.c:384:1: > /usr/include/bits/string_fortified.h:95:10: warning: '__builtin_strncpy' > specified bound 16 equals destination size [-Wstringop-truncation] >95 | return __builtin___strncpy_chk (__dest, __src, __len, > | ^~ >96 | __glibc_objsize (__dest)); > | ~ > In function 'strncpy', > inlined from 'arrangemon' at dwm.c:400:2, > inlined from 'arrange' at dwm.c:391:3: > /usr/include/bits/string_fortified.h:95:10: warning: '__builtin_strncpy' > specified bound 16 equals destination size [-Wstringop-truncation] >95 | return __builtin___strncpy_chk (__dest, __src, __len, > | ^~ >96 | __glibc_objsize (__dest)); > | ~ > In function 'strncpy', > inlined from 'setlayout' at dwm.c:1508:2: > /usr/include/bits/string_fortified.h:95:10: warning: '__builtin_strncpy' > specified bound 16 equals destination size [-Wstringop-truncation] >95 | return __builtin___strncpy_chk (__dest, __src, __len, > | ^~ >96 | __glibc_objsize (__dest)); > > This was enough to stop me updating from 6.3. > The last time I could find a modified strncpy in the logs in one of those places is somewhere around 2009. This isn't something introduced lately and should also occur when building older versions of dwm. -- Best Regards, Tom Schwindl
Re: [dev] dwm 6.4 bug
> I had bought up this issue in the past and the conclusion was that there > should just be a comment added [0] as users are treated as programmers. > > [0]: https://lists.suckless.org/hackers/2208/18484.html > So be it! :-) A user report is a good reason for adding the comment. -- Best Regards, Tom Schwindl
Re: [dev] About DWM Swapfocus patch
Hi Andre,
On Wed Nov 2, 2022 at 4:56 PM CET, Dr. André Desgualdo Pereira wrote:
> The swapfocus patch works as intended when we have changed the focus on the
> same tag. But when coming from another tag, the swapfocus does nothing.
>
> Example: suppose the focus is on a window at tag 2, then I manyally focus
> another window on another tag (say 3). Now if I try to swapfocus (Mod+S) the
> focus doesn't change back to the previous window.
>
> Any ideas on how to enable the swapfocus even if the previously focused
> window is in another tag?
>
To make sure I understand you correctly, does the following example apply to
your situation? (I use dwm-6.4 and default keybindings here)
tag 1: st
tag 2: browser
You currently are on tag 1 and switch to tag 2 (Mod+2), now your browser is
focused. Then you press Mod+s and expect st to somehow show up and obtain
the focus, right?
This is a bit ambiguous, since there are multiple ways this could happen:
- move st to tag 2
- view tag 1 alongside with tag 2 (equivalent to Mod+ctrl+1)
- switch to tag 1 (equivalent to Mod+1)
I think the last one is the most useful solution, so I inlined the updated
patch to match this behaviour. Let me know if that's what you meant.
--
Best Regards,
Tom Schwindl
diff --git a/dwm.c b/dwm.c
index 253aba7b6f7d..c5dd6db5c84c 100644
--- a/dwm.c
+++ b/dwm.c
@@ -207,6 +207,7 @@ static void seturgent(Client *c, int urg);
static void showhide(Client *c);
static void sigchld(int unused);
static void spawn(const Arg *arg);
+static void swapfocus(const Arg *arg);
static void tag(const Arg *arg);
static void tagmon(const Arg *arg);
static void tile(Monitor *m);
@@ -236,6 +237,7 @@ static int xerrorstart(Display *dpy, XErrorEvent *ee);
static void zoom(const Arg *arg);
/* variables */
+static Client *prevclient;
static const char broken[] = "broken";
static char stext[256];
static int screen;
@@ -1650,6 +1652,22 @@ spawn(const Arg *arg)
}
}
+void
+swapfocus(const Arg *arg)
+{
+ Client *c;
+ Arg tmp;
+
+ for (c = selmon->clients; c && c != prevclient; c = c->next)
+ ;
+ if (c == prevclient) {
+ tmp.ui = (prevclient->tags & TAGMASK);
+ view(&tmp);
+ focus(prevclient);
+ restack(prevclient->mon);
+ }
+}
+
void
tag(const Arg *arg)
{
@@ -1751,6 +1769,7 @@ unfocus(Client *c, int setfocus)
{
if (!c)
return;
+ prevclient = c;
grabbuttons(c, 0);
XSetWindowBorder(dpy, c->win, scheme[SchemeNorm][ColBorder].pixel);
if (setfocus) {
@@ -2116,10 +2135,11 @@ void
zoom(const Arg *arg)
{
Client *c = selmon->sel;
+ prevclient = nexttiled(selmon->clients);
if (!selmon->lt[selmon->sellt]->arrange || !c || c->isfloating)
return;
- if (c == nexttiled(selmon->clients) && !(c = nexttiled(c->next)))
+ if (c == nexttiled(selmon->clients) && !(c = prevclient =
nexttiled(c->next)))
return;
pop(c);
}
Re: [dev] [dwm] Obtain focused monitor
Hi,
On Sun Jan 8, 2023 at 11:40 AM CET, A Farzat wrote:
> On 23/01/08 11:32am, Hiltjo Posthuma wrote:
> > On Sun, Jan 08, 2023 at 07:19:10PM +0900, A Farzat wrote:
> > > Is there a way to obtain the currently focused monitor in dwm? I want to
> > > use it in my script to control which monitor gets its brightness
> > > modified.
> > >
> > > Regards,
> > > Farzat
> >
> > selmon
> >
> > --
> > Kind regards,
> > Hiltjo
> >
>
> And how do I access that command? If possible I want to access it from
> a shell script.
>
> I am open to modifying the dwm source code if necessary.
>
> Regards,
> Farzat
selmon isn't a command. It's a variable in the source code located at
dwm.c:269 (upstream). You could write a function like the following to dump
its value to stdout/stderr. Now you have to figure out where to call it.
--
Best Regards,
Tom Schwindl
diff --git a/dwm.c b/dwm.c
index 03baf42b3502..4fa8253c91e0 100644
--- a/dwm.c
+++ b/dwm.c
@@ -234,6 +234,7 @@ static int xerror(Display *dpy, XErrorEvent *ee);
static int xerrordummy(Display *dpy, XErrorEvent *ee);
static int xerrorstart(Display *dpy, XErrorEvent *ee);
static void zoom(const Arg *arg);
+static void dumpmon(void);
/* variables */
static const char broken[] = "broken";
@@ -276,6 +277,13 @@ static Window root, wmcheckwin;
struct NumTags { char limitexceeded[LENGTH(tags) > 31 ? -1 : 1]; };
/* function implementations */
+static void
+dumpmon(void)
+{
+ if (selmon)
+ fprintf(stdout, "%d\n", selmon->num);
+}
+
void
applyrules(Client *c)
{
[dev] bump copyright years?
Hi all, I've recently (well, a few days/weeks ago) read quite a few discussions on a wide variety of mailing lists about whether to remove the range of years from the copyright notices or keep them. Since a few of our LICENSE files are out of date too, I wonder if there is a consensus on what to do. Should we update them and do the usual "bump the year" dance? Or should we completely drop them and stop worrying. I do not have strong opinions on this, but I think if the years are stated, they should at least be correct. I like to link to the musl discussion here since they go into more depth on the topic. Unfortunately, I think they didn't come to a conclusion: <https://www.openwall.com/lists/musl/2023/01/09/4> The reason why I bring this up is that I think it's irritating, or at least inconsistent, if a project is actively developed but the LICENSE file states something like "(c) 2010-2015". -- Best Regards, Tom Schwindl
Re: [dev] bump copyright years?
Hi Laslo, On Wed Feb 8, 2023 at 5:48 PM CET, Laslo Hunhold wrote: > On Wed, 08 Feb 2023 10:17:47 + > "Tom Schwindl" wrote: > > Dear Tom, > > > I've recently (well, a few days/weeks ago) read quite a few > > discussions on a wide variety of mailing lists about whether to > > remove the range of years from the copyright notices or keep them. > > Since a few of our LICENSE files are out of date too, I wonder if > > there is a consensus on what to do. Should we update them and do the > > usual "bump the year" dance? Or should we completely drop them and > > stop worrying. I do not have strong opinions on this, but I think if > > the years are stated, they should at least be correct. > > > > I like to link to the musl discussion here since they go into more > > depth on the topic. Unfortunately, I think they didn't come to a > > conclusion: > > > > <https://www.openwall.com/lists/musl/2023/01/09/4> > > > > The reason why I bring this up is that I think it's irritating, or at > > least inconsistent, if a project is actively developed but the > > LICENSE file states something like "(c) 2010-2015". > > I also followed the hype regarding this topic, but found that it was > mostly fluff. Sure you can leave out the years, but then you're leaving > out information. > > I find the copyright years to be very helpful: They are meant to be > updated when there has been a _change_ in that timeframe as well. It's > not like you have to bump it everywhere. Looking at the license thus > gives you a short insight in who worked at the project in which > timeframe. A good example is, for instance, the dwm license file[0]. > I like your reasoning and certainly agree with it. Thanks! As I'm reading the other replies, I did not mean to start some sort of revolution against copyright years. I was simply interested in opinions since I haven't seen the topic come up here before. I seem to always start bikeshedding discussions :-) -- Best Regards, Tom Schwindl > With best regards > > Laslo > > PS: One thing you can _really_ leave out or replace with "Copyright" is > the copyright symbol "(C)" or "©". It suffices to say "Copyright 2023 > John Doe". > > [0]:https://git.suckless.org/dwm/file/LICENSE.html
Re: [dev] Using ii to connect to libera
Hi Sagar, > I'm using > > ii -s irc.libera.chat -n foobar/j #kicad > > doesn't do anything. > I'm not aware that passing commands on the command line in this fashion is possible. Additionally, what does "doesn't do anything" mean? Do you get output after entering the command or does it look like it hung up? You're aware that ii is a FIFO-based IRC client and does not provide an interactive way of entering messages and commands by itself? You *have* to either use the FIFO directly (via echo(1) and the usual suspects) or a frontend which handles the I/O for you. lchat[0] might be interesting for you. I'm sure you already know that, but I want to be certain. [0] https://tools.suckless.org/lchat -- Best Regards, Tom Schwindl
Re: [dev] Simpler WiFi alternatives
Hi Sagar, On Wed May 10, 2023 at 8:38 PM CEST, Sagar Acharya wrote: > I think routers ought to be way simpler than they currently are. I wonder if > y'all can recommend me some minimal C code which can be used as a router. > > I think that if the analog pins of arduino are connected to an antenna, and a > C code similar to, > > while 1 > If (switch_1==1) create_connection_with_handshake() > else if (switch_1==0) send_packet_to_isp() > receive_packet_from_isp() > > Something like that. Are there some existent projects like that? I really > don't think a router requires LibreCMC or OpenWRT like gigantic OSes. > > > Thanking you > Sagar Acharya > http://humaaraartha.in <https://humaaraartha.in> It's pretty clear that you don't know enough about the internet, its protocols and how communication and addressing works. It's a complex mess and what you're trying to do won't work. You should acquire basic knowledge in order to ask more precise questions or, more importantly, answer them yourself. Start to inform yourself about networking and the inner workings of networking devices instead of spamming this list with the same stuff over and over again. As someone prior to me said, you act like you're on reddit. -- Best Regards, Tom Schwindl
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
