Very nice!
Seems like you need to update [0] & [1].
[0] http://www.brain-dump.org/projects/dvtm/#news
[1] http://www.brain-dump.org/projects/abduco/#news
2016-01-09 9:48 GMT-02:00 Marc André Tanner :
> [ANNOUNCE] dvtm-0.15
>
> Hi,
>
> I just released dvtm-0.15, the tiling window manager for the
On Thu, Jan 14, 2016 at 11:21:00AM +0100, Kamil Cholewiński wrote:
> > It depends on your background. eprintf() and weprintf() were written by
> > Rob Pike and Kernighan and used in the book "The Practice of Programming".
>
> I see... Principle of least surprise, except it's me who should never b
> It depends on your background. eprintf() and weprintf() were written by
> Rob Pike and Kernighan and used in the book "The Practice of Programming".
I see... Principle of least surprise, except it's me who should never be
surprised. I guess the rest of us get surprised only once.
On Thu, Jan 14, 2016 at 11:01:16AM +0100, Kamil Cholewiński wrote:
> > Otherwise we can use the approach in sbase which is to have eprintf()
> > be equivalent to die() and weprintf() for just the warning version.
>
> TBH I would find this behavior extremely confusing. The established
> conventions
> Otherwise we can use the approach in sbase which is to have eprintf()
> be equivalent to die() and weprintf() for just the warning version.
TBH I would find this behavior extremely confusing. The established
conventions seem to be:
printf - format string and write to stdout
sprintf - format str
On Thu, Jan 14, 2016 at 09:02:43PM +1300, David Phillips wrote:
> 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
>
On Thu, Jan 14, 2016 at 09:02:43PM +1300, David Phillips wrote:
> 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
>
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 chi
