[dev] [slock] partial screen unmask after rotate and monitor video cable reconnect
Environment: Arch Linux, xorg-server, i3-wm, slock Steps to reproduce: 1) Rotate the display: $ xrandr --output HDMI1 --rotate left 2) Lock the screen: $ slock 3) Unplug your monitor video cable from your computer. 4) Plug your monitor video cable back into your computer. 5) The screen is still locked, but the right side of the screen (when horizontal, the "bottom" if rotated) is unmasked. The unmasked content appears to be live, as my clock was updating. The "mask" seems to become un-rotated when the monitor is being re-initialized. Rob
Re: [dev] [RFC] Design of a vim like text editor
On 24 Sep 2014, wrote: On Wed, Sep 24, 2014, at 15:36, Marc Andr=C3=A9 Tanner wrote: > > - 'J' in visual mode is not implemented > > Why would one use it? To be able to select lines to be joined interactively instead of having to count the lines by hand (since there's no J, only J). I do this all the time. You might find this useful - I think J makes more sense working as an operator, once you get used to it. " fix J to be an operator command func! Joinoperator(submode) norm $mj '[,']join norm 'jl endfunc nnoremap J :silent set operatorfunc=3DJoinoperatorg@ Cheers, Rob
Re: [dev] network protocol packing
On 30/06/14, Markus Teich wrote: Heyho, Hello there, since I did not find any suckless project regarding this issue, I would like to ask you guys for some feedback: unsigned char *msg; size_t msg_size; struct foo *msg_data; struct bar *msg_signature; msg_size = sizeof(unsigned char)// op + sizeof(struct foo)// data + sizeof(struct bar)// signature msg = malloc(msg_size); *msg = MSG_OP_SIGNED_DATA; msg_data = (struct foo *)(msg + 1); You've got alignment issues here - msg will be aligned to support any type (as malloc's interface specifies) so msg+1 will most likely be on an odd address, one byte off a highly aligned address. This means if your struct contains anything other than chars, you'll have UB. This is fine on x86, which allows unaligned access with a performance penalty but on something like an ARM machine you'll have issues. You probably want to memcpy the struct in from an existing one. msg_data->field0 = bla; msg_data->field1 = blub; msg_signature = (struct bar *)(msg_data + 1); create_signature(msg, msg_signature); sendmsg(msg); free(msg); I feel it is pretty good already compared to other message packing I've seen, but do you know a way to make it suck even less? Seems pretty straightforward otherwise :) Cheers, Rob
Re: [dev] [grep-notify] A simple notifier when stdout prints a pattern
On Sat, 28 Jun 2014, Amadeus Folego wrote: Hi Guys, for some days I've been looking for a suckless irc client. ... It's current status is very prototypical and it's by no measure near to something that I would like to share or tell others to use, I know it's working for simple things though. So, back to my original goal, I am still having some problems, output stops being printed after a certain threshold, ~ 20 lines, when using it with sic, I don't know yet why. If you guys have any idea or know of another program that could help me with this, it would be great! Hi Amadeus, As already mentioned, printing the bell character to the terminal should do the trick too - dwm will highlight the terminal's tag(s), for example. A couple of comments on the code - your arguments for notify() and line_match() are without types, which means they default to int, so you'll have issues where sizeof(int) != sizeof(char *), or where the integer representation of a pointer doesn't line up with a pointer representation. Also, code in main can't see these functions, since they're after main, so you'll need to move them above main, or forward declare them. gcc can help you here - compile with -Wall and -Wextra :) Perhaps see how using the bell character works for you. You could even do it with a shell script: ... | grep 'your-regex' | while read line; do printf '\x7'; done Cheers, Rob
Re: [dev] [st] [patch] misplaced parenthesis in LEN macro
Martti Kühne, 22 April 2014 : > On Sun, Apr 20, 2014 at 9:24 PM, Rob wrote: >> Into the bikeshed I go... >> >> LEN(a + 2) doesn't mean anything anyway, as a's type decays. >> >> To do it properly there should be some kind of static assert in the >> macro that the argument is of array type. But this is a small code base >> and you'd expect that the code would be run and checked before >> committing, which renders the assert pretty useless. >> >> I think it's fine as it is, in the original C way of doing things, >> garbage in, garbage out, undefined behaviour etc etc. >> >> Rob >> > > > I may remind you there is the case where people make struct > concatenations, just because they can. Arrays of concatenated structs. > The cases where you don't even care when the preprocessor will append > a pointer or a size_t to your type. You don't even want to know. > > So, no, the parentheses are not just needed for style. > > Which we require therefore. I'm not sure I follow? struct A bunch[10]; LEN(bunch) ? Can you give an example? Rob
Re: [dev] [st] [patch] misplaced parenthesis in LEN macro
On 20/04/14, sin wrote:
On Sun, Apr 20, 2014 at 02:43:53PM +0200, FRIGN wrote:
On Sun, 20 Apr 2014 13:53:33 +0200
#define LEN(a) (sizeof a / sizeof *a)
is the right way to do it.
You are missing the parentheses there.
Your macro provides the wrong answer for something like:
int a[] = { 1, 2, 3, 4, 5 };
printf("%zu\n", LEN(a + 2));
Into the bikeshed I go...
LEN(a + 2) doesn't mean anything anyway, as a's type decays.
To do it properly there should be some kind of static assert in the
macro that the argument is of array type. But this is a small code base
and you'd expect that the code would be run and checked before
committing, which renders the assert pretty useless.
I think it's fine as it is, in the original C way of doing things,
garbage in, garbage out, undefined behaviour etc etc.
Rob
Re: [dev] hotkey (1) - a suckless global keybinder
On 09/02/14, Chris Down wrote:
On 2014-02-09 01:43:55 -0500, Calvin Morrison wrote:
Surely the user knows what shell they are using? Sure it's a valid
point, but almost irrelevant at the same time. Who cares about their
shell behavior? If they think it's an issue, then they need not run
any commands. I assume people are intelligent, and want to let them
use their shells additional features, rather than retard them with
safety.
Well, I think the fact that you have to append & after each command
about sums up my feelings on the matter.
I suppose it's a question of whether you'll use shell features or not.
If not, you can go with how dwm does it, and pass
(char *[]){ "xterm", "-e", "mail", NULL } to execvp.
Regarding EXIT_SUCCESS, I think this is perhaps a bit picky, 0 is
perfectly fine and besides, every non-trivial shell script hard codes
stdout and stderr: 2>&1.
Rob
Re: [dev][announce] Optimizing C compiler & c++ compiler/runtime
Strake wrote: On 20/12/2013, Rob wrote: https://github.com/bobrippling/ucc-c-compiler Why are you rewriting libc? I think calling it a libc rewrite does it too much justice. When I started out I needed something I could statically link against that would be simple to debug, and had compatible function prologue/epilogue sequences to the cdecl-calling convention ucc originally used. So I knocked together a few libc functions. Now the parser is at a stage that it can handle system headers, and the code-gen can generate x86_64 compatible function call sequences I don't need it, it'll be canned at some point. Rob
Re: [dev] [st][patch] externalpipe()
koneu wrote: Rob wrote: Yeah, based it off url-select, love that feature. urxvt takes 8 seconds or so to open on my laptop, so necessity is the mother of invention and all that. Configure with --disable-everything and use urxvtd. Faster (and more stable) than st for me. Wow, it is pretty snappy actually. Wonder how... Rob
Re: [dev] [st][patch] externalpipe()
Alexander Huemer wrote: On Fri, Dec 20, 2013 at 08:21:34PM +0100, Alexander Huemer wrote: Hi Rob! On Fri, Dec 20, 2013 at 01:56:15PM +, Rob wrote: Attached is a patch which gives st the ability to spit out its current screen text to another program. IMHO it makes sense here to use `xargs -r`, otherwise hitting escape in dmenu results in calling `open` without argument, which does not make much sense. Ah! Didn't know about that, nice suggestion. Admittedly a GNU extension but it's very fitting. Where xurls[1] is a script that pulls out urls from the text, then I can pick one in dmenu and open[2] it in a browser. Very cool, thanks for writing this. I wanted to hack something equivalent to [1] during 30C3, which I won't now because this is much cooler :) Sorry, [1] was missing. Kind regards, -Alex [1] https://raw.github.com/muennich/urxvt-perls/master/url-select Yeah, based it off url-select, love that feature. urxvt takes 8 seconds or so to open on my laptop, so necessity is the mother of invention and all that. Anyway, glad you've found it useful, it's been pushed to the wiki with your modification now too. Rob
[dev][announce] Optimizing C compiler & c++ compiler/runtime
Paul Onyschuk wrote: On Fri, 20 Dec 2013 13:49:43 +0100 Sylvain BERTRAND wrote: There is also the question of finding a new C99 optimizing compiler written properly in C of course. Anything else? On one hand, you can use pretty old GCC and most of C codebase will compile just fine (OpenBSD still uses patched GCC v4.2.1, which is more than six years old). C is stable - you will more likely see changes in standard C library, than compiler/language itself. GCC v4.7.x should work just fine for some years to come. The last problem: C99-capable compiler isn't enough to get usable system based on Linux. Clang which was designed as GCC drop-in replacement chokes on Linux kernel (some patches are needed), because it heavily uses GCC extensions and specific features (some undocumented/undefined). PCC/TCC aren't actively developed, I'm not sure about the status of firm/CParser. Still those alternative C compilers are just good enough for specific programs and not larger set of packages. I suppose if you can get a stable version of GCC, like you say, the platform ABIs aren't going to change, but I can see certain things from C11 coming into libraries, such as atomics. Of course glibc (should) support all the way back to C89. Not sure if musl is C99 and above or not. pcc is pretty much dead but there's active development on tcc, both bug-fixes and work on the ARM ABI code. However I find bugs can easily sneak in due to its very small test suite and somewhat hard to understand / strongly coupled code. Still, speed-wise it goes like a stabbed rat. I've been working on a C compiler in my spare time and recently finished floating point support (minus long doubles). My aim has been to have a simple and easy to understand code base and little bloat, while supporting common extensions, such as emitting the middle term in ?: expressions, __asm__, __typeof__ and so on. The code generation beats tcc's and can usually match or beat gcc and clang's -O0 level in plenty of cases, which I find to be a good balance for now. There's plenty of room for improvement in the backend. The main features left before I can proclaim C99 support are passing and returning structs/unions by value, and VLAs *shudder*. It targets primarily x86_64 and can target x86 (experimental/32-bit) but 32-bit support for 'long long' and x87 floating point stack support are lacking (which is the same reason why long double isn't supported on x86_64 yet). There's also a MIPS backend but this hasn't been tested and is out of date. Alongside this, I'm now at a stage where I can work on getting it to bootstrap. I'm currently held back by a bug in the preprocessor when handling glibc/Debian's unistd.h and it also looks like I'll need to support GNU's transparent union extension too. If anyone's interested. It's hosted here [1] and I'm all ears to critiques and feedback. Thanks, Rob 1: https://github.com/bobrippling/ucc-c-compiler
[dev] [st][patch] externalpipe()
Hi all,
Attached is a patch which gives st the ability to spit out its current
screen text to another program. This can be added under shortcuts in
config.h, e.g.:
static Shortcut shortcuts[] = {
...
{ MODKEY, 'u', externalpipe, { .s = "xurls | dmenu -l 10 | xargs open"
} },
};
Where xurls[1] is a script that pulls out urls from the text, then I can
pick one in dmenu and open[2] it in a browser.
If this doesn't qualify as core-st I'll happily stick it on the patches
page. Feedback welcome.
Rob
1: https://raw.github.com/bobrippling/perlbin/master/xurls
2: https://github.com/bobrippling/openFrom 7982a2d238925028b45d5143db470e408b97469a Mon Sep 17 00:00:00 2001
From: Rob Pilling
Date: Fri, 20 Dec 2013 12:40:55 +
Subject: [PATCH] Add externalpipe() for piping out screen text
---
st.c | 74 --
1 file changed, 68 insertions(+), 6 deletions(-)
diff --git a/st.c b/st.c
index 4fb3311..adef257 100644
--- a/st.c
+++ b/st.c
@@ -299,6 +299,7 @@ typedef union {
unsigned int ui;
float f;
const void *v;
+ const char *s;
} Arg;
typedef struct {
@@ -313,6 +314,7 @@ static void clippaste(const Arg *);
static void numlock(const Arg *);
static void selpaste(const Arg *);
static void xzoom(const Arg *);
+static void externalpipe(const Arg *);
/* Config.h for applying patches and the configuration. */
#include "config.h"
@@ -1204,15 +1206,22 @@ execsh(void) {
void
sigchld(int a) {
int stat = 0;
+ pid_t r;
- if(waitpid(pid, &stat, 0) < 0)
- die("Waiting for pid %hd failed: %s\n", pid, SERRNO);
+ r = wait(&stat);
+ if(r < 0)
+ die("wait(): %s\n", SERRNO);
- if(WIFEXITED(stat)) {
- exit(WEXITSTATUS(stat));
- } else {
- exit(EXIT_FAILURE);
+ if(r == pid){
+ /* _the_ sub porcess */
+ if(WIFEXITED(stat)) {
+ exit(WEXITSTATUS(stat));
+ } else {
+ exit(EXIT_FAILURE);
+ }
}
+
+ /* something else we've forked out */
}
void
@@ -2928,6 +2937,59 @@ xzoom(const Arg *arg) {
}
void
+externalpipe(const Arg *arg)
+{
+ int to[2]; /* 0 = read, 1 = write */
+ pid_t child;
+ int y, x;
+ void (*oldsigpipe)(int);
+
+ if(pipe(to) == -1)
+ return;
+
+ /* sigchld() handles this */
+ switch((child = fork())){
+ case -1:
+ close(to[0]), close(to[1]);
+ return;
+ case 0:
+ /* child */
+ close(to[1]);
+ dup2(to[0], STDIN_FILENO); /* 0<&to */
+ close(to[0]);
+ execvp(
+ "sh",
+ (char *const []){
+ "/bin/sh",
+ "-c",
+ (char *)arg->s,
+ 0
+ });
+ exit(127);
+ }
+
+ /* parent */
+ close(to[0]);
+ /* ignore sigpipe for now, in case child exits early */
+ oldsigpipe = signal(SIGPIPE, SIG_IGN);
+
+ for(y = 0; y < term.row; y++){
+ for(x = 0; x < term.col; x++){
+ if(write(to[1], term.line[y][x].c, 1) == -1)
+goto done;
+ }
+ if(write(to[1], "\n", 1) == -1)
+ break;
+ }
+
+done:
+ close(to[1]);
+
+ /* restore */
+ signal(SIGPIPE, oldsigpipe);
+}
+
+void
xinit(void) {
XGCValues gcvalues;
Cursor cursor;
--
1.7.10.4
Re: [dev] [sbase] printf(1)
Roberto E. Vargas Caballero, Thu, 19 Dec 2013: I'm confused about what you're trying to accomplish here. How about you just copy the format part from the for loop up there and throw it into the standard library's printf? I agree! This strongly smells like NiH-syndrome. Considering we have suckless standard libraries like uClibc, which we could link statically to by default some day in the future, we can safely assume letting the stdlib I think you are lossing something important here. When you execute printf in a program you have the variables which you want to pass to printf, or in the case of vprintf you have the va_list, but in this case you don't have any of them. You cannot call to printf (or vprintf, or sprintf, or vsprintf) with an array of pointers to chars (argv), so you have to forgot the library routines. Exactly. Not to mention, what if the user did this: printf '%f\n' 2 If you "throw it into the standard library's printf", even forgetting about how we do that, you'd still interpret 2 as an int, when printf expects a float. And that's only the beginning, what about %n, or not passing enough arguments? Rob
Re: [dev] New utility "when"
On Thu, 12 Dec 2013, Fernando C.V. wrote:
On Wed, Dec 11, 2013 at 10:36 PM, Rob wrote:
[local-machine %] ssh user@host & && xmessage connected
[ssh-machine %] ...
`xmessage connected' will be executed even though ssh hasn't exit(0)'d
yet.
bash: syntax error near unexpected token `&&'
You probably meant this:
$ { ssh user@host &; } && xmessage connected
Still, you would always be running "xmessage connected" even in the
case of "ssh user@host" failing, which is not what he wants.
Sorry yeah, I didn't clarify enough - meant to say that it wasn't
actually a valid shell script, I was just saying what it would be sort
of like.
But obviously it can't be done in shell, even with your {} / () subshell
stuff, since we can't tell if ssh has connected until it exits (without
a decent bit of hackery anyway).
Rob
Re: [dev] New utility "when"
On Wed, 11 Dec 2013, Andrew Gwozdziewycz wrote: On Wed, Dec 11, 2013 at 4:23 PM, Calvin Morrison wrote: I'm confused how this is different than the usual longrunningscript.sh && generic_notify_command Could you clarify? Using -t, you can notify when the longrunningscript is actually still running. So it's very useful if you have something that fails repeatedly and get an alert when it actually starts. So basically if you have a command that takes input, like ssh, it's like being able to do this: [local-machine %] ssh user@host & && xmessage connected [ssh-machine %] ... `xmessage connected' will be executed even though ssh hasn't exit(0)'d yet. Rob
[dev] [sbase] id commits
Hi,
Attached are two commits for id(1), the first removes curproc() as we
can reuse the now-present user() function. The second adds support for
uid arguments.
uid arguments were mentioned in a previous commit, and it's trivial to
support them, but GNU id(1) doesn't, so it might not be worth the
hassle.
Patch is attached anyway.
Cheers,
RobFrom fad6b54c1c84031291b76644aa9d944ec1dcd091 Mon Sep 17 00:00:00 2001
From: Rob Pilling
Date: Sun, 1 Dec 2013 11:40:49 +
Subject: [PATCH 2/2] id(1) can handle uid arguments
---
id.1 |6 +++---
id.c | 51 ---
2 files changed, 39 insertions(+), 18 deletions(-)
diff --git a/id.1 b/id.1
index 8252773..6bfa06b 100644
--- a/id.1
+++ b/id.1
@@ -3,10 +3,10 @@
id \- print real and effective user and group IDs
.SH SYNOPSIS
.B id
-.RB [ user ]
+.RB [ user | uid ]
.SH DESCRIPTION
Print user and group information of the calling process to standard output.
-If a login name is specified, the user and group information of that user
-is displayed.
+If a login name or uid is specified, the user and group information of that
+user is displayed.
.SH SEE ALSO
.IR who(1)
diff --git a/id.c b/id.c
index ce618fd..78fa71d 100644
--- a/id.c
+++ b/id.c
@@ -7,21 +7,22 @@
#include
#include
#include
+#include
#include "util.h"
static void user(struct passwd *pw);
+static void userid(uid_t id);
+static void usernam(const char *nam);
static void
usage(void)
{
- eprintf("usage: %s [user]\n", argv0);
+ eprintf("usage: %s [user | uid]\n", argv0);
}
int
main(int argc, char *argv[])
{
- struct passwd *pw;
-
ARGBEGIN {
default:
usage();
@@ -30,20 +31,14 @@ main(int argc, char *argv[])
errno = 0;
switch (argc) {
case 0:
- pw = getpwuid(getuid());
- if (errno != 0)
- eprintf("getpwuid %d:", getuid());
- else if (!pw)
- eprintf("getpwuid %d: no such user\n", getuid());
- user(pw);
+ userid(getuid());
break;
case 1:
- pw = getpwnam(argv[0]);
- if (errno != 0)
- eprintf("getpwnam %s:", argv[0]);
- else if (!pw)
- eprintf("getpwnam %s: no such user\n", argv[0]);
- user(pw);
+ /* user names can't begin [0-9] */
+ if (isdigit(argv[0][0]))
+ userid(estrtol(argv[0], 0));
+ else
+ usernam(argv[0]);
break;
default:
usage();
@@ -52,6 +47,32 @@ main(int argc, char *argv[])
return EXIT_SUCCESS;
}
+static void usernam(const char *nam)
+{
+ struct passwd *pw;
+
+ errno = 0;
+ pw = getpwnam(nam);
+ if (errno != 0)
+ eprintf("getpwnam %s:", nam);
+ else if (!pw)
+ eprintf("getpwnam %s: no such user\n", nam);
+ user(pw);
+}
+
+static void userid(uid_t id)
+{
+ struct passwd *pw;
+
+ errno = 0;
+ pw = getpwuid(id);
+ if (errno != 0)
+ eprintf("getpwuid %d:", id);
+ else if (!pw)
+ eprintf("getpwuid %d: no such user\n", id);
+ user(pw);
+}
+
static void
user(struct passwd *pw)
{
--
1.7.10.4
From 4c8bad86bc817974603304cb6e7db7db617daec1 Mon Sep 17 00:00:00 2001
From: Rob Pilling
Date: Sun, 1 Dec 2013 11:31:36 +
Subject: [PATCH 1/2] curproc() isn't needed in id(1)
---
id.c | 60 +++-
1 file changed, 7 insertions(+), 53 deletions(-)
diff --git a/id.c b/id.c
index ce72e70..ce618fd 100644
--- a/id.c
+++ b/id.c
@@ -10,7 +10,6 @@
#include "util.h"
static void user(struct passwd *pw);
-static void curproc(void);
static void
usage(void)
@@ -28,12 +27,17 @@ main(int argc, char *argv[])
usage();
} ARGEND;
+ errno = 0;
switch (argc) {
case 0:
- curproc();
+ pw = getpwuid(getuid());
+ if (errno != 0)
+ eprintf("getpwuid %d:", getuid());
+ else if (!pw)
+ eprintf("getpwuid %d: no such user\n", getuid());
+ user(pw);
break;
case 1:
- errno = 0;
pw = getpwnam(argv[0]);
if (errno != 0)
eprintf("getpwnam %s:", argv[0]);
@@ -73,53 +77,3 @@ user(struct passwd *pw)
}
putchar('\n');
}
-
-static void
-curproc(void)
-{
- struct passwd *pw;
- struct group *gr;
- uid_t uid, euid;
- gid_t gid, egid, groups[NGROUPS_MAX];
- int ngroups;
- int i;
-
- /* Print uid/euid info */
- uid = getuid();
- printf("uid=%u", uid);
- if (!(pw = getpwuid(uid)))
- eprintf("getpwuid:");
- printf("(%s)", pw->pw_name);
- if ((euid = geteuid()) != uid) {
- printf(" euid=%u", euid);
- if (!(pw = getpwuid(euid)))
- eprintf("getpwuid:");
- printf("(%s)", pw->pw_name);
- }
-
- /* Print gid/egid info */
- gid = getgid();
- printf(" gid=%u", gid);
- if (!(gr = getgrgid(gid)))
- eprintf("getgrgid:");
- printf("(%s)", gr->gr_name);
- if ((egid = getegid()) != gid) {
- printf(" egid=%u", egid);
- if (!(gr = getgrgid(egid)))
- eprintf("getgrgid:");
- printf("(%s)", gr->gr_name);
- }
-
- /*
Re: [dev] Re: [st] System freeze when killing X after using st-git
Carlos Torres, Sat, 30 Nov 2013: On Sat, Nov 30, 2013 at 07:29:47AM -0800, Ryan O’Hara wrote: Christoph Lohmann <2...@r-36.net>, 2013-11-30T08:08:43Z I won’t add a »I‐am‐so‐stupid‐to‐buy‐Apple‐ hardware« or »I‐am‐a‐retard‐ using‐Arch‐Linux‐after‐the‐systemd‐disaster« flag. The bug is outside of st. Shall we change it to dwm then? It works fine with literally any other combination. It sounds like this is reproducible, and it also sounds like a debugger might not help so... Why not instrument the code around the so called "troubling" commit and look to see if that reveals proof of a problem?. if you think its a dwm issue, hunt it down with instrumentation. (i.e. carefully thought out print statements.) surely there are other ways to gather more information too... Sounds to me like it's an X11 bug, since it occurs on both Linux and OSX hosts. Seems to be aggravated/caused by spawning an X11 program while another one is picking up/handling depressed keys? (Let's be honest, my keys would be depressed if I was on one of those machines ... ho ho ho) If it can't be reproduced on another host/os combo, one place to look would be Arch / OSX's X11 configure and make flags. Rob
Re: [dev] [st] Changing system clock backwards disables st
On Sat, Oct 26, 2013 at 06:29:31PM -0700, Ryan O’Hara wrote: > When setting the system clock backwards in time (in my particular case, > it was using ntpd -qg), st appears to stop painting for the difference. > > (Is it worth dealing with? The last one was 97 seconds, but it’s no > problem at all to just open another terminal.) Yeah I posted a simple fix to this ages ago [1] but it never went upstream. Rob 1: http://lists.suckless.org/dev/1306/16039.html
Re: [dev] music db editor
On 12 October 2013 08:16, Daniel Bryan wrote: > > I did once start (and abandon) a tool that did a small part of this: it > would examine the tags in my music folder and identify: > > * files that weren't organised correctly into folders by artist and > album > * files that seemed to be missing key tags like track number, artist, > album > > It would print the filename, the artist and the album, tab-delimited, so > it was easy to then script moving the offending files into the right > place with cut, xargs, awk, etc. Still got that script lying around? Rob
[dev] rohrpost [was: Tabbed status?]
On Thu, Oct 10, 2013 at 07:37:46PM +0200, Christoph Lohmann wrote: > Greetings. > > I tried a simple > > rppick :from alex0player :subject tabbed > rpview p | git am --signoff > > This gave back the whole e‐mails. Then it took your first comment and > all the diffs. They are all in the last patch. I will have to write some > rpgit utility. This looks great - I've been waiting for rohrpost to be published, I'm getting tired of everything locked in mutt's UI and would love to see it, regardless of how complete it is. You never know, others might help finish the job. Rob
Re: [dev] [sbase] [PATCH] ls: add option to reverse the sort order
On Sat, Oct 05, 2013 at 03:47:05PM +0400, Alexander S. wrote: > 2013/10/5 Rob : > > On Fri, Oct 04, 2013 at 05:45:56PM +0400, Alexander S. wrote: > > I disagree - rather than adding a sort call and changing the program's > > runtime complexity, can't we just reduce the amount of lines _and_ > > duplication like this: > Reversing an array we just sorted isn't adding complexity, it's O(n) > adding to O(n log n). > Touche
Re: [dev] [sbase] [PATCH] ls: add option to reverse the sort order
On Fri, Oct 04, 2013 at 05:45:56PM +0400, Alexander S. wrote: > 2013/10/4 Raphaël Proust : > If we want to retain this patch, I'd suggest reversing array after > sorting, not multiplying by `sortorder' in comparison functions. This > avoids code duplication. I disagree - rather than adding a sort call and changing the program's runtime complexity, can't we just reduce the amount of lines _and_ duplication like this: @@ -89,9 +93,9 @@ entcmp(const void *va, const void *vb) const Entry *a = va, *b = vb; - if(tflag) - return sortorder * (b->mtime - a->mtime); - else - return sortorder * strcmp(a->name, b->name); + return sortorder * (tflag ? b->mtime - a->mtime : strcmp(a->name, b->name)); } void With line wrapping as appropriate. Thanks, Rob
Re: [dev] [st] [patch] Fixed lock up when system time jumps back
On Thu, Jun 20, 2013 at 11:41:02PM +0200, Silvan Jegen wrote: > On Wed, Jun 19, 2013 at 09:26:13PM +0100, Rob wrote: > > It seems st enters a heavy draw cycle when system time is moved back > > (e.g. ntp). > > This patch should fix it. > > I had the same problem and this patch seems to have fixed it though > some more testing may be advisable. Thanks! > > I was trying to debug the problem using gdb but the backtrace hang > somewhere in libc and I could not make sense of it. Good to hear, as far as I can tell I wouldn't expect any regressions, since there's just an extra draw performed if the change in time is negative, so at worst your st terminals will all redraw when the time jumps back. Do let me know if it goes funky though. Cheers
[dev] [st] [patch] Fixed lock up when system time jumps back
It seems st enters a heavy draw cycle when system time is moved back (e.g. ntp). This patch should fix it. Cheers, Rob 0001-Fixed-lock-up-when-system-time-jumps-backwards.patch Description: Binary data
Re: [dev] [sbase] 64-bit type for split
Interesting mix of top- and bottom-posting. I'll not disturb it. Anyway, 1999 was 14 years ago. I think uint64_t is the least of our worries if we're porting to some exotic architecture where gcc can't at least emulate a 64-bit integer. I mean even tcc has a runtime library for that. On Tue, Jun 11, 2013 at 01:10:37PM -0500, Galos, David wrote: > Right, but '-ansi -pedantic' is strictly C89. GCC doesn't complain, > but I could imagine there being trepidation around using a C99 header > in a C89 environment (where it is not required). > > 2013/6/11 Thorsten Glaser : > > Galos, David dixit: > > > >>On GNU systems stdint.h still provides uint64_t, but I have no idea > >>how portable this is. > > > > is C99. > > > > bye, > > //mirabilos > > -- > > 17:08⎜«Vutral» früher gabs keine packenden smartphones und so > > 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig > > 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch > > 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit > > klarkommt > > >
Re: [dev] ii IPv6 support
On Thu, Apr 11, 2013 at 08:32:43PM -0500, William Giokas wrote: > On Fri, Apr 12, 2013 at 09:25:25AM +0800, Patrick Haller wrote: > > i mean in the ii repo -> http://git.suckless.org/ii > > I agree...I think they should be put into separate branches. It would > make rebasing to a newer version ridiculously easy for end users, and > managing patches easy as well. > > I currently do something similar with dwm, I have a branch 'pristine' > that tracks origin/master, and a multitude of other branches for > different patches with one that I selectively merge to called > 'patched' that I use for building. There's no reason to keep patches > as patch files in git. In that case, you might find stacked git (stg) useful [1]. I use it to keep patches on top of origin/master and apply certains ones depending on which machine I'm on. Rob [1]: http://www.procode.org/stgit/
Re: [dev] [st] Segmentation fault when clicking the top of window
On Sun, Mar 24, 2013 at 11:15:21AM +0200, Juhani Haverinen wrote: > Hello. I have noticed a strange bug that results in segmentation > fault. If I click at the top 2 pixel rows in st window it will crash. > I attached a backtrace. > > -Juhani Could you also show us a "bt full" or maybe upload the core dump? Rob
Re: [dev] dwm switches view on _NET_ACTIVE_WINDOW
I completely removed that behaviour, I hate focus stealing. Not a bad idea you've had there though. Cheers, Rob On 4 March 2013 10:36, Markus Teich wrote: > Hi, > > a month ago i started using dwm. > In my rules i send firefox clients to tag 2. > Now, after starting dwm i am on tag 1 and after i started firefox via > dmenu, i automatically get switched to tag 2. > Right after starting dwm this is not that much of a problem, but when i > have some work in progress and use both views (via mod+tab) and then > start another application, which is not in the current tagset, i loose > one of my views to the tags of the started application. > Is there a particular reason for this behaviour? > > I found it kind of annoying and so i patched it to just pull in the tags > from the started application without switching view. > It is pretty simple and also removes one line of code. Yay! > > --Markus >
Re: [dev] FTP script: how to store password?
On Sat, Feb 09, 2013 at 01:41:26PM +0100, Hugues Moretto-Viry wrote: > If I understand correctly, your demonstration works because it's like you > added a parameter to an existing program. > In my script, you can't use a parameter, I just use variables inside the > script. > So, ps -ax just shows the called script or the command used in the variable > (here SQlite) and not the string. > > That's why I said I was unable to display the plain password (with SQlite I > mean). :) $ PASS=hello sleep 5 & [1] 16667 $ pid=$! $ ps ax | grep $pid 16667 pts/6S 0:00 sleep 60 $ tr '\0' '\n' < /proc/$pid/environ | grep PASS PASS=hello Of course, the "attacker" would need read permission on /proc/$pid, which is normally 600. Rob
Re: [dev] My dwmstatusbar.c
Thanks for the good suggestions - I'll have a pop at the daemon and see how it goes. Cheers, Rob
Re: [dev] My dwmstatusbar.c
On Sun, Dec 30, 2012 at 05:01:10PM +0100, Mariano Bono wrote: > Hi all, > I'm a new dwm user and i've written a simple dwmstatusbar app that > show volume and time. > The code relative to volume use alsalib and maybe someone can find it > useful. > Critics and suggestion are welcome. Here's one for you all - my keyboard has a scroll wheel, and I currently have it hooked via dwm to run an external shell script to increase/decrease the volume. I find that if my machine's under heavy-ish load (or if I scroll a lot), multiple processes open and all try to increment the volume to the same target. Too many cooks spoil the broth and we end up going quite slowly. I was thinking of linking dwm with alsa and doing all of the volume control inside dwm. Before you start flaming, I realise dwm is a window manager, not a volume control, which is why I'm writing to the list - anyone got any smart ideas about this? Cheers, Rob
Re: [dev] Migration to git
On Thu, Nov 29, 2012 at 09:33:23PM +0200, Barbu Paul - Gheorghe wrote: > On 11/29/2012 02:25 AM, Christoph Lohmann wrote: > Now I have a question: > > How can be patches for dwm be managed via git? > I mean I need a patch queue somehow, I'm thinking branches, I'll > create a local branch with my patches applied and I will hack > through its history. > > What are you guys suggesting/using? I imagine you can keep your own local branch, and rebase it upon suckless' master branch, when it changes. Cheers, Rob
Re: [dev] [st] extra arguments to xcopy()
On Wed, Sep 05, 2012 at 11:07:33AM -0400, Andrew Hills wrote: > In hg tip (c84141b8303e), two calls to xcopy() in xdrawcursor() pass > four arguments, which takes no arguments. It looks like xcopy() was > changed in dcba87365e02 and not all calls to xcopy() were updated. The > attached patch removes the arguments (no functional changes). I hope > the current behavior is correct. > > --Andrew Hills Might be worth winging this in while you're at it. Rob diff -r c84141b8303e st.c --- a/st.c Wed Sep 05 01:32:42 2012 +0200 +++ b/st.c Wed Sep 05 19:20:24 2012 +0100 @@ -290,7 +290,7 @@ static void xdraws(char *, Glyph, int, int, int, int); static void xhints(void); static void xclear(int, int, int, int); -static void xcopy(); +static void xcopy(void); static void xdrawcursor(void); static void xinit(void); static void xloadcols(void); @@ -315,7 +315,7 @@ static void selinit(void); static inline bool selected(int, int); static void selcopy(void); -static void selpaste(); +static void selpaste(void); static void selscroll(int, int); static int utf8decode(char *, long *);
Re: [dev] [ii] exposed password on process monitoring
On 15 June 2012 03:40, Andrew Hills wrote: > If you don't want the password argument to appear in ps/top listings, > you can write over argv like curl does (see references to > cleanarg(char*) in src/tool_getparam.c and the function definition in > tool_paramhlp.c:133, at least in curl-7.26.0). I'm pretty sure that > writable argv is guaranteed by C89, although that doesn't really mean > anything in practice... but it works on Linux. You can't depend on this - what if another user's process snapshots ii's argv array before ii overwrites it? Rob
Re: [dev] dwm: XKeycodeToKeysym deprecated patch
On 16 May 2012 02:58, Kurt H Maier wrote: > On Tue, May 15, 2012 at 09:52:10PM -0400, James Turner wrote: >> >> XKBlib.h has been around since 1993 is an extra header file really that >> bad? > > Are you arguing that it's good code because it's old code? You were arguing that it's bad because it's the "latest" mandate. I call subtle trolling
Re: [dev] slock && fullscreen
On 25 April 2012 08:16, hiro <23h...@googlemail.com> wrote: > This is about the lamest usecase for slock I've ever heard of. > Next people will complain locking the toilet door with it didn't work > and someone saw their junk. Prepare to get a lawyer Amselm. I frequently use slock on my bog door, my junk hasn't been seen by another human in 40 years. Best program ever. A+
Re: [dev] Moveresize patch page defaced
On Wed, Feb 22, 2012 at 03:19:28PM +0100, clamiax wrote: > That's most likely due to your wrong workflow, which includes moving X > clients between monitors. I'm not complain about multi-head setup, I'm > just telling you that moving windows between monitor without any kind > of criteria is a flaw in your worflow. Nah I'm just lazy or sometimes don't have a mouse. Might be slower using keys but I don't want to move my arms. Optimal "workflow" isn't my goal. > > That's why it's a patch and not in tip > This mean people can put any kind of patch on suckless.org regardless > if it comply with our phylosophy or not (and place it above that which > comply instead). Ok, I just learned a new rule. More or less
Re: [dev] Moveresize patch page defaced
On 22 February 2012 08:58, clamiax wrote: > I'm here to discuss about the change *before* make it, since most > people may not agree with me. I don't agree, I like moving windows with the keyboard, and the cross-monitor thing was bugging me >> The 6.0 patches do look ok from my point of view. > Adding 60 SLOC with no real benefits is not ok, from my point of view. That's why it's a patch and not in tip > But yes, I understand someone may like to moving X clients around > between monitors just for funny. You've got to have some sense of humour when using dwm/this mailing list Rob
Re: [dev] ... and then i go and spoil it all by saying something stupid ...
On 15 February 2012 07:34, hiro <23h...@googlemail.com> wrote: > Fuck off. > (It's the same I told my gf btw) Ha! That's a good one, people on suckless having girlfriends...
Re: [dev] [st] htop, tmux, terminfo
On Sun, Feb 12, 2012 at 05:14:22PM +0100, Martin Kopta wrote: > On 02/12/2012 04:26 PM, Rob wrote: > >All the programs I use work fine in st, except htop, .. > > I am glad to hear that. I use urxvt as my main terminal though, but as far as I'm aware, anyway. > >Although I wrote my own process monitor (http://github.com/jeffwar/utop) > >with vi key bindings, since I found it annoying that I kept having to use > >the arrow keys in htop > > I have exactly the same issue with utop as I have with htop. I guess > I should rather adopt vmstat and ps. > However, utop seems like a nice piece of software. Yeah, utop uses a dark/bold colour for non-owned processes too. Thanks, but yeah, I suppose it's a bit unnecessary
Re: [dev] [st] htop, tmux, terminfo
On Sun, Feb 12, 2012 at 09:15:34AM +0100, Martin Kopta wrote: > > Thank you for pointing me back to the original messages about > st/htop. Unfortunately, as I said, I haven't find any solution. The > message from Stefan Mark does mention that "I agree that in case of > htop its a bug, because both ways (st and xterm) are correct (as far > as i know), so it should be usable without the patch.", but as I > have shown in attached screenshot, it (st/htop) is not usable as it > is and I was unable to find any patches or any other solution. Maybe > I have just messed up something in my system. > > Does htop in st works properly for others? > > I am not particularly up to htop actually. I am just afraid there is > lots of other app with the same issue and I just haven't met them > yet in my short time of using st. All the programs I use work fine in st, except htop, and I just have a script run (attached), which alter's htop's config so when it's running in st it'll use black and white mode. Although I wrote my own process monitor (http://github.com/jeffwar/utop) with vi key bindings, since I found it annoying that I kept having to use the arrow keys in htop Thanks, Rob htop.sh Description: Bourne shell script
Re: [dev] [st] htop, tmux, terminfo
On Sun, Feb 12, 2012 at 12:59:30AM +0100, Martin Kopta wrote:
> The process viewer htop isn't drawing properly in st [1].
> Is there know solution for st/htop drawing problem?
This is a known "bug", I think the thread on it before is here [1]
Basically, st doesn't have a bold/bright colour, and just uses normal
black
> I have also noticed that when I log into some system via ssh, tmux
> won't let me attach my sessions due missing terminfo for
> st-256color. Well, for my private servers, I just scp .terminfo
> directory and problem is solved. However, I co-manage lots of
> various company servers and customer servers and copying .terminfo
> into each of them is just silly. Changing TERM to "xterm" forces
> apps run, but drawing goes mostly horribly wrong. So, my second
> question:
> How do you deal with st, terminfo of st and ssh to lots of various servers?
>
> [1] http://martin.kopta.eu/trash/st-htop.png
for s in $(grep '^Host' .ssh/config | awk '{print $2}')
do ssh $s tic - < path/to/st.info
done
or whatever to get tic to read stdin
Thanks,
Rob
[1] http://lists.suckless.org/dev/1104/7444.html
Re: [dev] slock-1.0
On Sat, Feb 11, 2012 at 01:50:38PM -0500, Joseph Iacobucci wrote: > On 02/11/2012 05:03 AM, Anselm R Garbe wrote: > > It does not contain other potential features that were requested > > during the years, like displaying some text in case the user hits his > > keyboard. Such features will be subject to future slock releases. > > Instead of text, I configured my slock to change the background color > when there are keyboard presses. If the password check fails, then it > goes back to the main color. People can have the existing behavior by > making both colors the same. Do you have a publicly accessible copy of the source code or a patch?
Re: [dev] stest review
On Sat, Feb 11, 2012 at 02:04:43PM +0100, Christoph Lohmann wrote: > Hello. > > Anselm R Garbe wrote: > > If you can write a simple for() loop to process your command line > > flags, your interface can't be that hard to grasp for the user. > > Otherwise he will look up the weirdo flags quite often in your man > > file and develop hate against your tool over time ;) > > That is plain wrong. I disagree > Users will rather be irritated, if the commandline argument hand- > ling is different in every application. They then *have* to read > the sourcecode for finding out how arguments are handled. What Anselm is on about, is that it prevents the programmer from adding more and more flags, keeping the complexity low, not from having a different style for each application. Rob
Re: [dev] sbase TODO patch
On Thu, Feb 09, 2012 at 10:37:51PM +0100, Lukas Fleischer wrote: > On Thu, Feb 09, 2012 at 04:06:59PM -0500, Galos, David wrote: > > malloc() in yes(1) is definitely overkill. I've attached a simple > > version. > > Invoking malloc() once (resulting in O(1) additional time and space) is > overkill but using printf() in every iteration (which means firing up > the printf() parser over and over again) isn't? I think you're a tad off > base, sir... > > There's only two ways to implement this properly: > > * Build the string during program initialization and use puts() (or > something similar) to print that string over and over again. > > * Call the output routine once for each token in each iteration. If we > use buffered streams, this shouldn't make much difference. We should > probably do some quick performance tests to be sure, though. What's more, that version prints "a\nb\n" for ./yes a b, instead of "a b\n". Forgot completely about puts() though. Rob
Re: [dev] sbase TODO patch
On Thu, Feb 09, 2012 at 12:15:32PM +, stateless wrote:
> Hi all,
>
> Implemented yes(1), sync(1) and printenv(1). Source is attached,
> haven't had time to write the manpage yet.
>
> Cheers,
> stateless
These are slightly shorter and printenv() returns 1 when it can't find
the environment variable.
Thanks,
Rob
#include
#include
#include
#include "util.h"
int main(int argc, char **argv)
{
char *print_me;
if(argc < 2){
print_me = "y";
}else{
char *arg, *p;
int i, len = 1;
for(i = 1; i < argc; i++)
len += 1 + strlen(argv[i]);
p = arg = malloc(len);
if(!arg)
eprintf("malloc():");
for(i = 1; i < argc; i++)
p += sprintf(p, "%s%s", argv[i], argv[i + 1] ? " " : "");
print_me = arg;
}
for(;;)
printf("%s\n", print_me);
}
#include
#include
int main(int argc, char **argv, char **environ)
{
int ret = 0;
if(argc <= 1){
char **ep;
for(ep = environ; *ep; ep++)
printf("%s\n", *ep);
}else{
int i;
for(i = 1; i < argc; i++){
char *env = getenv(argv[i]);
if(env)
printf("%s\n", env);
else
ret = 1;
}
}
return ret;
}
Re: [dev] skype gui interface
On Wed, Feb 01, 2012 at 09:58:14PM +0400, Nikolay G. Petrov wrote: > Can you tell me why if I start skype, gui interface is absent, not > apear, but a skype process persist? dwm doesn't have a systray, which skype minimises itself to regardless. Try stalonetray or trayer.
Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply
On Fri, Jan 20, 2012 at 07:01:22PM +, Bjartur Thorlacius wrote: > Does this actually go out and send a SIGTERM to the PID of the owner > of the window, or merely destroy the window? Surely it just destroys the window, you can't get a PID for any X window, since it could be a networked one
Re: [dev] [dwm] Tags vs Monitors
On Fri, Jan 13, 2012 at 11:35:02AM +0100, Thomas Dean wrote: > On Thu, Jan 12, 2012 at 17:44:56 -0500, TJ Robotham wrote: > > You might find it helpful to go into sendmon and delete that one line that > > resets the window's tags to whatever's currently visible on the other > > monitor. > > That was pretty much the first thing I did when multihead support was added, > > since I rarely want to both move a window between monitors and retag it. > > Thank's a lot for this hint! This would result in almost exactly what I > want. In fact, if combined with a patch that would keep the set of visible > tags on both screens in sync, I think it would be exactly what I want. Does > anyone know how to achieve the latter? Check /(toggle)?(view|tag)/ functions in dwm.c Or you could change arrange() so it sets the tagset for all other monitors too Rob
Re: [dev] [dwm] Tags vs Monitors
On Fri, Jan 13, 2012 at 11:32:42AM +0100, Thomas Dean wrote: > This problem would come up if there was only one tagset and each monitor > would be an independent view whose visible tags could be set independently. > I rather meant that there should be only one tagset, and all monitors > together would form a combined view, i.e. both monitors would always have > the same set of tags visible. Each window should still be assigned a > definite monitor. I'm sorry if my previous description was unclear, and > hope that this one clarifies it. Oh, yeah I got the wrong end of the stick, I thought you meant a tagset which was shared between each monitor or something, thanks for clearing that up. Personally I prefer the way it's set up at the moment, but I'd be interested in seeing any patches anyway. Cheers, Rob
Re: [dev] [dwm] Tags vs Monitors
On Thu, Jan 12, 2012 at 04:16:37PM +0100, Thomas Dean wrote: > I would imagine that the (or my at least) workflow could be much smoother > if there was only one tagset, independently of the number of monitors, and > if there were (a) layout(s) suitable for multi-screen views. The first > useful layout for two monitors that would come to my mind would consist of > two master windows plus one stack on one of the two monitors. > > What do you guys think? How do you make efficient use of two monitors? Do > you find the current tag/monitor paradigm useful? I would be very > interested in your opinions. I had this thought, but how would you implement it? What if you selected the same tagset on each monitor? You can only display a window in a single place, so it couldn't be on both monitors at the same time, think about it. It can't be done unless you can somehow clone the window or something (I'm not very clued up on X11). Rob
Re: [dev] dmenu-4.5
On 11 January 2012 10:55, Džen wrote: > Hey Connor > > I've discovered a little imperfection when running dmenu with the -f > flag (note that this is really a tiny issue and maybe it would be better > to just ignore it). > > Due to the fact that dmenu locks up the keyboard before reading data > from stdin, the user isn't able to exit dmenu while it is waiting for > (or reading) data from stdin. As far as I know the only solution would > be to switch over to a tty outside of X, then send a kill signal to > dmenu. This can be annoying if dmenu has to wait for data for a long > time or no data is coming at all, and the user simply wants to exit > dmenu. This is a known bug, we decided to leave it as it is, for the time being, because we couldn't think of a simple way to solve it, and I think there's a note somewhere about only using -f if dmenu is reading from a non-tty. I think I did have dmenu set to print a warning if stdin was a tty and -f was given, but I don't know what happened to it. > IMO, dmenu should always exit if XK_Escape or Ctrl-C is pressed. This > could be solved by select()'ing through the stdin fd and X fd, in order > to be able to handle KeyPress events from X. I hadn't thought of this solution, it increases the complexity, so I suppose it's up to Connor, I'm at work at the moment so I can't test it out either. > The attached patch works for me, however I'm not sure whether this is an > elegant solution. A possible issue with this patch might be the loss of > speed while reading data from stdin (due to the select() calls, etc). > > What's your opinion? I wouldn't imagine a few extra select calls would matter. What if we used select() until we got input on stdin, then just read all of stdin at once, not bothering to select() again? Unless you're reading over a network, I don't think there's that much of a delay. Cheers, Rob
Re: [dev] sbase ls patch
On 22 December 2011 23:10, Bjartur Thorlacius wrote: >> Tiny cleanup patch. Now more memory is allocated than necessary. > > Is that a good thing or a typo? Looking at the code, it appears to be a typo, now the exact amount of memory is allocated Rob
Re: [dev] [slock] segfault
On 4 December 2011 22:19, Arian Kuschki wrote: > I get a segfault when running slock via my acpi handler script: > > Dec 4 23:15:00 localhost kernel: [26284.789539] slock[13389]: > segfault at 0 ip 7f12b8b57879 sp 7fff74d6d810 error 4 in > libnss_files-2.14.1.so[7f12b8b5+b000] Can you get a coredump and give us a stack trace? In your script: ulimit -c unlimited Then when slock segfaults, hunt around for a file named "core". Probably in $HOME Then: $ gdb path/to/slock path/to/core (gdb) bt You might want to compile slock with debug flags too (replace -s with -g in config.mk) Rob
Re: [dev] [dmenu] Keyboard Bindings
On 21 November 2011 09:15, Yoshi Rokuko wrote: > it seems that i cannot communicate my point - why are vi-styled-key- > binding-styled-interfaces so popular? It's not vi-style, it's Unix. If you come from a Windows background, you'll be used to Ctrl+Backspace to delete a word, or Shift+Home, Backspace to delete a line. Unix has C-W and C-U, it's just muscle memory. Rob.
Re: [dev] semicolons
On 18 November 2011 12:24, pancake wrote:
> should we support code written by bitches?
main(argc, argv)
int argc;
char **argv;
{
}
// SLOC of two, should be zero
#define SEMI ;
int main(int argc, char **argv)
{
int i SEMI
for(i = 0 SEMI i < argc SEMI i++)
printf("argv[%d] = %s\n", i, i[argv]) SEMI
return 0 SEMI
}
// SLOC count of 1, should be much more
:P
Re: [dev] semicolons
On 18 November 2011 11:41, Roger wrote: > Anything can be worked around one way or another. For reference, standard > benchmark tools also never look at just "one thing". Exactly, short of writing a C-parser and doing some heuristic on the syntax tree, you'll just end up missing things anyway. if(5) x = 5, y = 2, apply_layout(NULL), something_else_that_doesnt_use_semi_colons();
Re: [dev] Start dwm on different tag selection
On 13 November 2011 18:22, Stephen Paul Weber wrote:
> I used to be able to start dwm on a different tag selection than the default
> (which is only select tag 1). Is there still a way to do this?
This is what I use, I'm not at my box right now, so it's a rough guess, but I'm
pretty sure it'll work.
Obviously TAG_INIT wants to be your starting tag mask.
Rob
diff -r ee36ffbd4252 dwm.c
--- a/dwm.c Sun Nov 06 20:36:23 2011 +0100
+++ b/dwm.c Sun Nov 13 18:34:07 2011 +
@@ -647,7 +647,7 @@
if(!(m = (Monitor *)calloc(1, sizeof(Monitor
die("fatal: could not malloc() %u bytes\n", sizeof(Monitor));
- m->tagset[0] = m->tagset[1] = 1;
+ m->tagset[0] = m->tagset[1] = TAG_INIT;
m->mfact = mfact;
m->nmaster = nmaster;
m->showbar = showbar;
Re: [dev] xv6
On 9 November 2011 19:49, Truls Becken wrote: > Professors at MIT have rewritten Unix V6 in 7000 lines of ANSI C for use in > operating system class. I thought it might interest some people on this list. > > http://pdos.csail.mit.edu/6.828/2011/xv6.html Thanks, I look forward to reading this. Rob
Re: [dev] [surf] downloads
On 5 November 2011 14:26, Troels Henriksen wrote: > Étienne Faure writes: >> Try this: >> >> wget >> 'http://www.vim.org/scripts/script.php?script_id=3792&adding=dummy&arguments=that&could=be&a=horrible&hash=that&i=ve&seen=on&crappy=sites&unfortunatly=i&can=not&find=a&publicly=available&example=of&this=so&let=s&go=for&a=hash&here=514241337a3c43a0bb28eb88de0adde1&and=another&one=K3NYV1NvZm9IeU5IRFRjbkFIdjdlV0F5cW5HbVFzeWJpcFd0UHZyenhEZklDSUNrb1VwdnN3PT0K' > > What an ugly mess. Is there really no usable downloader program that > can handle these (not terribly rare) cases in a simple manner? This > sounds like a good candidate for a new Suckless project, although I'm > partial to simply using the wget-loop for now. I don't know why wget and curl fail on this. Anyway, time for a shameless self-plug. http://github.com/jeffwar/wgetlite Handles it fine. The only thing it's lacking is HTTPS support at the moment. Rob
Re: [dev] Re: [dwm] A general approach to master-slave layouts
On 31 October 2011 23:07, lolilolicon wrote: > Indeed mfact and nmaster being members of Layout does make more sense, and > I made a patch which includes this change. > Note that this may seem to add some SLOCs, but it actually reduces the > amount of code required to implement the same layouts by avoiding code > duplication. See how tile, bstack and col are each defined using just a > one-liner. By defining two layout algorithms `lt_vstack` and `lt_hstack`, > in combination with the hsplit switch, one can define 2 ** 2 * 2 = 8 such > layouts, and if you count the (masters|slaves)-only layouts as separate > ones, we got 10. Add a third layout algorithm, and you have > 3 ** 2 * 2 + 3 = 21. Sure, not all layouts are useful for everyone, but > hopefully this will produce some interesting layouts suitable for your > particular setup. I don't have much time today, or possibly tomorrow, but I'm interested in this patch, it sounds almost like it recurses on each sub-section of the total area, applying a different layout function each time, except it's limited to two calls, one for the master area and one for the slave. Either way, I'm hoping to try out your patch(es) at some point this week, and hoping to mess around with the key bindings, I assume you can change the master layout while keeping the slave one the same with a binding, right? Cheers, Rob
Re: [dev] [dwm] ncol layout
On 30 October 2011 20:13, Anselm R Garbe wrote: > As for the nmaster discussion: I think what I really dislike is the > fact that adjusting nmaster requires 2 key combos. What I could live > with is fixing nmaster in config.h. > > This leads me to the question to long-time users of nmaster: Do you > guys adjust nmaster frequently, or do you just stick to a particular > setting? I guess the latter... Please let me know. > > Cheers, > Anselm I find myself using ntile and nmaster frequently for things like chat tags, where I want all the windows in the master column to be more or less even, and then a couple of buddy-list windows squashed to the side. I only adjust if I have many chat windows and the tile method starts putting them into the slave-column, so I can to push them back into the master column. tl;dr: I mainly stick to tile. Rob
Re: [dev] Focusing on windows by name
On 26 October 2011 14:51, Peter John Hartman wrote: > I do something similar: > > if [[ $foo != "" ]]; then [ -n "$foo" ] if you're going for POSIX.
Re: [dev] Introducing SEE, the Simple Executing Engine
On 22 October 2011 19:36, Pierre Chapuis wrote: > On 22.10.2011 15:47, Xinhao.Yuan wrote: > >> http://github.com/xinhaoyuan/see > > Looks interesting, but what the hell is that? > > static char __sa[sizeof(gc_header_s) == GC_HEADER_SPACE ? 0 : -1]; It's a similar compile time check similar to what dwm uses, in this case, it checks if gc_header_s is the same size as GC_HEADER_SPACE. Rob
Re: [dev] hidcur: Utility for hiding the mouse cursor in X11
On 5 October 2011 09:54, Bastien Dejean wrote: > Rob a écrit : > >> I find unclutter sometimes locks my focus to a window, I try to shift focus >> (dwm), it just jumps back. > > You probably need to launch unclutter with the -noevents option. That's fixed it, thank you very much! Rob
Re: [dev] hidcur: Utility for hiding the mouse cursor in X11
On 4 October 2011 19:06, Ricardo Catalinas Jiménez wrote: > On Tue, Oct 04, 2011 at 07:47:44PM +0200, pmarin wrote: >> Any advantage over unclutter? > > No, except that the code is simpler. unclutter support some nice > features like ignoring mouse jitter, which I could add in a future. I find unclutter sometimes locks my focus to a window, I try to shift focus (dwm), it just jumps back. I'd use hidcur, except that the initial click isn't passed through to the window beneath, so scrolling in a browser, for example, seems delayed. Might have a go at patching it in tomorrow if I get some time. Thanks, Rob.
Re: [dev] Make dmenu sensitive to user aliases ("Hello world")
On 1 October 2011 19:55, Kiriakos at Kindstudios wrote: > I'm using many aliases in my terminal sessions and want to be able to use > them with dmenu Just a guess - in dmenu_run, source the file that defines your aliases, before doing anything else. Rob
Re: [dev] Missing hg repo after move?
On 29 September 2011 20:08, Jeremy Jackins wrote: > hg clone http://hg.suckless.org/sandy > gives > abort: HTTP Error 500: Internal Server Error Secret coup against Sandy
Re: [dev] How to get windows opened on one tag?
On 20 September 2011 08:53, Yue Wu wrote:
> Hi list,
Hello.
> Sometimes I want to know all windows that I've opened on current tag, to
> know if a window has opened and decide to find and switch to it, so my
> question is how to get a list of opened windows names on current tag? The
> statusbar shows only current focus window name.
Apply the attached patch to config.h, and include the attached C file in
dwm.c somewhere just above the function implementations.
You might have to add the prototype for list_cur_tag somewhere in your
config.h too.
If you want dwm to constantly output the current client list to a file,
you'll have to use alarm(3), threads or something similar.
Rob
void
list_cur_tag(const Arg *arg) {
Client *c;
FILE *f;
if(!arg || !arg->v || !selmon)
return;
f = fopen(arg->v, "w");
if(!f){
fprintf(stderr, "open %s: %s\n", arg->v, strerror(errno));
return;
}
for(c = selmon->clients; c; c = c->next)
if(ISVISIBLE(c))
fprintf(f, "%s\n", c->name);
fclose(f);
}
diff --git a/config.h b/config.h
index afc6bee..daa2e61 100644
--- a/config.h
+++ b/config.h
@@ -227,6 +227,8 @@ static Key keys[] = {
{ MODKEY, XK_y, incnmaster, {.i = +1 } },
{ MODKEY, XK_o, incnmaster, {.i = -1 } },
+ { MODKEY|ShiftMask,XK_g, list_cur_tag, {.v = "/tmp/dwm_cur_tag" } },
+
TAGKEYS( XK_1, 0)
TAGKEYS( XK_2, 1)
TAGKEYS( XK_3, 2)
Re: [dev] A dmenu that includes all additional features
On 12 September 2011 14:26, Dieter Plaetinck wrote: > I wonder if we could restructure the code a bit in such a way, that > all patches can be independent again and user can combine the patches > they want without hitting conflicts. I don't think this would be worth it, suckless tools are supposed to be lightweight, even someone who hasn't seen the code before can make changes, they don't have to be an expert at C, so merging a few lines here and there is no big deal. Rob
[dev] suckless wget
Hi all, After a bit of interest off list, I've decided to release wgetlite[1], wget, but low on options, size and hopefully suckyness. Not sure how suckless it actually is, considering that there's quite a bit of HTTP code that could be removed, but I thought I'd get peoples' opinions/patches on it anyway. Thanks, Rob. [1]: http://www.github.com/jeffwar/wgetlite
Re: [dev] Re: [lsw] List only visible windows
On 28 August 2011 14:49, Christian Neukirchen wrote: > My private fork of lsw also features a check for the urgency hint, which > I use in my statusbar to see fresh messages in pidgin and skype. Could > be useful in general. > > -- > Christian Neukirchen http://chneukirchen.org How do you set the tag(s) urgency hint for new Skype messages? I noticed one can get Skype to run a script on a new message, but I wasn't sure what to do after that. Rob
Re: [dev] [dwm] Fullscreen Layout
On 14 August 2011 21:03, Bastien Dejean wrote: > Hi, Hello > Any idea on how to implement a fullscreen layout? Mod + b, Mod + m
Re: [dev] [dwm] [patch] USPosition, USSize
Since there's a few opinions on this, how about we make a dwm "focus" page? The NetActiveWindow hint is not one of the better ideas in the history of X11, it really got my goat when windows started stealing focus while I'm trying to type elsewhere. Rob focus.md Description: Binary data
Re: [dev] [wmii] Flash in fullscreen regularly freezes screen
On 6 August 2011 11:09, Ethan Grammatikidis wrote: > On Sat, 6 Aug 2011 09:19:24 +0100 > Rob wrote: >> Somewhat off topic now, but http://repo.hu/projects/yget/ works fine for me > > Shell script and an order of magnitude smaller than youtube-dl which > I've been using, nice! Is it updated quickly when youtube changes? I think so, yeah. There was a recent change, where the core yurl program stopped working, youtube must've changed something. I checked today and there was an updated version on svn, which works fine. Although it is svn... On 6 August 2011 12:15, Kris Maglione wrote: > http://hg.suckless.org/vp is. > Last updated: 19 hours ago Just about :P
Re: [dev] [wmii] Flash in fullscreen regularly freezes screen
On 5 August 2011 17:39, Kris Maglione wrote:
> On Fri, Aug 05, 2011 at 09:31:40AM -0700, Suraj Kurapati wrote:
>> # see http://www.reddit.com/r/linux/comments/dky73/
>> lsof -p $(pgrep -f libflashplayer) | grep /tmp/Flash |
>> awk '{print "/proc/" $2 "/fd/" $4}' | sed 's/[rwu]$//' |
>> xargs mplayer -fs
>
> That's only the case for HTTP streams. RTMP streams are never written to
> disk. And there are quite a lot of cases where it automatically unlinks the
> files, in any case. Even then, you still need to let the non-fullscreen
> player buffer the things, which kind of defeats the point.
Somewhat off topic now, but http://repo.hu/projects/yget/ works fine for me
Re: [dev] [surf] segfault
Hi On 3 August 2011 22:34, Peter John Hartman wrote: > Hey, > > surf has been segfaulting about 6 seconds after loading, no matter what > site. > > ... > > Suggestions? > > Peter Surf has more or less been abandoned, you're on your own, in the forest of Webkit. Good luck. Rob
Re: [dev] [dwm] visible only if needed [patch]
On 7 July 2011 14:18, Ruben Gonzalez Arnau wrote:
> Talking about remember applications when restarting, it's possible to
> remember "terminals" too? When I restart dwm everything is okey with my
> config.h rules and each app goes to its tag, except all xterms go to tag 1,
> I think that is the normal behavior now, not sure if exist an easy
> solution. any idea?
You need to give your xterms different class names, otherwise dwm can't
distinguish between them
e.g.
xterm -class XTerm7
and
{ "XTerm7", NULL, NULL, 1 << 6, ... }
in dwm's config.h
Re: [dev] [dwm] sloppy focus
On 4 July 2011 16:14, Connor Lane Smith wrote: > But apparently opinions are split on this topic! Suppose it depends, I've been conditioned, and expect that when I move a mouse into another window, focus should go there, so much that when I'm on Windows I'll use some tweaking program to implement this. Maybe I'm just not using dwm properly, because the main time I use this focusing is when I have floating windows, so make what you will of that. Rob
Re: [dev] [dwm] segfault
Build with debug flags (-g in Makefile) Enable coredumps in your .xinitrc ulimit -c unlimited Wait until dwm segfaults $ gdb --core=path/to/core dwm > bt Voila, you've got the bug's location.
Re: [dev] Microsoft considers harmful...
Honestly, I think they have a point. Sure, they don't have a leg to stand on in this area, but look at Flash. All that allows is interaction with the mouse and keyboard + video and sound playback, but not a week goes by without yet another exploit being uncovered in it. That could just be because the guys who code flash subcontract out to a few thousand monkeys with typewriters, though. It's a shame they didn't go into more detail, at the moment it could just be FUD spreading.
Re: [dev] Experimental editor
On Fri, Jun 17, 2011 at 07:15:22AM -0800, Andrew Hills wrote: > On Fri, Jun 17, 2011 at 6:29 AM, Nick wrote: > > But if we're thinking about > > breaking from the terminal, how would remote editing work? > > Some sort of ssh piping from / to the file on the server? > > I haven't thought this through, but it's certainly a usecase > > which would be nice to cover. > scp sshfs?
Re: [dev] Re: sbase
On 16 June 2011 02:18, Connor Lane Smith wrote: > An update: I've done this, and added it to the Makefile. It's a little > simpler than doing it by concatenating all the sources, since we don't > need to worry about statics or anything. Currently sbase-box comes out > at 69K statically linked against musl, or 23K dynamically linked > against glibc. That looks much nicer than my script, actually, nicely done.
Re: [dev] Experimental editor
On 10 June 2011 08:54, Rafa Garcia Gallego wrote: > The lack of Shift+Control modifier is a serious bummer indeed. It looks like it's been decided that X is the way to go, but before any code is implemented, I thought I'd just stick my oar in - what if we were to keep to the terminal and open a connection to an X server, if available, and simply query the modifier key states when reading a key? This way we can still have a console editor, but overcome the problem of modifier keys, and not have to bother with window handling. Good idea? Hackish idea? Finally-got-rid-of-curses-and-I'm-trying-to-drag-you-all-back idea? You decide.
Re: [dev] Re: sbase
On 10 June 2011 06:55, pancake wrote: > On 10/06/2011, at 4:26, Connor Lane Smith wrote: >> No, there's no bug here; size is allocated and memset on the next line. > > Your gcc sucks. Mine reports the error here. Size is only allocated if the > or condition applies which is not something to always happen opening the > doors to use an uninitialized pointer. It's because gcc doesn't understand that eprintf will never return. Add something like __attribute__((noreturn)) to eprintf's prototype and you'll see.
Re: [dev] Re: sbase
On 10 June 2011 14:23, Rob wrote: > Anyway, I had another pop this morning and here's what I got. Also, forgot to mention, you'll need to alter true.c, false.c and tty.c so their main conforms, otherwise it won't compile.
Re: [dev] Re: sbase
On 10 June 2011 04:30, Connor Lane Smith wrote: > The only way this is going to happen is if someone writes a script > which does it automatically, by going through each utility prefixing > their main() functions (in a separate build directory), generating a > common main() which dispatches to the correct places, and then > compiles them. > > That is to say, I'm not going to change the utilities themselves, but > if someone were to write a separate 'boxing' script I'd be happy to > add it to the repo. > > Thanks, > cls I had a go at writing one last night, but it didn't work properly due to static variables and no one on here seemed to want it so I didn't bother submitting. Anyway, I had another pop this morning and here's what I got. It's a bit hackish, but to do the job properly would require a parser so yeah... Thanks, Rob. monolithic.sh Description: Bourne shell script
Re: [dev] Re: sbase
On 9 June 2011 16:06, Hiltjo Posthuma wrote:
> I like it, but what about -signalnumber (and maybe -signalname), I use
> -9 all the time :)
I was wondering whether to do that or not, it's pretty useful but
there's a fair bit more code. I'll leave it to cls to decide.
#include
#include
#include
#include
#include
#include "util.h"
#define LEN(x) (sizeof(x)/sizeof((x)[0]))
struct
{
const char *name;
int sig;
} sigs[] = {
#define SIG(n) { #n, n }
SIG(SIGHUP), SIG(SIGINT), SIG(SIGQUIT), SIG(SIGTRAP),
SIG(SIGABRT), SIG(SIGKILL), SIG(SIGUSR1), SIG(SIGSEGV),
SIG(SIGUSR2), SIG(SIGPIPE), SIG(SIGALRM), SIG(SIGTERM),
SIG(SIGCHLD), SIG(SIGCONT), SIG(SIGSTOP), SIG(SIGTSTP),
SIG(SIGTTIN), SIG(SIGTTOU), SIG(SIGWINCH)
#undef SIG
};
int num(const char *s)
{
char *end;
int n = strtol(s, &end, 0);
if(*end != '\0')
eprintf("%s: not a number\n", s);
return n;
}
int parse_sig(const char *s)
{
int i;
if('0' <= *s && *s <= '9')
return num(s);
if(strncmp(s, "SIG", 3))
for(i = 0; i < LEN(sigs); i++)
sigs[i].name += 3;
for(i = 0; i < LEN(sigs); i++)
if(!strcmp(sigs[i].name, s))
return sigs[i].sig;
eprintf("%s: invalid signal\n", s);
/* unreachable */
return -1;
}
int
main(int argc, char *argv[])
{
int sig = SIGTERM;
int i;
if(argc == 1){
usage:
eprintf("usage: %s [-s signal] [pid...]\n", argv[0]);
}
i = 1;
if(argv[i][0] == '-'){
if(!strcmp(argv[i], "-s")) {
if(++i == argc)
goto usage;
sig = parse_sig(argv[i]);
}else{
sig = parse_sig(argv[i] + 1);
}
i++;
}
if(i == argc)
eprintf("%s: not enough arguments\n", argv[0]);
for(; i < argc; i++) {
int pid = num(argv[i]);
if(kill(pid, sig) == -1)
eprintf("kill %d:", pid);
}
return 0;
}
Re: [dev] Re: sbase
On 9 June 2011 13:54, stateless wrote:
> Arrgh fucking gmail.
+1
#include
#include
#include
#include
#include "util.h"
int
main(int argc, char *argv[])
{
int sig = SIGTERM;
char c, *end;
while((c = getopt(argc, argv, "s:")) != -1)
switch(c){
case 's':
sig = strtol(optarg, &end, 0);
if(*end != '\0')
eprintf("%s: not a (signal) number\n", optarg);
break;
default:
eprintf("usage: %s [-s signal] [pid...]\n", argv[0]);
}
if(optind == argc)
eprintf("%s: not enough arguments\n", argv[0]);
for(; optind < argc; optind++) {
int pid = strtol(argv[optind], &end, 0);
if(*end != '\0')
eprintf("%s: not a number\n", argv[optind]);
if(kill(pid, sig) == -1)
eprintf("kill %d:", pid);
}
return 0;
}
Re: [dev] Re: sbase
On 9 June 2011 13:48, stateless wrote:
> Hi,
>
> Just to be on the same page and we don't start working on the same
> tools. I'll look into implementing id, kill and comm.
>
> Thanks,
> stateless
Ah man, I've just been doing kill.c myself. Lowest SLOC count makes it
into base?
#include
#include
#include
#include
#include "util.h"
int
main(int argc, char *argv[])
{
int sig = SIGTERM;
char c, *end;
while((c = getopt(argc, argv, "s:")) != -1)
switch(c){
case 's':
sig = strtol(optarg, &end, 0);
if(*end != '\0')
eprintf("%s: not a (signal) number\n", optarg);
break;
default:
eprintf("usage: %s [-s signal] [pid...]\n", argv[0]);
}
if(optind == argc)
eprintf("%s: not enough arguments\n", argv[0]);
for(; optind < argc; optind++) {
int pid = strtol(argv[optind], &end, 0);
if(*end != '\0')
eprintf("%s: not a number\n", argv[optind]);
printf("kill(%d, %d)\n", pid, sig);
if(kill(pid, sig) == -1)
eprintf("kill %d:", pid);
}
return 0;
}
kill.1
Description: Binary data
Re: [dev] ideas on suckless file manager
On 7 June 2011 15:53, Le Tian wrote: > Continuing these threads about suckless "anything" > I've been looking quite a long time for fast and lightweight file manager > for dwm. There are occasions, when u need to see or show some lovely icons. > MC and derivatives are the last resort here. I liked pcmanfm, but it just > lacks functionality. Rox-filer is nice, but then again I needed something > else. Recently I've installed Xfe, and it looks like I'm pretty happy with > it. > Xfe has decent configuration options and decent look. So I wonder, is there > any chance that we shall see a suckless file manager in the future? Does > anybody plan or think about developing it? > (Just a thought) I like rox, I used to use thunar but it stopped loading thumbnails, which is the only reason I use a file manager, so I switched. IMO, rox without all the desktop-panel extras is good enough. When not looking at thumbnails though, coreutils do the job fine.
Re: [dev] [st] Font issues
On 1 June 2011 02:00, Kurt H Maier wrote: > On Tue, May 31, 2011 at 8:54 PM, Jonathan Slark > wrote: >> It's a point though, do we need a suckless screen replacement? If you use >> dwm you don't need it but lately I've been looking into cwm/tmux instead. > > If all you're looking for is detach, dtach[1] exists. Under 1k of code. > > [1] http://dtach.sourceforge.net/ and dvtm[1] if you want multiple shells [1] http://www.brain-dump.org/projects/dvtm/
Re: [dev] suckless wget/curl
Here's one I wrote: http://github.com/jeffwar/wgetlite 26K without debugging symbols, unfortunately it doesn't statically link yet (getaddrinfo), but it'll be pretty trivial to sort it.
Re: [dev] sbase
On 23 May 2011 20:08, Bjartur Thorlacius wrote: > On 5/23/11, Rob wrote: >> Finally, I have an editor in the works, unfinished, but I plan to show >> you lot at some point though. > Interesting. More details, or show me the code. What's novel about him? Nothing novel I'm afraid, I'm still waiting for that idea, it's a stripped down vi clone and I'm planning on having the majority of the commands filter though external programs, like :s would use sed and so on. I'm busy with exams at the moment and I managed to brick the curses stuff, so I'd rather not upload until I've got it back together. On 24 May 2011 01:58, Connor Lane Smith wrote: > On 23 May 2011 19:53, Rob wrote: >> I have to hit ^D twice before eof is reported > I wonder why this behaves differently to read(). Any ideas? Guessing stdio buffering, I tried stuff like setbuf(stdin, NULL), but it was having none of it. I suppose you could drop to read(fileno(..)) but .. well.. I'm sure fread() shouldn't be doing that in the first place. >> Also rm.c > Thanks. I've modified it slightly to avoid having to get the cwd, > since that opens a can of worms. (In short, POSIX makes it literally > impossible ensure that you've got the entire path.) I'm not sure whether moving up a directory will always work, what if you're in $HOME and do rm -r /tmp/dir1 ./dir2 (assuming /tmp/dir1 isn't empty, causing the chdir) it'll change to /tmp/dir1, remove entries in there, move up to /tmp, remove dir1, then attempt to remove dir2 (i.e. /tmp/dir2) when you actually mean $HOME/dir2. >> UK, right? Up late coding even with exams, I'm impressed. > I can't help it, I think I code obsessively. :p Haha, good luck with your exams if you keep that up! On 24 May 2011 11:45, Pierre Chapuis wrote: > On Mon, 23 May 2011 11:05:55 +0100, Connor Lane Smith wrote: > I don't understand why so few people on this list are interested in > Minix3. ~5k LOC for a POSIX-compatible kernel that can run most of > the software you need on a Unix box sounds nice to me. 5K? Why has no one mentioned this before?! On 24 May 2011 12:12, Anselm R Garbe wrote: > If you want to go that route, I suggest to build the hardware yourself > as well, here is a brilliant guy who did it a couple of years ago: > > http://www.homebrewcpu.com/ Or if you don't have the time for hardware: http://www.youtube.com/watch?v=7sNge0Ywz-M Cheers, Rob.
Re: [dev] sbase
I have a gripe about the fread() business - I have to hit ^D twice
before eof is reported - the first ^D causes fread() to return non-zero,
with text I entered previously, the second ^D causes fread() to return 0.
Probably not a major problem but here's a patch if anyone's interested.
Also rm.c
I don't think it has any problems with symlinks, but I accept no
responsibility for your lost home directory, anime collection or
childhood memories. I've never ever found a use for -f, it's just a
pain having rm prompt me, so I've assumed an always present -f. Stick it
in if you're going for posix or whatever though.
One more thing, we're not bothering with the -- flag, are we?
> but I'm quite busy with exams atm.
UK, right? Up late coding even with exams, I'm impressed.
Finally, I have an editor in the works, unfinished, but I plan to show
you lot at some point though.
Cheers,
Rob.
fread.diff
Description: plain/text
/* See LICENSE file for copyright and license details. */
#include
#include
#include
#include
#include
#include
#include
#include "util.h"
int rflag = 0;
void rm(const char *);
int
main(int argc, char *argv[])
{
int i;
if(argc == 1)
eprintf("usage: %s [-r] files...\n", argv[0]);
for(i = 1; i < argc; i++) {
if(!strcmp(argv[i], "-r"))
rflag = 1;
else
rm(argv[i]);
}
return EXIT_SUCCESS;
}
void rm(const char *path)
{
if(remove(path) == -1){
if(errno == ENOTEMPTY && rflag){
DIR *d = opendir(path);
struct dirent *ent;
char prev[BUFSIZ];
if(!getcwd(prev, sizeof prev))
eprintf("getcwd:");
if(chdir(path))
eprintf("chdir %s:", path);
while((ent = readdir(d)))
if(strcmp(ent->d_name, "..") && strcmp(ent->d_name, "."))
rm(ent->d_name);
closedir(d);
if(chdir(prev) == -1)
eprintf("chdir %s:", prev);
if(remove(path) == -1)
eprintf("remove %s:", path);
}else
eprintf("remove %s:", path);
}
}
rm.1
Description: Binary data
Re: [dev] [dwm] move windows via keyboard
On 14 May 2011 12:39, ilf wrote:
> I find myself using this mouse thing for moving floating windows around. Is
> there any way to do this via keyboard?
>
> I don't need to so this pixel by pixel, but rather from corner to corner.
>
> --
> ilf
Here's what I use, it's a modified version of moveresize.c
Add something like this to config.h:
{ MODKEY|ControlMask, XK_q, jumpto, {.i = 0}},
{ MODKEY|ControlMask, XK_e, jumpto, {.i = 1}},
{ MODKEY|ControlMask, XK_a, jumpto, {.i = 2}},
{ MODKEY|ControlMask, XK_d, jumpto, {.i = 3}},
Rob.
void moveresize(const Arg *arg) {
XEvent ev;
Monitor *m = selmon;
const int *param = arg->v;
if(!(m->sel && arg && arg->v))
return;
/*
* if monitor->tag[monitor->selectedtag]->has_arrange_function
* and the selected client isn't floating...
*/
if(m->lt[m->sellt]->arrange && !m->sel->isfloating)
m->sel->isfloating = True;
resize(m->sel,
m->sel->x + param[0],
m->sel->y + param[1],
m->sel->w + param[2],
m->sel->h + param[3],
True);
arrange(m);
while(XCheckMaskEvent(dpy, EnterWindowMask, &ev));
}
void jumpto(const Arg *arg) {
Monitor *m = selmon;
XEvent ev;
if(!m->sel || !arg)
return;
{
#define LEFT (m->wx)
#define RIGHT (m->wx + m->ww - m->sel->w)
#define TOP(m->wy)
#define BOTTOM (m->wy + m->wh - m->sel->h)
struct
{
int x, y;
} jumps[] = {
{ LEFT, TOP},
{ RIGHT, TOP},
{ LEFT, BOTTOM },
{ RIGHT, BOTTOM }
};
if(!(0 <= arg->i && arg->i < LENGTH(jumps)))
return;
if(m->lt[m->sellt]->arrange && !m->sel->isfloating)
m->sel->isfloating = True;
resize(m->sel,
jumps[arg->i].x,
jumps[arg->i].y,
m->sel->w,
m->sel->h,
True);
arrange(m);
while(XCheckMaskEvent(dpy, EnterWindowMask, &ev));
}
}
Re: [dev] [PATCH] dmenu: Add commandline-options to determine Xinerama-screen
On 11 May 2011 12:39, Connor Lane Smith wrote:
> Hey Rob,
>
> I think this was caused by the given '-m' not being present. I've
> applied a patch which should fix this, since it falls back to the
> mouse if the '-m' isn't there. Could you confirm whether it works?
>
> If it doesn't it's a weird corner case (which must have existed prior
> to this patch), and we'll have to just fall back to the last monitor
> like you suggested.
>
> Thanks,
> cls
Hi again,
No joy, I'm afraid, m is -1 when the for loop finishes.
I believe the problem is with XGetWindowAttributes, can't figure it out
though, I've attached a log if anyone's interested, but for now I'll
just settle for using dmenu without the patch.
There's no problem with dmenu tip, it works fine whatever's focussed.
Cheers,
Rob.
[1][dmenu]% sleep 2; echo hi | ./dmenu
XGetWindowAttributes(dc->dpy, dw, fwa = { x=-1, y=-1, w=1, h=1 })
XTranslateCoordinates(dc->dpy, dw, fwa.root, fwa.x=-1, fwa.y=-1, x=-2, y=13, chi=0);
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 1 (X_CreateWindow)
Value in failed request: 0x0
Serial number of failed request: 65
Current serial number in output stream: 66
[1][dmenu]% sleep 2; echo hi | ./dmenu
XGetWindowAttributes(dc->dpy, dw, fwa = { x=-1, y=-1, w=1, h=1 })
XTranslateCoordinates(dc->dpy, dw, fwa.root, fwa.x=-1, fwa.y=-1, x=-2, y=13, chi=0);
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 1 (X_CreateWindow)
Value in failed request: 0x0
Serial number of failed request: 65
Current serial number in output stream: 66
Re: [dev] [PATCH] dmenu: Add commandline-options to determine Xinerama-screen
Hi, Sorry to thread-dig here, but I've had trouble with dmenu recently and traced it to this patch. The XCreateWindow call would fail because mw would be zero. I'm unsure why, but this problem only happened when Firefox or OpenOffice were focussed. Anyway, I've sorted it, the patch caused dmenu to access past the end of the info array and a quick bounds check fixes it. Thanks, Rob. diff -r d0f5c7885a5a dmenu.c --- a/dmenu.c Sun May 08 15:15:24 2011 +0100 +++ b/dmenu.c Wed May 11 02:46:22 2011 +0100 @@ -515,6 +515,8 @@ if((monitor == info[i].screen_number) || (monitor < 0 && INRECT(x, y, info[i].x_org, info[i].y_org, info[i].width, info[i].height))) break; + if(i >= n) + i = n - 1; x = info[i].x_org; y = info[i].y_org + (topbar ? 0 : info[i].height - mh); mw = info[i].width;
Re: [dev] [dwm] devilspie doesn't work
On 4 May 2011 20:59, Maciej Sobkowski wrote:
> I want to add transparency to terminal windows using transset-df. Is
> this possible to acomplish within config.h file?
This has been mentioned before on the list, generally transparency is
seen as a superfluous extra by most suckless members.
... but I had a pop at writing a patch anyway.
Add something like this to your config.h:
{ "XTerm", NULL, NULL, TAG_ANY, False, -1, trans, { .f = 0.5 } }
And apply the patch. It might not apply cleanly since I diff'd from my
heavily patched dwm, so you'll have to do some shuftying.
Rob.
--- a/dwm.c 2011-05-02 17:07:20.537676024 +0100
+++ b/dwm.c 2011-05-04 21:44:36.78819 +0100
@@ -129,6 +129,8 @@
unsigned int tags;
Bool isfloating, centre;
int monitor;
+ void (*f)(Client *, const Arg *);
+ const Arg farg;
} Rule;
/* function declarations */
@@ -295,6 +297,7 @@
#include "patches/grid.c"
#include "patches/spawnq.c"
#include "patches/shiftview.c"
+#include "patches/rule.c"
/* function implementations */
void
@@ -324,6 +327,8 @@
c->mon = m;
if(!r->centre)
centre = 0;
+if(r->f)
+ r->f(c, &r->farg);
}
}
if(ch.res_class)
void trans(Client *c, const Arg *a)
{
char buffer[64];
snprintf(buffer, sizeof buffer, "transset-df -i %ld %f", c->win, a->f);
system(buffer);
}
Re: [dev] dmenu fast grab
On 23 April 2011 14:11, Ciprian Dorin Craciun wrote:
> I've tried to apply the attached patch (and the one on the dmenu
> web-site) with both patch and git-apply, and they've both complained:
>
> Am I missing something?
Don't think so, I must've bodged the patch, give this a try.
Cheers,
Rob.
diff -r c2e77ee26371 dmenu.c
--- a/dmenu.c Fri Jan 07 18:55:00 2011 +
+++ b/dmenu.c Tue Apr 26 19:50:05 2011 +0100
@@ -66,6 +66,7 @@
int
main(int argc, char *argv[]) {
int i;
+ Bool fastgrab = False;
progname = "dmenu";
for(i = 1; i < argc; i++)
@@ -78,6 +79,8 @@
topbar = False;
else if(!strcmp(argv[i], "-i"))
fstrncmp = strncasecmp;
+ else if(!strcmp(argv[i], "-f"))
+ fastgrab = True;
else if(i == argc-1)
usage();
/* double flags */
@@ -103,7 +106,19 @@
dc = initdc();
initfont(dc, font);
readstdin();
- setup();
+
+
+ if(fastgrab)
+ setup(); /* grab X _now_ */
+
+ readstdin();
+
+ if(!fastgrab)
+ setup();
+ else
+ match(); /* need to re-match now we've read the input */
+
+
run();
return EXIT_FAILURE; /* should not reach */
@@ -536,7 +551,7 @@
void
usage(void) {
- fputs("usage: dmenu [-b] [-i] [-l lines] [-m monitor] [-p prompt] [-fn font]\n"
+ fputs("usage: dmenu [-b] [-i] [-f] [-l lines] [-m monitor] [-p prompt] [-fn font]\n"
" [-nb color] [-nf color] [-sb color] [-sf color] [-v]\n", stderr);
exit(EXIT_FAILURE);
}
