[hackers] [slstatus] uptime: Port to OpenBSD. || Aaron Marcher
commit fc5d23212fdaec8c242db9b25770f290dd287212
Author: Aaron Marcher
AuthorDate: Tue Mar 20 00:48:10 2018 +0100
Commit: Aaron Marcher
CommitDate: Tue Mar 20 00:52:09 2018 +0100
uptime: Port to OpenBSD.
In OpenBSD uptime gets fetched using sysctl now.
diff --git a/README b/README
index ddd295b..0eac61a 100644
--- a/README
+++ b/README
@@ -62,7 +62,6 @@ Todo
Porting to OpenBSD is the current goal before thinking about a release.
The following functions are not portable at the moment:
-- uptime
- ipv{4,6}
- ram_{free,perc,total,used}
- wifi_{perc,essid}
diff --git a/components/uptime.c b/components/uptime.c
index 36f03b1..c5e28ee 100644
--- a/components/uptime.c
+++ b/components/uptime.c
@@ -1,20 +1,45 @@
/* See LICENSE file for copyright and license details. */
+#include
#ifdef __linux__
#include
+#elif __OpenBSD__
+#include
+#include
+#endif
#include "../util.h"
const char *
uptime(void)
{
+ int h;
+ int m;
+ int uptime = 0;
+#ifdef __linux__
struct sysinfo info;
- int h = 0;
- int m = 0;
sysinfo(&info);
- h = info.uptime / 3600;
- m = (info.uptime - h * 3600 ) / 60;
+ uptime = info.uptime;
+#elif __OpenBSD__
+ int mib[2];
+ size_t size;
+ time_t now;
+ struct timeval boottime;
+
+ time(&now);
+
+ mib[0] = CTL_KERN;
+ mib[1] = KERN_BOOTTIME;
+
+ size = sizeof(boottime);
+
+ if (sysctl(mib, 2, &boottime, &size, NULL, 0) != -1)
+ uptime = now - boottime.tv_sec;
+ else
+ return NULL;
+#endif
+ h = uptime / 3600;
+ m = (uptime - h * 3600) / 60;
return bprintf("%dh %dm", h, m);
}
-#endif
Re: [hackers] [slstatus] battery_perc: Port to OpenBSD. || Aaron Marcher
Hello, If you're going to do this for every module for every OS you're planning on supporting, this is a bad start imho. Well, i will only support Linux and OpenBSD - and almost half of the modules is POSIX-compliant anyway. What would you think about rather separating objects to their OS directory and chose which to build/link at make time? Will adding an additional separation layer or even directory structure with duplicate code actually improve the readbility of the program? Performance-wise it is the same. Regards, Aaron -- Web: https://drkhsh.at/ or http://drkhsh5rv6pnahas.onion/ Gopher: gopher://drkhsh.at or gopher://drkhsh5rv6pnahas.onion GPG: 0x7A65E38D55BE96FE Fingerprint: 4688 907C 8720 3318 0D9F AFDE 7A65 E38D 55BE 96FE
Re: [hackers] [[st][PATCH]] Move term_mode to st.h
On Fri, Mar 16, 2018 at 11:23:08PM +0800, Ivan Tham wrote:
> This allows MODE_ALTSCREEN to be applied to scrollback patch in x.c
> ---
> st.c | 11 ---
> st.h | 11 +++
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/st.c b/st.c
> index 65a0cb6..1eafc0e 100644
> --- a/st.c
> +++ b/st.c
> @@ -47,17 +47,6 @@
> /* constants */
> #define ISO14755CMD "dmenu -w \"$WINDOWID\" -p codepoint:
>
> -enum term_mode {
> - MODE_WRAP= 1 << 0,
> - MODE_INSERT = 1 << 1,
> - MODE_ALTSCREEN = 1 << 2,
> - MODE_CRLF= 1 << 3,
> - MODE_ECHO= 1 << 4,
> - MODE_PRINT = 1 << 5,
> - MODE_UTF8= 1 << 6,
> - MODE_SIXEL = 1 << 7,
> -};
> -
> enum cursor_movement {
> CURSOR_SAVE,
> CURSOR_LOAD
> diff --git a/st.h b/st.h
> index dac64d8..624f72f 100644
> --- a/st.h
> +++ b/st.h
> @@ -52,6 +52,17 @@ enum selection_snap {
> SNAP_LINE = 2
> };
>
> +enum term_mode {
> + MODE_WRAP= 1 << 0,
> + MODE_INSERT = 1 << 1,
> + MODE_ALTSCREEN = 1 << 2,
> + MODE_CRLF= 1 << 3,
> + MODE_ECHO= 1 << 4,
> + MODE_PRINT = 1 << 5,
> + MODE_UTF8= 1 << 6,
> + MODE_SIXEL = 1 << 7,
> +};
> +
> typedef unsigned char uchar;
> typedef unsigned int uint;
> typedef unsigned long ulong;
> --
> 2.16.2
>
>
This won't work - the Term instance is now internal to st.c, and IS_SET
in x.c refers to win.mode (on the TermWindow instance) which doesn't
contain MODE_ALTSCREEN.
How about checking it in kscrollup/kscrolldown, over on the st.c side of
things? (To be honest, the ^E/^Y behavior already seems like kind of a
compatibility hack for programs that lack actual mouse reporting.)
*dp
--
<><
Re: [hackers] [slstatus] battery_perc: Port to OpenBSD. || Aaron Marcher
Hello Aaron, > battery_perc: Port to OpenBSD. > +#elif __OpenBSD__ > +#ifdef __linux__ > +#elif __OpenBSD__ > +#endif > +#ifdef __linux__ If you're going to do this for every module for every OS you're planning on supporting, this is a bad start imho. What would you think about rather separating objects to their OS directory and chose which to build/link at make time?
[hackers] [slcon5] Invitation to the suckless conference 2018
Dear fellow hackers! we are pleased to announce the suckless conference on 2018-07-(06-09) in Würzburg, Bavaria, Germany. Based on the very good experience we had last year, we will spend the time together working and reflecting on projects and are open for talk proposals, even though this will not be the main focus of this event. The accomodation fee will be 150€ or less and includes everything (a bed, towels, all meals, snacks, planned events) as a shared accomodation. The only thing you need to schedule in beyond that are your travel costs and costs in case we go to the pub or a restaurant. If you wish to set up your own accomodation the accomodation fee will be 50€ or less. In order to be able to arrange the conference properly, we kindly ask all of you who want to attend the event to register until 2018-06-01 by sending a mail to cha...@suckless.org with your name and clear message that you will definitely attend. Places are limited and secured on a first mail basis. We will inform all successful registrants within 2 weeks after receiving their mail. We also believe that it would be a good idea to arrange your travel already, if you plan to attend. We recommend arrival on 2018-07-06 and departure on 2018-07-(08-09). The closest international airport is Frankfurt/Main, Germany. Würzburg is a 90 minute trip from Frankfurt airport and well-accessible by train. Members of the suckless.org e.V. are invited to attend our annual Mitgliederversammlung (members meeting) on 2018-07-06 night in Würzburg (the exact location will be communicated around early June and we intend to meet in some Hinterzimmer of a nice Bavarian Wirtshaus like last year). We are looking forward to your registration requests! With best regards Laslo Hunhold -- Laslo Hunhold
[hackers] [slstatus] battery_perc: Port to OpenBSD. || Aaron Marcher
commit 7e3f80c1a39e16973f3c9235d3f9d85df0d1b995
Author: Aaron Marcher
AuthorDate: Mon Mar 19 18:44:52 2018 +0100
Commit: Aaron Marcher
CommitDate: Mon Mar 19 18:46:52 2018 +0100
battery_perc: Port to OpenBSD.
In OpenBSD battery percentage gets fetched using apm now.
diff --git a/README b/README
index f14a3b8..ddd295b 100644
--- a/README
+++ b/README
@@ -69,6 +69,6 @@ The following functions are not portable at the moment:
- cpu_{freq,perc,iowait}
- entropy
- swap_{free,perc,total,used}
-- battery_{perc,power,state}
+- battery_{power,state}
- temp
- vol_perc
diff --git a/components/battery.c b/components/battery.c
index 52ad343..4314e81 100644
--- a/components/battery.c
+++ b/components/battery.c
@@ -1,22 +1,50 @@
/* See LICENSE file for copyright and license details. */
+#include
+#include
#ifdef __linux__
#include
-#include
#include
+#elif __OpenBSD__
+#include
+#include
+#include
+#include
+#endif
#include "../util.h"
const char *
battery_perc(const char *bat)
{
+#ifdef __linux__
int perc;
char path[PATH_MAX];
snprintf(path, sizeof(path), "%s%s%s", "/sys/class/power_supply/", bat,
"/capacity");
return (pscanf(path, "%i", &perc) == 1) ?
bprintf("%d", perc) : NULL;
+#elif __OpenBSD__
+ struct apm_power_info apm_info;
+ int fd;
+
+ fd = open("/dev/apm", O_RDONLY);
+ if (fd < 0) {
+ warn("Failed to open file /dev/apm");
+ return NULL;
+ }
+
+ if (ioctl(fd, APM_IOC_GETPOWER, &apm_info) < 0) {
+ warn("Failed to get battery info");
+ close(fd);
+ return NULL;
+ }
+ close(fd);
+
+ return bprintf("%d", apm_info.battery_life);
+#endif
}
+#ifdef __linux__
const char *
battery_power(const char *bat)
{
Re: [hackers] [sinit] Ensure children are reaped periodically || sin
On Sun, Mar 18, 2018 at 01:09:08PM -0700, Michael Forney wrote:
> On 2018-03-18, g...@suckless.org wrote:
> > commit 170d599d58efee6c9be675a85c6e435d68e8a2de
> > Author: sin
> > AuthorDate: Sun Mar 18 13:35:38 2018 +
> > Commit: sin
> > CommitDate: Sun Mar 18 13:43:25 2018 +
> >
> > Ensure children are reaped periodically
> >
> > There is a pathological case where a parent receives SIGCHLD after its
> > child dies but does not reap it. After the parent dies, the child is
> > reparented to init but SIGCHLD is not redelivered.
> >
> > To fix this, periodically check if there are zombies pending to be
> > reaped.
>
> I'm assuming this patch is a response to the bug liwakura reported on
> #musl? I also did some investigation of this, and wasn't able to
> reproduce the issue on linux.
i knew about this bug for a while and discussed with emg about possible
solutions a year ago or so. somebody reminded me of this again because
of the discussion on #musl.
> Were you able to trigger this case somehow (maybe on another OS)?
no i didn't test the patch but the issue is real.
> > diff --git a/sinit.c b/sinit.c
> > index 93f9925..7166710 100644
> > --- a/sinit.c
> > +++ b/sinit.c
> > @@ -7,7 +7,8 @@
> > #include
> > #include
> >
> > -#define LEN(x) (sizeof (x) / sizeof *(x))
> > +#define LEN(x) (sizeof (x) / sizeof *(x))
> > +#define TIMEO 30
> >
> > static void sigpoweroff(void);
> > static void sigreap(void);
> > @@ -20,6 +21,7 @@ static struct {
> > } sigmap[] = {
> > { SIGUSR1, sigpoweroff },
> > { SIGCHLD, sigreap },
> > + { SIGALRM, sigreap },
> > { SIGINT, sigreboot },
> > };
> >
> > @@ -40,6 +42,7 @@ main(void)
> > sigprocmask(SIG_BLOCK, &set, NULL);
> > spawn(rcinitcmd);
> > while (1) {
> > + alarm(TIMEO);
>
> I wonder if there is another way to do this without a timeout. Perhaps
> a dedicated reaper thread?
>
> > sigwait(&set, &sig);
> > for (i = 0; i < LEN(sigmap); i++) {
> > if (sigmap[i].sig == sig) {
> > @@ -63,6 +66,7 @@ sigreap(void)
> > {
> > while (waitpid(-1, NULL, WNOHANG) > 0)
> > ;
> > + alarm(TIMEO);
> > }
> >
> > static void
> >
> >
>
Re: [hackers] [sinit] Ensure children are reaped periodically || sin
On Sun, Mar 18, 2018 at 02:59:50PM -0700, Michael Forney wrote: > On 2018-03-18, Laslo Hunhold wrote: > > On Sun, 18 Mar 2018 13:09:08 -0700 > > Michael Forney wrote: > >> I wonder if there is another way to do this without a timeout. Perhaps > >> a dedicated reaper thread? > > > > I suggested this too, but rightfully, this would require linking sinit > > with libpthread which would be an unacceptable overhead. > > A static binary linked against musl using a reaper thread instead of > alarm grows from 13600 bytes to 13616 bytes, so "unacceptable > overhead" seems like a bit of an exaggeration. musl isn't the only relevant libc though.
Re: [hackers] [sent] [PATCH] Add toggle fullscreen shortcut: f
> > Don't you think it's worth it? > > I don't think so, but at the end of the day, Markus will make the > decision and that's what matters. The maintainer decides what to merge > and what not. Same as Lalso on this.
Re: [hackers] [sent] [PATCH] Add toggle fullscreen shortcut: f
On Mon, 19 Mar 2018 09:20:35 -0300 Héctor Monacci wrote: Hey Héctor, > No, of course it is not our fault... Nevertheless, I think even users > of dwm would find it easier to just touch the f key and have > fullscreen toggle on and off. > > Look, my desktop/wm is XFCE, and by pressing Alt-F11 I get fullscreen > on and off everywhere. But mnemonics and lazyness push me once and > again to try the f key. It's just simpler, it's just less effort. > > The code overhead for adding this to "sent", both in source and in the > executable, is absolutely minimal. > > I still think this change would make "sent" a bit better. surely it's a matter of taste. I elaborated how I think about it, but would of course understand the decision to add it. Obviously it has its uses, but when writing software it's important to prevent feature-creep. > Don't you think it's worth it? I don't think so, but at the end of the day, Markus will make the decision and that's what matters. The maintainer decides what to merge and what not. With best regards Laslo Hunhold -- Laslo Hunhold
Re: [hackers] [sent] [PATCH] Add toggle fullscreen shortcut: f
On Mon, Mar 19, 2018 at 09:20:35AM -0300, Héctor Monacci wrote: > 2018-03-18 17:47 GMT-03:00 Laslo Hunhold : > > Hey Héctor, > > > >> Hi people, this is my first one, so please be patient if I > >> inadvertently break rules. > >> > >> After talking to Markus Teich, I added a fullscreen toggle function to > >> sent. It uses the f key for toggling. > > > > it looks good, but I don't really like the idea of putting things into > > a program which are actually the window manager's job. > > Is it really our fault that the popular window managers do not support > > fullscreening an arbitrary window? > > Hi Laslo! > > No, of course it is not our fault... Nevertheless, I think even users > of dwm would find it easier to just touch the f key and have > fullscreen toggle on and off. > > Look, my desktop/wm is XFCE, and by pressing Alt-F11 I get fullscreen > on and off everywhere. But mnemonics and lazyness push me once and > again to try the f key. It's just simpler, it's just less effort. > > The code overhead for adding this to "sent", both in source and in the > executable, is absolutely minimal. > > I still think this change would make "sent" a bit better. > > Don't you think it's worth it? Sounds good to me.
Re: [hackers] [sent] [PATCH] Add toggle fullscreen shortcut: f
2018-03-18 17:47 GMT-03:00 Laslo Hunhold : > Hey Héctor, > >> Hi people, this is my first one, so please be patient if I >> inadvertently break rules. >> >> After talking to Markus Teich, I added a fullscreen toggle function to >> sent. It uses the f key for toggling. > > it looks good, but I don't really like the idea of putting things into > a program which are actually the window manager's job. > Is it really our fault that the popular window managers do not support > fullscreening an arbitrary window? Hi Laslo! No, of course it is not our fault... Nevertheless, I think even users of dwm would find it easier to just touch the f key and have fullscreen toggle on and off. Look, my desktop/wm is XFCE, and by pressing Alt-F11 I get fullscreen on and off everywhere. But mnemonics and lazyness push me once and again to try the f key. It's just simpler, it's just less effort. The code overhead for adding this to "sent", both in source and in the executable, is absolutely minimal. I still think this change would make "sent" a bit better. Don't you think it's worth it? Héctor
