Re: [dev] [sbase] [patch v4] Add df(1)
On Fri, Jul 26, 2013 at 10:54:43PM +0300, sin wrote: > On Fri, Jul 26, 2013 at 12:14:08PM +0100, Nick wrote: > > On Fri, Jul 26, 2013 at 01:51:01PM +0300, sin wrote: > > > Incorporated Steve's changes as well to make it compile/work > > > on OpenBSD. I realize #ifdef's are terrible but for now it should > > > do the trick until we come up with a proper solution to this. > > > > Is there really no sensible way to get the required information for > > most POSIXish systems? How does coreutils do it (I expect tons of > > way more awful ifdefs than you've done here, but it's worth > > checking)? > > No idea, I have not looked at the coreutils code. Will check it out. > I just did. At least in the current version in Debian Squeeze it contains a whole lot of algorithms for different system interfaces, including listmntent(), getmntent() (for Linux, 4.3BSD, SunOS, HP-UX, Dynix and Irix), getmntinfo() (in two different versions, one for 4.4BSD, one for NetBSD 3.0), getmnt() (for Ultrix) and next_dev()/fs_stat_dev() (for BeOS). All of these are checked for availability, then executed and abstracted into GNU's own datastructures. Which, in this case, is a linked list. Apparently this stuff can't be done portably. > > I wonder what the right approach for utilities that can't be made > > portable should be? Are there any others that are likely to have > > these problems? > > If the build system can switch between between say Linux ops and > OpenBSD ops then we could have something like os/openbsd.c and > os/linux.c (for things that are not portable between them). > > Then the df.c code can just call a function that will be implemented > by both OSes (with the same signature etc.). > That would be a good choice, but I see problems on the horizon. Like, what happens if stuff is actually portable between Linux and OpenBSD, but some third option, say, Solaris, behaves differently? File descriptor readiness notification comes to mind. Not that I think we'd ever need that. What if some stuff is portable between operating systems, but unportable between architectures? What if the combination of both matters? Will we have a sysdeps tree like glibc? > The number of tools that might require this glue code is less than > 2% of the overall number of tools. So maybe leaving the #ifdef's for now > is enough until we encounter other situations as well? > I think that would be preferable. Unless we get a leaning tower of hostnames at some point, I would go with ifdefs in those tools as well. > Thanks, > sin Ciao, Markus
Re: [dev] [sbase] [patch v4] Add df(1)
On Sat, Jul 27, 2013 at 11:59:02AM +0200, Markus Wichmann wrote: > On Fri, Jul 26, 2013 at 10:54:43PM +0300, sin wrote: > > On Fri, Jul 26, 2013 at 12:14:08PM +0100, Nick wrote: > > > On Fri, Jul 26, 2013 at 01:51:01PM +0300, sin wrote: > > > > Incorporated Steve's changes as well to make it compile/work > > > > on OpenBSD. I realize #ifdef's are terrible but for now it should > > > > do the trick until we come up with a proper solution to this. > > > > > > Is there really no sensible way to get the required information for > > > most POSIXish systems? How does coreutils do it (I expect tons of > > > way more awful ifdefs than you've done here, but it's worth > > > checking)? > > > > No idea, I have not looked at the coreutils code. Will check it out. > > > > I just did. At least in the current version in Debian Squeeze it > contains a whole lot of algorithms for different system interfaces, > including listmntent(), getmntent() (for Linux, 4.3BSD, SunOS, HP-UX, > Dynix and Irix), getmntinfo() (in two different versions, one for > 4.4BSD, one for NetBSD 3.0), getmnt() (for Ultrix) and > next_dev()/fs_stat_dev() (for BeOS). All of these are checked for > availability, then executed and abstracted into GNU's own > datastructures. Which, in this case, is a linked list. > > Apparently this stuff can't be done portably. We should probably make a decision on how portable we want to be. > > > I wonder what the right approach for utilities that can't be made > > > portable should be? Are there any others that are likely to have > > > these problems? > > > > If the build system can switch between between say Linux ops and > > OpenBSD ops then we could have something like os/openbsd.c and > > os/linux.c (for things that are not portable between them). > > > > Then the df.c code can just call a function that will be implemented > > by both OSes (with the same signature etc.). > > > > That would be a good choice, but I see problems on the horizon. Like, > what happens if stuff is actually portable between Linux and OpenBSD, > but some third option, say, Solaris, behaves differently? File > descriptor readiness notification comes to mind. Not that I think we'd > ever need that. If not all three behave the same then we should still abstract it. > What if some stuff is portable between operating systems, but unportable > between architectures? What if the combination of both matters? Will we > have a sysdeps tree like glibc? I would not worry much about that at the moment. I can't think of anything. Although if that really matters then we extend the above solution to include something like an arch/ folder. > > The number of tools that might require this glue code is less than > > 2% of the overall number of tools. So maybe leaving the #ifdef's for now > > is enough until we encounter other situations as well? > > > > I think that would be preferable. Unless we get a leaning tower of > hostnames at some point, I would go with ifdefs in those tools as well. David, what do you think? Thanks, sin
Re: [dev] Issue with DWM and x-terminal-emulator launching
This isn't related to fonts per se. When I launch st using the mod-key shortcut the system will freeze when killing X. This doesn't happen with another terminal emulator or when launching st from dmenu. I haven't seen this reported elsewhere but one other person on the arch forum has the same problem.
Re: [dev] daemon for DWM
On Mon, Jul 22, 2013 at 3:17 PM, Markus Teich
wrote:
>
> rx_now=0
> tx_now=0
> for i in /sys/class/net/*; do
> if [[ -d "$i" && ${i##*/} != "lo" ]]; then
> if [[ -f "$i/statistics/rx_bytes" ]]; then
> rx_now=($rx_now+`cat $i/statistics/rx_bytes`)
> fi
> if [[ -f "$i/statistics/tx_bytes" ]]; then
> tx_now=($tx_now+`cat $i/statistics/tx_bytes`)
> fi
> fi
> done
> let rx_rate=($rx_now-$rx_old)
> let tx_rate=($tx_now-$tx_old)
>
Might I ask what shell dialect is that written in? O_o
cheers!
mar77i
Re: [dev] Issue with DWM and x-terminal-emulator launching
* James Latteier [27.07.2013 15:35]: > This isn't related to fonts per se. When I launch st using the mod-key > shortcut the system will freeze when killing X. This doesn't happen with > another terminal emulator or when launching st from dmenu. I haven't > seen this reported elsewhere but one other person on the arch forum > has the same problem. Make this a +1, this also happens on my system, Arch 64bit with vanilla dwm-git and vanilla st-git. pgpDvnJJKM4_5.pgp Description: PGP signature
[dev] [st] Binding Control+Tab
In my configuration for st, I have the following Key entry for
Control+Shift+Tab:
{ XK_ISO_Left_Tab, ShiftMask | ControlMask, "\033[27;6;9~", 0, 0, 0},
I would also like to use Control+Tab, so I added the following entry
above that:
{ XK_ISO_Left_Tab, ControlMask, "\033[27;5;9~", 0, 0, 0},
After recompiling st, pressing Control+Tab still does not emit the
desired key sequence, but Control+Shift+Tab works fine. How can I
configure st so that pressing Control+Tab emits "\033[27;5;9~"?
Eric
[dev] Wayland st!!??
I didn't know about this http://www.phoronix.com/scan.php?page=news_item&px=MTQyMTQ I'm both excited or looking to troll
[dev] Re: [st] Binding Control+Tab
On Sat, Jul 27, 2013 at 12:00:04PM -0500, Eric Pruitt wrote:
> In my configuration for st, I have the following Key entry for
> Control+Shift+Tab:
>
> { XK_ISO_Left_Tab, ShiftMask | ControlMask, "\033[27;6;9~", 0, 0, 0},
>
> I would also like to use Control+Tab, so I added the following entry
> above that:
>
> { XK_ISO_Left_Tab, ControlMask, "\033[27;5;9~", 0, 0, 0},
>
> After recompiling st, pressing Control+Tab still does not emit the
> desired key sequence, but Control+Shift+Tab works fine. How can I
> configure st so that pressing Control+Tab emits "\033[27;5;9~"?
After poking around some more, I learned that when using Control+Tab,
the KeySym value is XK_Tab instead of XK_ISO_Left_Tab although I am not
sure why using "Shift" changes that and "Control" does not. To use
Control+Tab, I changed what I originally had to:
{ XK_Tab, ControlMask, "\033[27;5;9~", 0, 0, 0},
Pressing Control+Tab now emits the sequence I want.
Eric
Re: [dev] Wayland st!!??
On Sat, 27 Jul 2013 14:17:42 -0400, Carlos Torres wrote: > I didn't know about this > > http://www.phoronix.com/scan.php?page=news_item&px=MTQyMTQ > > I'm both excited or looking to troll I'm the author of the port. I'm not sure how the suckless community feels about Wayland, but it seems like the core protocol is fairly lightweight, depends only on libffi, and is refreshing to work with compared to X. Weston's goals are perhaps more orthogonal to suckless, but I think there is potential for a suckless compositor. I don't really expect there to be a suckless Wayland environment for a while, and maybe something better will come around before there is, but I think my rendering library could be useful in either case (the Wayland part is just buffer creation/management and is separate from the rendering part). -- Michael Forney
