Re: [hackers] [sent][patch] load slide image on-demand
On Sat, Jun 04, 2016 at 05:28:31PM +0200, Markus Teich wrote:
> Hiltjo Posthuma wrote:
> > previously an image file would be opened but only ffread when advancing to
> > the slide, but when the slide was not used it gave an error:
> >
> > /usr/local/bin/2ff: failed to convert image/png
>
> Heyho Hiltjo,
>
> thanks for the patch. Unfortunately it does not work if the first slide
> contains
> an image (ffopen is only called in advance). I think it would be good to merge
> ffopen and ffread instead into a single function ffload. This makes the
> `LOADED`
> state clearer and also enforces that the fd is closed in the same function
> where
> it is opened. This ffload function should then be called in advance()
> replacing
> the ffread() calls if the image is not loaded yet and once in load() for the
> first slide if it is an image.
>
Ah yes, sorry for the oversight.
> If you want to take this new approach, go for it, otherwise I'll look into it
> myself.
>
I have attached a patch that does this, I hope you'll like it.
Also I'm not sure if we need the below code in advance(), I have removed it in
the patch:
if (slidecount > idx + 1 && slides[idx + 1].img)
ffread(slides[idx + 1].img);
if (0 < idx && slides[idx - 1].img)
ffread(slides[idx - 1].img);
That seems to preload the next and previous slide image right? A minor issue I
notice also is that images seem to flicker, it uses XPutImage directly to
xw.win. Maybe it can be replaced with a backbuffer then XCopyArea? What do you
think?
In advance() it should also not always be needed to rescale the image.
--
Kind regards,
Hiltjo
>From 97bebdcab4003f9acdfdd4bdf424449299ffd61d Mon Sep 17 00:00:00 2001
From: Hiltjo Posthuma
Date: Sat, 4 Jun 2016 21:34:25 +0200
Subject: [PATCH] merge ffread and ffopen into one function
---
sent.c | 77 +++---
1 file changed, 27 insertions(+), 50 deletions(-)
diff --git a/sent.c b/sent.c
index 05902bf..605a7c3 100644
--- a/sent.c
+++ b/sent.c
@@ -89,9 +89,8 @@ typedef struct {
const Arg arg;
} Shortcut;
-static Image *ffopen(char *filename);
static void fffree(Image *img);
-static void ffread(Image *img);
+static Image *ffread(char *filename);
static void ffprepare(Image *img);
static void ffscale(Image *img);
static void ffdraw(Image *img);
@@ -159,14 +158,27 @@ filter(int fd, const char *cmd)
return fds[0];
}
+void
+fffree(Image *img)
+{
+ free(img->buf);
+ if (img->ximg)
+ XDestroyImage(img->ximg);
+ free(img);
+}
+
Image *
-ffopen(char *filename)
+ffread(char *filename)
{
+ uint32_t y, x;
+ uint16_t *row;
+ uint8_t opac, fg_r, fg_g, fg_b, bg_r, bg_g, bg_b;
+ size_t rowlen, off, nbytes, i;
+ ssize_t count;
unsigned char hdr[16];
char *bin = NULL;
regex_t regex;
Image *img;
- size_t i;
int tmpfd, fd;
for (i = 0; i < LEN(filters); i++) {
@@ -178,13 +190,11 @@ ffopen(char *filename)
break;
}
}
-
if (!bin)
return NULL;
- if ((fd = open(filename, O_RDONLY)) < 0) {
+ if ((fd = open(filename, O_RDONLY)) < 0)
die("sent: Unable to open file %s:", filename);
- }
tmpfd = fd;
fd = filter(fd, bin);
@@ -192,10 +202,7 @@ ffopen(char *filename)
die("sent: Unable to filter %s:", filename);
close(tmpfd);
- if (read(fd, hdr, 16) != 16)
- return NULL;
-
- if (memcmp("farbfeld", hdr, 8))
+ if (read(fd, hdr, 16) != 16 || memcmp("farbfeld", hdr, 8))
return NULL;
img = calloc(1, sizeof(Image));
@@ -203,31 +210,6 @@ ffopen(char *filename)
img->bufwidth = ntohl(*(uint32_t *)&hdr[8]);
img->bufheight = ntohl(*(uint32_t *)&hdr[12]);
- return img;
-}
-
-void
-fffree(Image *img)
-{
- free(img->buf);
- if (img->ximg)
- XDestroyImage(img->ximg);
- free(img);
-}
-
-void
-ffread(Image *img)
-{
- uint32_t y, x;
- uint16_t *row;
- uint8_t opac;
- uint8_t fg_r, fg_g, fg_b, bg_r, bg_g, bg_b;
- size_t rowlen, off, nbytes;
- ssize_t count;
-
- if (img->state & LOADED)
- return;
-
if (img->buf)
free(img->buf);
/* internally the image is stored in 888 format */
@@ -237,9 +219,8 @@ ffread(Image *img)
/* scratch buffer to read row by row */
rowlen = img->bufwidth * 2 * strlen("RGBA");
row = malloc(rowlen);
- if (!row) {
+ if (!row)
die("sent: Unable to malloc buffer for image
[hackers] [sent][patch] load slide image on-demand
Hi,
>From f63134043f065eaa7ccce666160e9a05785ecd54 Mon Sep 17 00:00:00 2001
From: Hiltjo Posthuma
Date: Sat, 4 Jun 2016 16:29:07 +0200
Subject: [PATCH] load slide image on-demand
previously an image file would be opened but only ffread when advancing to
the slide, but when the slide was not used it gave an error:
/usr/local/bin/2ff: failed to convert image/png
this changes it to load the image on-demand once and "cache" it.
---
sent.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sent.c b/sent.c
index bde0de8..251524a 100644
--- a/sent.c
+++ b/sent.c
@@ -55,6 +55,7 @@ typedef struct {
unsigned int linecount;
char **lines;
Image *img;
+ char *embed;
} Slide;
/* Purely graphic info */
@@ -436,7 +437,7 @@ load(FILE *fp)
/* only make image slide if first line of a slide
starts with @ */
if (s->linecount == 0 && s->lines[0][0] == '@') {
memmove(s->lines[0], &s->lines[0][1], blen);
- s->img = ffopen(s->lines[0]);
+ s->embed = s->lines[0];
}
if (s->lines[s->linecount][0] == '\\')
@@ -458,6 +459,8 @@ advance(const Arg *arg)
if (slides[idx].img)
slides[idx].img->state &= ~(DRAWN | SCALED);
idx = new_idx;
+ if (!slides[idx].img && slides[idx].embed &&
slides[idx].embed[0])
+ slides[idx].img = ffopen(slides[idx].embed);
xdraw();
if (slidecount > idx + 1 && slides[idx + 1].img)
ffread(slides[idx + 1].img);
--
2.8.1
--
Kind regards,
Hiltjo
Re: [hackers] [dmenu] import new drw from libsl and minor fixes.
On Fri, Jun 03, 2016 at 07:42:37PM +0200, Markus Teich wrote: > Hiltjo Posthuma wrote: > > Your patch fixes the slowness for me, but we need to think of a more > > accurate > > but faster way indeed. > > Heyho, > > I plan to clean up the drw_text function some time in the future. I think it > is > possible to split the string into chunks which are drawn by the same font > respectively and then either actually draw them (expensive) or just measure > them > (cheap). However currently I don't have much spare time, so this additional > drw > patch will have to wait. > > --Markus > Fair enough, I think I'll apply it with the (temporary fix), since the current width is also less accurate and the speed trade-off is not worth it. Again: thanks for the patches! I'll also review the patch for dwm soon(tm). -- Kind regards, Hiltjo
Re: [hackers] [dmenu] import new drw from libsl and minor fixes.
On Fri, Jun 03, 2016 at 06:55:36PM +0200, Markus Teich wrote: > Hiltjo Posthuma wrote: > > I noticed a regression, dmenu seems really slow to load on my machine in the > > function readstdin(). Was the font cache behaviour removed from drw? > > Heyho, > Heya!, > that is probably because of the second change noted from readstdin(): > > I don't see how your patch fixes the slowness, since it still calculates the > actual width of every item in readstdin(). That's true, it is not the right fix for this issue atleast. > ... > I tested > drw_font_getexts instead of TEXTW, which seems to be a lot faster, but is not > as > accurate, since it doesn't account for fallback fonts if they are needed in > the > string. Please try the attached dmenu patch and let me know if the slowness > problem is fixed. > > --Markus Your patch fixes the slowness for me, but we need to think of a more accurate but faster way indeed. -- Kind regards, Hiltjo
Re: [hackers] [dwm] [PATCH] Replace str[n]cpy with strlcpy
On Thu, Jun 02, 2016 at 09:57:01PM +0200, FRIGN wrote: > Hello fellow hackers, > > I'll drop this little patch here so we finally make the switch to the > safe OpenBSD-functions for string copying. A good compromise might be using snprintf(buf, sizeof(buf), "%s", text) this is standard and functionally exactly the same as using strlcpy. I agree the strncpy functions need to go, they don't make sense in this context. Some people forget strncpy has the following properties aswell, from the OpenBSD man page: "If src is less than len characters long, it fills the remaining buffer with '\0' characters". and "strncpy() only NUL terminates the destination string when the length of the source string is less than the length parameter." -- Kind regards, Hiltjo
Re: [hackers] [dmenu] import new drw from libsl and minor fixes.
On Sun, May 22, 2016 at 10:34:30PM +0200, Markus Teich wrote:
> - extract drawitem function (code deduplication)
> - fix bug where inputw was not correctly calculated from the widest item, but
> just from the one with the longest strlen() which is not the same.
> - minor code style fixes (indentation, useless line breaks)
> ---
... snip snip ...
Hey,
I reviewed the drw patches for dmenu and it looks pretty good to me, but I
noticed a regression, dmenu seems really slow to load on my machine in the
function readstdin(). Was the font cache behaviour removed from drw?
As a test I did:
./dmenu -l 20 < dmenu.c
and it takes about 4 seconds to load. On another user his machine it took
18 seconds each time!
I have written a hacky patch to workaround the issue, it stores the value of
textw and so only calculates the width per item once, but it can probably be
done better in another way. Anyway here is the patch:
diff --git a/dmenu.c b/dmenu.c
index f802553..11710a7 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -23,12 +23,14 @@
* MAX(0, MIN((y)+(h),(r).y_org+(r).height) -
MAX((y),(r).y_org)))
#define LENGTH(X) (sizeof X / sizeof X[0])
#define TEXTW(X) (drw_fontset_getwidth(drw, (X)) + lrpad)
+#define TEXTWITEM(X) ((X)->textw = (X)->textw ? (X)->textw :
(drw_fontset_getwidth(drw, ((X)->text)) + lrpad))
/* enums */
enum { SchemeNorm, SchemeSel, SchemeOut, SchemeLast }; /* color schemes */
struct item {
char *text;
+ size_t textw;
struct item *left, *right;
int out;
};
@@ -81,10 +83,10 @@ calcoffsets(void)
n = mw - (promptw + inputw + TEXTW("<") + TEXTW(">"));
/* calculate which items will begin the next page and previous page */
for (i = 0, next = curr; next; next = next->right)
- if ((i += (lines > 0) ? bh : TEXTW(next->text)) > n)
+ if ((i += (lines > 0) ? bh : TEXTWITEM(next)) > n)
break;
for (i = 0, prev = curr; prev && prev->left; prev = prev->left)
- if ((i += (lines > 0) ? bh : TEXTW(prev->left->text)) > n)
+ if ((i += (lines > 0) ? bh : TEXTWITEM(prev->left)) > n)
break;
}
@@ -164,7 +166,7 @@ drawmenu(void)
}
x += w;
for (item = curr; item != next; item = item->right)
- x = drawitem(item, x, 0, MIN(TEXTW(item->text), mw - x
- TEXTW(">")));
+ x = drawitem(item, x, 0, MIN(TEXTWITEM(item), mw - x -
TEXTW(">")));
if (next) {
w = TEXTW(">");
drw_setscheme(drw, scheme[SchemeNorm]);
@@ -471,7 +473,7 @@ readstdin(void)
if (!(items[i].text = strdup(buf)))
die("cannot strdup %u bytes:", strlen(buf) + 1);
items[i].out = 0;
- if (inputw < (tmpmax = TEXTW(items[i].text)))
+ if (inputw < (tmpmax = TEXTWITEM(&items[i])))
inputw = tmpmax;
}
if (items)
--
Kind regards,
Hiltjo
Re: [hackers] [PATCH 4/8] drw: simplify color schemes
On Mon, May 23, 2016 at 07:40:14PM +0200, Markus Teich wrote:
> Hiltjo Posthuma wrote:
> > I'm willing to apply your unification patches to dmenu and dwm, but can you
> > make a patch for dwm/dmenu if it breaks it?
>
> Heyho Hiltjo,
>
> sorry, I don't quite get what you are referring to. If a regression with my
> patch series turns up, of course I will fix it assuming that is what you
> meant.
>
Nevermind, I did not see your dwm, dmenu and sent patches, very nice work! I'll
test those later :)
> > > -typedef struct {
> > > - Clr *fg;
> > > - Clr *bg;
> > > - Clr *border;
> > > -} ClrScheme;
> > > +enum { ColFg, ColBg, ColCount }; /* Scm index */
> > > +typedef XftColor *Scm;
> >
> > I don't like the typedef to a pointer here.
>
> I wanted to clean up the unneeded nesting, but also keep the type naming
> scheme
> (upper case letter - two lower case letters) consistent instead of just using
> `XftColor *` in the interface. I am unsure about what the level of abstraction
> should be in this non-library interface to the drw compilation unit. Could you
> provide more insight in the reasoning behind your preference?
I meant using:
typedef XftColor Scm
and *Scm.
instead of
typedef XftColor *Scm
not sure tbh, maybe it's fine as it is now.
--
Kind regards,
Hiltjo
Re: [hackers] [PATCH 4/8] drw: simplify color schemes
On Sun, May 22, 2016 at 10:29:21PM +0200, Markus Teich wrote:
> - Use simple XftColor type instead of Clr struct => No need for drw_clr_free
> function.
> - Replace ClrScheme struct with simple array of XftColor items `Scm`.
> - Add Enum with ColFg and ColBg for indexing Scm type variables.
> - Remove border color, since drw.c does never use it. dwm can still use it by
> creating a 3 element Scm.
I'm willing to apply your unification patches to dmenu and dwm, but can you
make a patch for dwm/dmenu if it breaks it?
>
> -typedef struct {
> - Clr *fg;
> - Clr *bg;
> - Clr *border;
> -} ClrScheme;
> +enum { ColFg, ColBg, ColCount }; /* Scm index */
> +typedef XftColor *Scm;
>
I don't like the typedef to a pointer here.
Kind regards,
Hiltjo
Re: [hackers] [scc] Implement proper #pragma support || sin
On Thu, May 12, 2016 at 7:29 PM, wrote: > commit c9cccba538e9870b1177ae4c57dad716e9f02185 > Author: sin > AuthorDate: Wed May 11 17:38:15 2016 +0100 > Commit: Roberto E. Vargas Caballero > CommitDate: Wed May 11 17:35:52 2016 +0200 > > Implement proper #pragma support > This patch seems to have a gaping flaw. It doesn't seem to compile on TempleOS for me.
Re: [hackers] Re: [ii] [GIGA-patchset] Hiltjo-branch
On Mon, May 9, 2016 at 7:52 PM, Nico Golde wrote: > Hi, > > This is massive, pretty exciting! > Hi and thanks! It came as a bit of a surprise to me too, but it is nice FRIGN posted it. There can be some silly commits though since it is an incremental patchset, so the changeset seems bigger than it effectively is. >> Changes include major overhauls to the internal infrastructure and >> fixing many many bugs this way. >> ii will now clean up after itself properly and be much much more >> fun and productive to work with. >> IPv6 support has been added, as well as a way to control ii over >> a UDS. >> The code received a major cleanup as well, so it's much better >> to read and will more likely receive contributions in the future. > > I'll check this out and let you guys know if I have questions regarding the > patches. I'm also in favor of moving this functionality into ii. We've been > sitting too long on external patches for ipv6 and other things that should be > universally accepted these days. > Since my branch differed over time I went a bit crazy :). Some features like the UDS support can probably be left out. For example to set up a TLS tunnel it is usually sufficient to bind to localhost (already works). >> You can imagine how much time went into this, so please check it >> out and give your feedback. > > To be honest I was a little in shock when I saw this. Some of this would have > been nice to see beforehand, I see some of the patches date back until 2014. > So bear with me when it comes to integrating this, but I'll try to be quick... > If I don't make it, that may as well be a good chance to hand of maintenance > of the project. I guess I've been pretty inactive for too long. > It is my fault, it was my intention to send the patches upstream, but I sat on the patches too long and over time it was harder for me to merge the changes back. Take your time to review it and don't hesitate to contact me (via mail or IRC). I think some of the patches attached don't apply cleanly anymore, but I can help to fix them up later. Kind regards, Hiltjo
[hackers] [scc] fix test001, uninitialized value after include
>From 9d83c63ab6557d1a7effbcb6c88cac00bc507ef2 Mon Sep 17 00:00:00 2001 From: Hiltjo Posthuma Date: Fri, 6 May 2016 22:18:53 +0200 Subject: [PATCH] fix uninitialized value after include(), fixes test001 The issue manifests after the line "#include " is parsed. The codeflow is like this: - in cpp.c calls (*bp->fun)(); - this calls include(). - in includefile() calls addinput(path); - ip->begin[0] = uninitialized - in include() its_done label next() is called. - next() checks ip->begin[0]. This is triggered when using OpenBSD with MALLOC_OPTIONS="J" set, this option fills allocated and free'd memory with junk (useful for finding this kind of issues). --- cc1/lex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cc1/lex.c b/cc1/lex.c index 3aff6d3..935cb40 100644 --- a/cc1/lex.c +++ b/cc1/lex.c @@ -30,6 +30,7 @@ allocinput(char *fname, FILE *fp) ip = xmalloc(sizeof(Input)); ip->fname = xstrdup(fname); ip->p = ip->begin = ip->line = xmalloc(INPUTSIZ); + ip->p[0] = '\0'; ip->nline = 0; ip->next = input; ip->fp = fp; @@ -89,7 +90,6 @@ ilex(char *fname) } } allocinput(fname, fp); - *input->begin = '\0'; keywords(keys, NS_KEYWORD); } -- 2.8.1
Re: [hackers] [ubase][PATCH] hwclock: [-rsw] => (-r | -s | -w) and fix flag check
On Fri, Apr 22, 2016 at 03:24:47AM +0200, Mattias Andrée wrote:
> Also in man page: [-r | -s | -w] => (-r | -s | -w)
>
> 8< ... snippity snip ...>8
>
> int
> @@ -141,7 +141,7 @@ main(int argc, char *argv[])
> else if (argc == 1)
> dev = argv[0];
>
> - if ((rflag ^ sflag ^ wflag) == 0)
> + if (rflag + sflag + wflag != 1)
> eprintf("missing or incompatible function\n");
This is not the same in behaviour. Is it intended? I think the patch makes
sense though.
Thanks for the patches,
Kind regards,
Hiltjo
Re: [hackers][farbfeld][patch] ffcrop tool.
On Fri, Apr 08, 2016 at 01:13:09PM +, ra...@openmailbox.org wrote:
> This adds a crop tool to farbfeld, the use is: ffcrop x y w h.
>
> What do you think?
Cool idea, I think farbfeld should have some useful tools included, maybe
in a separate tools/ directory or something.
Another tool I like is farbfeld-resize:
https://github.com/ender672/farbfeld-resize
Some notes inline in the patch:
> From fc0479232da65ca60119b6131a11e6aca4273d11 Mon Sep 17 00:00:00 2001
> From: rain1
> Date: Fri, 8 Apr 2016 13:08:47 +
> Subject: [PATCH] Added crop tool.
>
> ---
> Makefile | 2 +-
> ffcrop.c | 107
> +++
> 2 files changed, 108 insertions(+), 1 deletion(-)
> create mode 100644 ffcrop.c
>
> diff --git a/Makefile b/Makefile
> index 21b82d9..bf5b40f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2,7 +2,7 @@
> # See LICENSE file for copyright and license details
> include config.mk
>
> -BIN = png2ff ff2png jpg2ff ff2jpg ff2ppm
> +BIN = png2ff ff2png jpg2ff ff2jpg ff2ppm ffcrop
> SCRIPTS = 2ff
> SRC = ${BIN:=.c}
> HDR = arg.h
> diff --git a/ffcrop.c b/ffcrop.c
> new file mode 100644
> index 000..03e162c
> --- /dev/null
> +++ b/ffcrop.c
> @@ -0,0 +1,107 @@
> +/* See LICENSE file for copyright and license details. */
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +static char *argv0;
> +
> +int
> +main(int argc, char *argv[])
> +{
> + size_t rowlen;
> + uint32_t hdr[4], width, height, i, tmp32;
> + uint16_t *row;
> + uint32_t crop_x, crop_y, crop_w, crop_h;
> + size_t crop_skiplen, crop_rowlen;
> +
> + argv0 = argv[0], argc--, argv++;
> +
> + if (argc != 4) {
> + fprintf(stderr, "usage: %s x y w h\n", argv0);
> + return 1;
> + }
> +
> + crop_x = strtol(argv[0], NULL, 10);
> + crop_y = strtol(argv[1], NULL, 10);
> + crop_w = strtol(argv[2], NULL, 10);
> + crop_h = strtol(argv[3], NULL, 10);
> +
I think these need to be checked (errno and whole string is a number).
Also width and height should be > 0. Note also that strtol() parses signed
numbers and it will be cast to uint32_t.
> + /* header */
> + if (fread(hdr, sizeof(*hdr), 4, stdin) != 4) {
> + goto readerr;
> + }
> + if (memcmp("farbfeld", hdr, sizeof("farbfeld") - 1)) {
> + fprintf(stderr, "%s: invalid magic value\n", argv0);
> + return 1;
> + }
> + width = ntohl(hdr[2]);
> + height = ntohl(hdr[3]);
> +
> + /* sanitize the input sizes */
> + if (crop_x > width) {
> + crop_x = width;
> + }
> +if (crop_y > height) {
> +crop_y = height;
> +}
> + if (crop_w > width - crop_x) {
> + crop_w = width - crop_x;
> + }
> + if (crop_h > height - crop_y) {
> + crop_h = height - crop_y;
> + }
> +
Some style issues, please use TABS for indentation.
> +/* write header */
> +fputs("farbfeld", stdout);
> +tmp32 = htonl(crop_w);
> +if (fwrite(&tmp32, sizeof(uint32_t), 1, stdout) != 1)
> +goto writerr;
> +tmp32 = htonl(crop_h);
> +if (fwrite(&tmp32, sizeof(uint32_t), 1, stdout) != 1)
> +goto writerr;
> +
> + if (width > SIZE_MAX / ((sizeof("RGBA") - 1) * sizeof(uint16_t))) {
> + fprintf(stderr, "%s: row length integer overflow\n", argv0);
> + return 1;
> + }
> + rowlen = width * (sizeof("RGBA") - 1);
> + if (!(row = malloc(rowlen * sizeof(uint16_t {
> + fprintf(stderr, "%s: malloc: out of memory\n", argv0);
> + return 1;
> + }
> + crop_skiplen = crop_x * (sizeof("RGBA") - 1);
> + crop_rowlen = crop_w * (sizeof("RGBA") - 1);
> +
> + /* skip the first rows */
> + for (i = 0; i < crop_y; ++i) {
> + if (fread(row, sizeof(uint16_t), rowlen, stdin) != rowlen) {
> + goto readerr;
> + }
> + }
> + /* write rows */
> + for (i = 0; i < crop_h; ++i) {
> + if (fread(row, sizeof(uint16_t), rowlen, stdin) != rowlen) {
> + goto readerr;
> + }
> + fwrite(row + crop_skiplen, sizeof(uint16_t), crop_rowlen,
> stdout);
> + }
> +
> + return 0;
> +readerr:
> + fprintf(stderr, "%s: fread: ", argv0);
> + perror(NULL);
> +
> + return 1;
> +
> +writerr:
> + fprintf(stderr, "%s: fwrite: ", argv0);
> + perror(NULL);
> +
> + return 1;
> +}
> --
> 2.8.1
>
Kind regards,
Hiltjo
Re: [hackers] [sbase][PATCH] Move setsid to ubase
On Tue, Mar 29, 2016 at 08:41:00PM +0200, Mattias Andr??e wrote:
> Signed-off-by: Mattias Andr??e
> ---
> Makefile | 1 -
> setsid.1 | 17 -
> setsid.c | 40
> 3 files changed, 58 deletions(-)
> delete mode 100644 setsid.1
> delete mode 100644 setsid.c
>
> diff --git a/Makefile b/Makefile
> index 6b2bfdf..9944048 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -141,7 +141,6 @@ BIN =\
> rmdir\
> sed\
> seq\
> - setsid\
> sha1sum\
> sha224sum\
> sha256sum\
> diff --git a/setsid.1 b/setsid.1
> deleted file mode 100644
> index d43bcfc..000
> --- a/setsid.1
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -.Dd 2015-10-08
> -.Dt SETSID 1
> -.Os sbase
> -.Sh NAME
> -.Nm setsid
> -.Nd run a command in a new session
> -.Sh SYNOPSIS
> -.Nm
> -.Ar cmd
> -.Op Ar arg ...
> -.Sh DESCRIPTION
> -.Nm
> -runs
> -.Ar cmd
> -in a new session.
> -.Sh SEE ALSO
> -.Xr setsid 2
> diff --git a/setsid.c b/setsid.c
> deleted file mode 100644
> index 4c885a4..000
> --- a/setsid.c
> +++ /dev/null
> @@ -1,40 +0,0 @@
> -/* See LICENSE file for copyright and license details. */
> -#include
> -#include
> -
> -#include "util.h"
> -
> -static void
> -usage(void)
> -{
> - eprintf("usage: %s cmd [arg ...]\n", argv0);
> -}
> -
> -int
> -main(int argc, char *argv[])
> -{
> - int savederrno;
> -
> - argv0 = argv[0], argc--, argv++;
> -
> - if (!argc)
> - usage();
> -
> - if (getpgrp() == getpid()) {
> - switch (fork()) {
> - case -1:
> - eprintf("fork:");
> - case 0:
> - break;
> - default:
> - return 0;
> - }
> - }
> - if (setsid() < 0)
> - eprintf("setsid:");
> - execvp(argv[0], argv);
> - savederrno = errno;
> - weprintf("execvp %s:", argv[0]);
> -
> - _exit(126 + (savederrno == ENOENT));
> -}
> --
> 2.7.4
>
>
setsid is POSIX and it is portable so I don't see why it should be in ubase
(Linux-specific tools).
Can you explain your intention?
Kind regards,
Hiltjo
Re: [hackers] [ubase][PATCH v2] Add pwdx(1)
On Sat, Mar 26, 2016 at 12:58:37PM +0100, Mattias Andr??e wrote:
> +
> + for (; argc > 0; argc--, argv++) {
> + n = snprintf(path, sizeof(path), "/proc/%s/cwd", *argv);
> + if (n < 0 || n > sizeof(path)) {
> + errno = ESRCH;
The line:
> + if (n < 0 || n > sizeof(path)) {
Should be:
> + if (n < 0 || n >= sizeof(path)) {
Kind regards,
Hiltjo
Re: [hackers] [ubase][PATCH] Add pwdx(1)
On Sat, Mar 26, 2016 at 12:30:50AM +0100, Mattias Andr??e wrote:
> Signed-off-by: Mattias Andr??e
> diff --git a/pwdx.c b/pwdx.c
> new file mode 100644
> index 000..b9836b7
> --- /dev/null
> +++ b/pwdx.c
> @@ -0,0 +1,53 @@
> +/* See LICENSE file for copyright and license details. */
> +#include
> +#include
> +#include
> +#include
> +#include
> +
Sort includes.
> +#include "util.h"
> +
> +static void
> +usage(void)
> +{
> + eprintf("usage: %s pid...\n", argv0);
> +}
> +
> +int
> +main(int argc, char *argv[])
> +{
> + int ret = 0;
> + char path[sizeof("/proc//cwd") + 3 * sizeof(pid_t)];
Just use PATH_MAX here.
> + char target[PATH_MAX + sizeof(" (deleted)")];
Why + sizeof(" (deleted)") ?
> +
> + for (; argc > 0; argc--, argv++) {
> + if (strlen(*argv) > 3 * sizeof(pid_t)) {
> + fprintf(stderr, "%s: No such process\n", *argv);
> + ret = 1;
> + continue;
> + }
> + sprintf(path, "/proc/%s/cwd", *argv);
Please use snprintf here and check for -1 and truncation.
> + n = readlink(path, target, sizeof(target) - 1);
> + if (n >= 0) {
> + target[n] = '\0';
> + printf("%s: %s\n", *argv, target);
> + } else if (errno == ENOENT) {
> + fprintf(stderr, "%s: No such process\n", *argv);
> + ret = 1;
Here you can use eprintf().
> + } else {
> + perror(*argv);
> + ret = 1;
> + }
> + }
> +
> + return ret;
> +}
> --
> 2.7.3
>
>
Kind regards,
Hiltjo
Re: [hackers] dmenu][PATCH reversed
On Sat, Feb 20, 2016 at 10:28 PM, Maurycy Skier wrote: > Hi, I hope I am doing everything right. > > I added a new option (-r) which reverses the list and puts the input under > it. If you've used Vimperator or CtrlP plugin in Vim you can say it tries to > make dmenu lookalike (with -b and -l option). > Hi, You can add this to the wiki. Make sure to maintain the patch against dmenu releases. Kind regards, Hiltjo
Re: [hackers][sbase][PATCH] arg.h: fixed argv checks order
On Fri, Feb 19, 2016 at 8:43 PM, Lucas Gabriel Vuotto wrote: > this is a small fix for arg.h where it's possible to perform an > out-of-boundary memory access in argv's internal string. In particular, this > is a fix for sbase's arg.h, but I've also seen it in st repo, and I suppose > that this "bug" is present in all suckless' repo which uses arg.h . > Nice find! Kind regards, Hiltjo
Re: [hackers] [dmenu] Typofix, patches rebased
On Mon, Jan 11, 2016 at 6:29 PM, Klemens Nanni wrote: > Hey, > Hi! > cc596365a (unbolify dmenu) "breaks" some of the patches provided at > tools.suckless.org/dmenu/patches. Basically 's,bool,int' was all I had > to do besides some offset correction. Since this is the first time I'm > dealing with dmenu's source I do not guarantee anything, but it compiles > fine, though. Making them apply without errors ontop of latest git was > all I did, no changes in functionality or whatsoever. > Thanks, I'll apply the typofix later to upstream dmenu, you can push the other patches to the wiki. A small note: try to keep the code-style neat / consistent. Kind regards, Hiltjo
Re: [hackers] [dmenu][RFC][PATCH 0/4] Using sort and simple C program to get dmenu history functionality
On Mon, Nov 30, 2015 at 3:28 PM, Silvan Jegen wrote:
> Heyho!
>
> On Sat, Nov 28, 2015 at 11:25 PM, Hiltjo Posthuma
> wrote:
>> On Fri, Nov 27, 2015 at 7:38 PM, Silvan Jegen wrote:
>> This can be implemented in a few lines of shell (wc, sort) and maybe awk.
>
> I *have* implemented the history part with sort. If you think the
> history updating functionality that I ended up writing in C can be
> (easily?) implemented in some shell script and/or awk then I would
> like to see it on the list :)
>
Something like (quick hack):
cat historyfile | awk '//{x[$0]++; } END { for (k in x) { print x[k] "
" k; }}' | sort -k 1rn,2 | cut -f 2- | dmenu >> historyfile
> I thought it should be possible to implement in awk but because you
> have to both read input from stdin (the command) and from a file (the
> history file) I couldn't figure it out in the admittedly short time I
> kept trying to do it.
>
The input is read from X, not stdin, but if you mean additional input
apart from the history file you can append it and probably use some
kind of "weights" (like used count), then after it use sort like
above.
Kind regards,
Hiltjo
Re: [hackers] [dmenu][RFC][PATCH 0/4] Using sort and simple C program to get dmenu history functionality
On Fri, Nov 27, 2015 at 7:38 PM, Silvan Jegen wrote: > Heyhey > > I kept thinking about a more general way to implement history > functionality for dmenu and this is what I came up with. > > We use the sort command to generate an input list for dmenu sorted by > count (first patch). dmenu itself is not modified and shows the available > commands with the most often used ones first (due to the sorting done > by sort). Before sending the dmenu output to a shell we use a simple > C program that reads a command from stdin for which it increments the > usage count in the history file before sending the command to the shell > to execute (patch 4; rest of the patches are just glue code). > This can be implemented in a few lines of shell (wc, sort) and maybe awk. > > * It uses the -t and -k options of sort which are not available for > all sort implementations (not in sbase for example). If there is an > easy way to replicate this functionality without using these sort > options I would like to hear about it. Sbase sort supports -t and -k, if some part of it is broken: send a patch.
Re: [hackers] [sent] drw.c: Avoid potential memory leak in drw_cur_create()
On Wed, Nov 18, 2015 at 10:54 PM, Markus Teich wrote: > The drw code of sent diverged from the drw code of dmenu/dwm/… a couple of > months ago. I submitted my changes earlier this year, they were never merged > into upstream libdrw. Now we have two different histories and should probably > try to merge them again as soon as possible. I don't know, when I will have > time > to do it, so volunteers are welcome. > > --Markus > I did not merge the changes because I was working on improving the drw code at the time and some changes would conflict or not be relevant anymore. I'd definitely be interested in unifying and bringing some of the fixes back into dwm/dmenu libdraw. It is probably best to take the fixes and cleanups from dwm/dmenu and sync them into sent. Kind regards, Hiltjo
Re: [hackers] [dmenu] Command History Patch
On Fri, Nov 20, 2015 at 7:04 AM, Stephen Sherratt wrote: > I made a patch to add suggestions to dmenu based on previously run commands. > I know there already exists such a patch > (http://tools.suckless.org/dmenu/patches/history) but it seems to be quite > old and doesn't work with the latest version of dmenu. It stores history in > a text file at a specified location. > > I've attached the patch. Feedback is welcome! To be honest this can be solved in a simpler way with some shell and/or awk wrapper. Implementing it in C at this level is sucky in my opinion. Kind regards, Hiltjo
Re: [hackers] [dwm] setfullscreen: don't process the property twice
On Thu, Nov 5, 2015 at 2:39 PM, Alexander Huemer wrote: > Hi, > > this patch solved an inconvenience for me regarding at least mpv and > firefox. > In case there are no strong objections I recommend to mainline it. > > Kind regards, > -Alex^Wblackbit Can you explain in some greater detail what issue it fixes exactly for firefox and mpv, preferably with some steps to reproduce the issue? Kind regards, Hiltjo
Re: [hackers] [dmenu] paste fix
On Sun, Oct 4, 2015 at 6:22 PM, shua lloret wrote: > You should change the website if git diff is not the correct way to create > patches. > > http://dwm.suckless.org/patches/ > http://surf.suckless.org/patches/ > http://tools.suckless.org/dmenu/patches/ > http://tools.suckless.org/ii/patches/ > http://tools.suckless.org/sic/patches/ > http://tools.suckless.org/tabbed/patches/ > It is correct to use if it's a (feature) patch for the wiki. For patches against the current code it is encouraged to use format-patch so they can be applied directly (with git am). I'll update the wiki soon (hacking.md). Kind regards, Hiltjo
Re: [hackers] [dmenu] Fix incorrect ordering of matching results
On Fri, Aug 14, 2015 at 6:28 PM, Davide Del Zompo wrote: > dmenu incorrectly orders matching results: > > $ dmenu < suck xless > suck less > EOF > > Typing 'suck less' shows 'suck xless' as first result, however, according to a > comment in the source code, this is not the intended behaviour: > /* exact matches go first, then prefixes, then substrings */ > > The attached patch should fix the problem. Regarding the third argument to > fstrncmp: assuming fstrncmp, whatever it points to, behaves as strncmp (i.e. > "characters that follow a null byte are not compared"), both 'strlen(text) + > 1' > and 'strlen(item->text) + 1' should be safe. Hi, Better late than never, I have applied your patch with a minor optimization (textsize). Additionally I have modified the git author name to be less funky (sorry). Kind regards, Hiltjo
Re: [hackers] [dmenu] paste fix
On Sat, Oct 3, 2015 at 3:09 AM, shua lloret wrote: > attached is a small patch to enable pasting from clipboard, as well as > primary. > > It seems like there was already code in there to allow this, but since there > was never any case to match the upper case 'Y', that inline if would always > evaluate to false. > > -Joshua Lloret Hi, thanks for the patch! Looking at the history it was actually broken for a long time. A minor thing: can you provide the patch next time using git format-patch? This way the commit message and author name is retained. I have commited and pushed the changes. Kind regards, Hiltjo
Re: [hackers] Created od, with improvements suggested by FRIGN
On Tue, Sep 29, 2015 at 8:41 PM, Greg Reagle wrote: > My two patches combined with FRIGN's feedback. See attached. > Nice work!
Re: [hackers] [dmenu] add a new dmenu option to trigger immediately when theres a single option left
On Sun, Aug 30, 2015 at 2:57 PM, Michael Stummvoll wrote: > From 12b254047d5f4fe0c254a3e686a36965ff50a266 Mon Sep 17 00:00:00 2001 > From: Michael Stummvoll > Date: Sun, 30 Aug 2015 14:49:51 +0200 > Subject: [PATCH] Introduce instant match option > > with the instant match option, dmenu will close as soon as there is a > distinct match for the current input. > > The default behavior will be defined in the config.def.h with the > instant option. The -n flag will toggle the default behavior. > --- Hi, The patch seems garbled / linewrapped to me. I won't add this feature to upstream dmenu though, feel free to upload this to the suckless site however: http://git.suckless.org/sites/tree/tools.suckless.org/dmenu/patches Kind regards, HIltjo
Re: [hackers] [dmenu] [PATCH] Typo Patch
On Thu, Aug 6, 2015 at 4:20 AM, Eric Pruitt wrote: > This patch fixes a typo in dmenu. > Hi! Applied! Thanks for the patch. Kind regards, Hiltjo
Re: [hackers] [scc][patch] fix build + some whitespace fixes
On Fri, Jul 17, 2015 at 8:34 PM, Eric Pruitt wrote:
>
> You forgot the attachments.
Lol, sorry, again:
patch 1: whitespace fixes
patch 2: make fp of type FILE * and use needed includes
patch 3: fix missing ;
From fdcb684addcb71b6067b6668bd0e723277e22544 Mon Sep 17 00:00:00 2001
From: Hiltjo Posthuma
Date: Fri, 17 Jul 2015 20:28:56 +0200
Subject: [PATCH 1/3] whitespace fixes
---
cc1/cc1.h | 1 -
cc1/cpp.c | 26 +-
2 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/cc1/cc1.h b/cc1/cc1.h
index 7095cf2..6a9d9aa 100644
--- a/cc1/cc1.h
+++ b/cc1/cc1.h
@@ -13,7 +13,6 @@ typedef struct caselist Caselist;
typedef struct node Node;
typedef struct input Input;
-
struct type {
unsigned char op; /* type builder operator */
unsigned char ns;
diff --git a/cc1/cpp.c b/cc1/cpp.c
index 534585a..3e10e2e 100644
--- a/cc1/cpp.c
+++ b/cc1/cpp.c
@@ -59,17 +59,17 @@ icpp(void)
static void
nextcpp(void)
{
-next();
-if (yytoken == EOFTOK)
+ next();
+ if (yytoken == EOFTOK)
error("unterminated argument list invoking macro \"%s\"",
- macroname);
-if (yylen + 1 > arglen)
-error("argument overflow invoking macro \"%s\"",
- macroname);
-memcpy(argp, yytext, yylen);
-argp += yylen;
-*argp++ = ' ';
-arglen -= yylen + 1;
+ macroname);
+ if (yylen + 1 > arglen)
+ error("argument overflow invoking macro \"%s\"",
+ macroname);
+ memcpy(argp, yytext, yylen);
+ argp += yylen;
+ *argp++ = ' ';
+ arglen -= yylen + 1;
}
static void
@@ -171,7 +171,7 @@ copymacro(char *bp, char *s, size_t bufsiz, char *arglist[])
s += 2;
}
}
-*bp = '\0';
+ *bp = '\0';
return;
@@ -201,8 +201,8 @@ expand(char *begin, Symbol *sym)
macroname = sym->name;
if (!parsepars(arguments, arglist, atoi(s)))
return 0;
-for (n = 0; n < atoi(s); ++n)
-fprintf(stderr, "PAR%d:%s\n", n, arglist[n]);
+ for (n = 0; n < atoi(s); ++n)
+ fprintf(stderr, "PAR%d:%s\n", n, arglist[n]);
copymacro(buffer, s+3, INPUTSIZ-1, arglist);
--
2.3.0
From 88eb60a95be178120f204bc80d6a011cece4522b Mon Sep 17 00:00:00 2001
From: Hiltjo Posthuma
Date: Fri, 17 Jul 2015 20:29:28 +0200
Subject: [PATCH 2/3] make fp of type FILE * and use needed includes
---
cc1/cc1.h| 2 +-
cc1/decl.c | 1 +
cc1/symbol.c | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/cc1/cc1.h b/cc1/cc1.h
index 6a9d9aa..5a18e21 100644
--- a/cc1/cc1.h
+++ b/cc1/cc1.h
@@ -73,7 +73,7 @@ struct yystype {
struct input {
char *fname;
- void *fp;
+ FILE *fp;
char *line, *begin, *p;
struct input *next;
unsigned short nline;
diff --git a/cc1/decl.c b/cc1/decl.c
index 9d6ff98..ded6ee4 100644
--- a/cc1/decl.c
+++ b/cc1/decl.c
@@ -1,6 +1,7 @@
#include
#include
+#include
#include
#include "../inc/sizes.h"
diff --git a/cc1/symbol.c b/cc1/symbol.c
index 57eb7ac..c869cd6 100644
--- a/cc1/symbol.c
+++ b/cc1/symbol.c
@@ -1,5 +1,6 @@
#include
+#include
#include
#include
--
2.3.0
From a81a19be94c21fffa5b92aeb6bd484f50f5e62c0 Mon Sep 17 00:00:00 2001
From: Hiltjo Posthuma
Date: Fri, 17 Jul 2015 20:29:58 +0200
Subject: [PATCH 3/3] fix missing ;
---
cc1/cpp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cc1/cpp.c b/cc1/cpp.c
index 3e10e2e..4df8244 100644
--- a/cc1/cpp.c
+++ b/cc1/cpp.c
@@ -447,7 +447,7 @@ ifclause(int isdef)
if (cppctx == NR_COND-1)
error("too much nesting levels of conditional inclusion");
- n = cppctx++
+ n = cppctx++;
if (yytoken != IDEN) {
error("no macro name given in #%s directive",
(isdef) ? "ifdef" : "ifndef");
--
2.3.0
[hackers] [scc][patch] fix build + some whitespace fixes
Hi, patch 1: whitespace fixes patch 2: make fp of type FILE * and use needed includes patch 3: fix missing ; Kind regards, Hiltjo
[hackers] [patch][scc] fix parsing end of comment
Hi,
This patch fixes parsing the end of a comment, there was a missing ;
Kind regards,
Hiltjo
From 2dc0d42b51973d0e9106a2fd487d9f485178ac34 Mon Sep 17 00:00:00 2001
From: Hiltjo Posthuma
Date: Wed, 15 Jul 2015 22:34:42 +0200
Subject: [PATCH] lex: fix parsing end of comment
---
cc1/lex.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cc1/lex.c b/cc1/lex.c
index c35e401..111c6f8 100644
--- a/cc1/lex.c
+++ b/cc1/lex.c
@@ -184,8 +184,8 @@ comment(char type)
{
if (type == '*') {
while (!eof) {
- while (readchar() != '*' && !eof)
- /* nothing */
+ while (readchar() != '*' && !eof)
+ /* nothing */;
if (readchar() == '/')
break;
}
--
2.3.0
[hackers] [patch][scc] minor fixes (whitespace and such)
Hi,
Just some minor fixes (whitespace and such).
Kind regards,
Hiltjo
From c79b4339fc477e2d0212d442f38c50326e430f2a Mon Sep 17 00:00:00 2001
From: Hiltjo Posthuma
Date: Wed, 15 Jul 2015 21:37:32 +0200
Subject: [PATCH] whitespace + typo fixes
change exit(-1) to exit(1), just use 1 instead of EXIT_FAILURE
---
README | 4 ++--
cc1/cpp.c| 2 +-
cc1/error.c | 4 ++--
cc1/lex.c| 2 +-
cc2/main.c | 2 +-
cc2/optm.c | 2 +-
cc2/parser.c | 2 +-
lib/die.c| 2 +-
8 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/README b/README
index a4c9337..a99676a 100644
--- a/README
+++ b/README
@@ -23,8 +23,8 @@ friends).
This is the reason why I begin to develop this compiler, and I hope
it will be useful for you.
-Changes from standar C
-==
+Changes from standard C
+===
This compiler is near of being full compatible with C99 standard, but
it has some differences:
diff --git a/cc1/cpp.c b/cc1/cpp.c
index 13ec31b..8552f80 100644
--- a/cc1/cpp.c
+++ b/cc1/cpp.c
@@ -534,7 +534,7 @@ usererr(char *s)
if (cppoff)
return;
printerr("#error %s", s);
- exit(-1);
+ exit(1);
}
static void
diff --git a/cc1/error.c b/cc1/error.c
index 2160c3a..68880d1 100644
--- a/cc1/error.c
+++ b/cc1/error.c
@@ -25,7 +25,7 @@ warn_helper(int flag, char *fmt, va_list va)
putc('\n', stderr);
if (flag < 0 && nerrors++ == MAXERRNUM) {
fputs("too many errors\n", stderr);
- exit(-1);
+ exit(1);
}
}
@@ -62,6 +62,6 @@ printerr(char *fmt, ...)
void
unexpected(void)
-{
+{
error("unexpected '%s'", yytext);
}
diff --git a/cc1/lex.c b/cc1/lex.c
index 26d9b14..c35e401 100644
--- a/cc1/lex.c
+++ b/cc1/lex.c
@@ -651,7 +651,7 @@ discard(void)
break;
}
if (c == '\0' && !moreinput())
- exit(-1);
+ exit(1);
}
jump:
yytoken = c;
diff --git a/cc2/main.c b/cc2/main.c
index 846f81e..3aec235 100644
--- a/cc2/main.c
+++ b/cc2/main.c
@@ -22,7 +22,7 @@ error(unsigned nerror, ...)
vfprintf(stderr, errlist[nerror], va);
va_end(va);
putc('\n', stderr);
- exit(EXIT_FAILURE);
+ exit(1);
}
bool
diff --git a/cc2/optm.c b/cc2/optm.c
index f755023..83a634a 100644
--- a/cc2/optm.c
+++ b/cc2/optm.c
@@ -34,7 +34,7 @@ repeat:
np->left = optcasts(np->left, tp);
np->right = optcasts(np->right, tp);
- return np;
+ return np;
}
static Node *
diff --git a/cc2/parser.c b/cc2/parser.c
index cfdff4b..99f9d8d 100644
--- a/cc2/parser.c
+++ b/cc2/parser.c
@@ -464,7 +464,7 @@ oreturn(char *token)
if (token = strtok(NULL, "\t")) {
expr(token);
lp = pop();
- np ->left = lp;
+ np->left = lp;
np->type = lp->type;
} else {
np->left = NULL;
diff --git a/lib/die.c b/lib/die.c
index 6752848..974dd2c 100644
--- a/lib/die.c
+++ b/lib/die.c
@@ -16,5 +16,5 @@ die(const char *fmt, ...)
va_start(va, fmt);
fprintf(stderr, fmt, va);
va_end(va);
- exit(EXIT_FAILURE);
+ exit(1);
}
--
2.3.0
Re: [hackers] [st] [5 PATCHES] Code layout changes
On Wed, Jul 8, 2015 at 8:45 PM, FRIGN wrote: > Good evening everybody! > > I've taken a look at st today and made some changes that have proven to > improve the code while working on sbase and ubase in the last few months. > > These patches imply layout and style changes in most places of the code, > so before you grab your pitchforks and torches: > The patches on the wiki are broken for git HEAD anyway. The next thing on > my list is to go through _all_ patches on the wiki and make releases for > 0.6, which has been tagged yesterday, and git HEAD preferrably after these > patches have been merged. > > I know about the clause in the suckless style guide: The project's style > has precedence. Nevertheless, I think it's only beneficial to have a > consistent style across the multiple projects we have and most importantly > across a single project in particular. > I once read that suckless is indeed popular for some people because of our > great "brain dead C dialect", thus I think it's a step in the right direction > to make this dialect even more solid. I agree. I think code consistency and clarity is very important aswell. > > Now is the best time to merge style changes like this, one day after the > latest > version has been tagged. This gives us (and especially me) enough time to take > care of the wiki-patches. > > Please let me know what you think about it! > Nice work, this is indeed probably a good time to do these changes. > Cheers > Kind regards, Hiltjo
Re: [hackers] Re: [dmenu] Use libsl/libdraw code and add Xft support
On Sat, Jun 27, 2015 at 9:50 PM, Anselm R Garbe wrote: > > You are very welcome to take over libsl+dmenu. But I'd like to keep > the dwm maintainership, though all plans back from 2013 are still > valid. If you keep working on libsl+dmenu, I'd be willing to > adopt/adjust dwm accordingly for the next 6.1 release. > Awesome! I have some (small) changes for libsl and dmenu in queue. I will post it within a few days. Can you provide the permissions and PM the details to push to dmenu (and libsl)? Kind regards, Hiltjo
Re: [hackers] Re: [dmenu] Use libsl/libdraw code and add Xft support
On Sat, Jun 13, 2015 at 11:51 AM, Dimitris Papastamos wrote: > > Works well for me. > > Anselm, can we merge this? > Bump. Can this get merged to master? I'd be willing to take over maintainership for dwm and dmenu if the current maintainer(s) don't have the time or energy to do it. Also I'd like to improve libdraw/libsl as was the intention as discussed on Slcon 2013. Kind regards, Hiltjo
[hackers] Re: [dmenu] Use libsl/libdraw code and add Xft support
On Mon, Jun 8, 2015 at 11:48 PM, Hiltjo Posthuma wrote:
> On Mon, Jun 8, 2015 at 11:05 PM, Hiltjo Posthuma
> wrote:
>> ... snip ...
>>
>
Some more thoughts: in drw.c these functions don't check if drw ==
NULL before use: drw_load_fonts, drw_font_xcreate.
We should probably not check these in drw.c and let the program using
drw error out at drw_create(). If an invalid context is passed it
should just crash. This would make spotting errors regarding drw.{c,h}
simpler aswell.
Kind regards,
Hiltjo
[hackers] Re: [dmenu] Use libsl/libdraw code and add Xft support
On Mon, Jun 8, 2015 at 11:05 PM, Hiltjo Posthuma wrote: > ... snip ... > I forgot to mention I also changed the odd case in drw_cur_create where if you pass NULL for drw it would allocate memory but never expose it and return NULL (possible leak): http://git.suckless.org/dwm/tree/drw.c#n397 . Also on OpenBSD I got a warning for a possible case for uninitialised variable in drw.c drw_text(): XftDraw *d . I looked into this, but I think this is a false positive and didn't change it.
[hackers] [dmenu] Use libsl/libdraw code and add Xft support
Hi guys,
This is a resend of the patch to add Xft support to upstream dmenu.
There was some stray whitespace in the previous patch which I fixed.
Based on the work of libsl I have modified dmenu to use the new
libsl/libdraw code which adds Xft and fallback-fonts support aswell.
Addtionally I fixed a few oddities in libsl which were mentioned on
this ML by Markus Teich and Eric Pruitt before.
- libdraw, util: add drw.{c,h}, util.{c,h} and update code.
- libdraw: fix drw_rect(): use w and h parameter.
- libdraw: die(): print errstr if last character in string was ":" (sbase).
- libdraw: drw_clr_free: allow valid free(NULL).
- config.def.h: set default font to monospace.
- cleanup() on exit.
- LICENSE: update license string for dmenu -v to 2015.
- LICENSE: add myself to LICENSE
Considering this is a big change it would be very welcome if people
would review this and give feedback.
Kind regards,
Hiltjo
0001-Use-libdraw-add-Xft-and-fallback-fonts-support-to-gr.patch
Description: Binary data
Re: [hackers] [sbase] config.mk: make cc the default $CC || Hiltjo Posthuma
On Tue, Nov 11, 2014 at 11:05 AM, Dimitris Papastamos wrote: > > I agree on this, I think Hiltjo had some trouble because it > was defaulting to "c99" as opposed to "cc" and that did not > exist on his system. > > Hiltjo, can you clarify again? > Yeah that was my problem. ".POSIX:" in the Makefile specifies c99 is the default $CC[0]. That said I'll just fix my system. Feel free to revert this commit. [0]: http://pubs.opengroup.org/onlinepubs/007904975/utilities/make.html
