Re: [hackers] Compiling stali

[David Phillips]

Did you read the error yourself?

Software does not output errors without reason.

[hackers] [sent] [PATCH] Change an eprintf to a die to stop child from running its own slideshow

[David Phillips]

The child thread was created because execlp will not return if successful.
The eprintf was placed after the call to execlp to catch any error, but the
child continued to return a (closed) fds[0], resulting in a second slideshow
being run by the child.

This commit fixes the issue by killing the child.
---
 sent.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sent.c b/sent.c
index fc5e389..88abe90 100644
--- a/sent.c
+++ b/sent.c
@@ -153,7 +153,7 @@ filter(int fd, const char *cmd)
close(fds[0]);
close(fds[1]);
execlp(cmd, cmd, (char *)0);
-   eprintf("execlp %s:", cmd);
+   die("execlp %s:", cmd);
}
close(fds[1]);
return fds[0];
--
2.6.2

Re: [hackers] [sent] [PATCH 2/2] replace farbfeld with libnetpbm

[Markus Teich]

FRIGN wrote:
> __You need a library to handle it__ and it's not that much of a popular format
> to justify installing a library for it.

Heyho,

like FRIGN pointed out correctly this patch would negate the effort and goal of
the switch to farbfeld. sent with farbfeld uses a separate process instead of
linking to a library and is therefore more UNIXy and sucks less. The patch won't
be merged.

--Markus

Re: [hackers] Compiling stali

[Harald Weber]

Yes I think "conflicts: 43 shift/reduce, 85 reduce/reduce" results in
"/bin/sh: 1: gen/maketab: not found"

On Fri, Dec 11, 2015 at 12:17 AM, David Phillips  wrote:
> Did you read the error yourself?
>
> Software does not output errors without reason.
>

Re: [hackers] [sent] [PATCH 2/2] replace farbfeld with libnetpbm

[FRIGN]

On Wed, 9 Dec 2015 20:56:38 -0800
Grant Mathews  wrote:

Hey Grant,

> Since the PNM/PAM format already exist as a minimal intermediate
> representation with a rich set of commandline tools to manipulate them,
> use Netpbm to handle images.

back to your desk, Grant, you've missed the purpose of farbfeld.

No, to be fair, we discussed the PAM-format at slcon2 in more than one
coffee break.
Netpbm is arguably almost more complex than BMP and not easy to handle.
We could discuss it if it was widely used, but the main point is:
__You need a library to handle it__ and it's not that much of a popular
format to justify installing a library for it. I don't know about you
guys, but I don't have libpbm installed on my computer and even though
ffmpeg for instance offers support, I might be having a hard time
finding a format ffmpeg _doesn't_ support.

You've replaced the entire farbfeld parsing code in sent with the
boilerplate "offered" by netpbm. Good job!

A question for the diligent reader: Can you read in a netpbm file
without first looking into the docs?

Cheers

FRIGN

-- 
FRIGN 

Re: [hackers] [sent] [PATCH 2/2] replace farbfeld with libnetpbm

[Grant Mathews]

On Fri, Dec 11, 2015 at 01:30:52AM +0100, Markus Teich wrote:
> sent with farbfeld uses a separate process instead of linking to a
> library and is therefore more UNIXy and sucks less.

This patch still does all the file conversion in a separate process, and
sent still uses an external library regardless of whether this patch is
merged.

I'm a big fan of process-level code reuse, but no tool is right for
every job, and sometimes a library is the correct way to go.

Aside from those points: would rewriting the patch to not use libnetpbm,
but to use the Netpbm helpers instead, be acceptable?

- Grant

Re: [hackers] [sent] [PATCH 2/2] replace farbfeld with libnetpbm

[Grant Mathews]

On Thu, Dec 10, 2015 at 04:39:49PM +0100, FRIGN wrote:
> Netpbm is arguably almost more complex than BMP and not easy to handle.

It's literally the top result when I search for the phrase "simplest
image format". I've written PPM loaders by hand in projects too small
for a makefile.

> We could discuss it if it was widely used,

Again, it's the top result for simplest image format: people use it.
dcraw uses it, it's supported by every image viewer I've ever installed,
and it shows up in enough random places that I'd consider it pretty
standard.

farbfeld is used nowhere, and sets the bar for "widely used" quite low.

> but the main point is: __You need a library to handle it__ and it's
> not that much of a popular format to justify installing a library for
> it.

You don't actually need a library for it, I'm just really lazy and the
library handles all the hard parts for me.

If the library "requirement" is the only sticking point, it'd be pretty
easy to fix that.

> I don't know about you guys, but I don't have libpbm installed on my
> computer and even though ffmpeg for instance offers support, I might
> be having a hard time finding a format ffmpeg _doesn't_ support.

I don't have farbfeld installed on my computer, and ffmpeg doesn't even
support it.

> You've replaced the entire farbfeld parsing code in sent with the
> boilerplate "offered" by netpbm. Good job!

Yes, that is not a bad thing.

> A question for the diligent reader: Can you read in a netpbm file
> without first looking into the docs?

I, uh, what? Are you proposing a format that doesn't require
explanation? Without any sort of docs (or reverse engineering), *no*
format is readable. Though, to be fair, PAM comes close: the header is
pure ASCII, and fairly self-explanatory.


Really, I just want this tool to be usable. Requiring some ridiculously
obscure image format for no reason takes this from "something I might
want to use" to "something nobody is going to use".

- Grant