[dev] Re: [PATCH 1/1] expr.c: define __dead

2014-09-29 Thread Dimitris Papastamos
On Mon, Sep 29, 2014 at 03:07:36PM +0200, Christian Hesse wrote: > For me compilation fails with: > > expr.c:30:8: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ > before ‘void’ > __dead void error(void); > ^ > > Macro __dead is not defined on my system. This should fix it. T

Re: [dev] Re: [PATCH 1/1] expr.c: define __dead

2014-09-29 Thread Dimitris Papastamos
On Mon, Sep 29, 2014 at 03:15:54PM +0200, Christian Hesse wrote: > Dimitris Papastamos on Mon, 2014/09/29 14:12: > > On Mon, Sep 29, 2014 at 03:07:36PM +0200, Christian Hesse wrote: > > > For me compilation fails with: > > > > > > expr.c:30:8: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute_

Re: [dev] Re: [PATCH 1/1] expr.c: define __dead

2014-09-29 Thread Dimitris Papastamos
On Mon, Sep 29, 2014 at 03:26:51PM +0200, Christian Hesse wrote: > Dimitris Papastamos on Mon, 2014/09/29 14:23: > > On Mon, Sep 29, 2014 at 03:15:54PM +0200, Christian Hesse wrote: > > > Dimitris Papastamos on Mon, 2014/09/29 14:12: > > > > On Mon, Sep 29, 2014 at 03:07:36PM +0200, Christian Hes

[dev] A new FIFO based tox client

2014-09-29 Thread Dimitris Papastamos
Hi all, Me and FRIGN started working on a simple FIFO based tox client called ratox[0]. I started working on it initially because of my frustration trying to get toxic/uTox to build and run properly under OpenBSD. For those not familiar with tox, have a look at https://tox.im/. I made an initia

Re: [dev] A new FIFO based tox client

2014-09-29 Thread FRIGN
On Mon, 29 Sep 2014 20:57:51 +0100 Dimitris Papastamos wrote: > Thanks Dimitris for the great introduction! It goes without saying that the motivation to develop a new client is also more or less rooted in the quality of existing clients. While developing ratox in the last two weeks, we had lots

Re: [dev] A new FIFO based tox client

2014-09-29 Thread Lee Fallat
Hey, Good job guys. I just read the site and both your write-ups and I've got to say this seems very appealing to me. I love how the software is not reliant on vt100 terminal emulation or huge libraries. Your FIFO approach seems great as well. Keep up the good work. Looking forward to release 0.0

Re: [dev] A new FIFO based tox client

2014-09-29 Thread Nick
Sounds great, good job on this. I haven't read about Tox in any depth, so don't know how lovely or otherwise it is as a protocol. What do you folks think? Quoth FRIGN: > Based on ratox, TLH and I will work on a set of scripts/client > rather similar to hysteria[5] with tmux and other tools > (

Re: [dev] A new FIFO based tox client

2014-09-29 Thread Lee Fallat
On Mon, Sep 29, 2014 at 6:21 PM, Nick wrote: > The sort of dwm / X client I'm imagining would have a separate > program for contact list, and for each "conversation" (one window > split into input box and output). The contact list could just spawn > the conversation windows, or they could be spawn

Re: [dev] A new FIFO based tox client

2014-09-29 Thread Dimitris Papastamos
On Mon, Sep 29, 2014 at 11:21:53PM +0100, Nick wrote: > Sounds great, good job on this. I haven't read about Tox in any > depth, so don't know how lovely or otherwise it is as a protocol. > What do you folks think? I'd say pretty much sensible. The API is nice too. > Quoth FRIGN: > > Based o

Re: [dev] A new FIFO based tox client

2014-09-29 Thread FRIGN
On Mon, 29 Sep 2014 23:21:53 +0100 Nick wrote: > Sounds great, good job on this. I haven't read about Tox in any > depth, so don't know how lovely or otherwise it is as a protocol. > What do you folks think? Well, as a short comment: Tox is an emerging protocol and will have its share sooner

Re: [dev] A new FIFO based tox client

2014-09-29 Thread FRIGN
On Mon, 29 Sep 2014 23:38:47 +0100 Dimitris Papastamos wrote: > dwm with the fifo patch[0] could work fine. I generally work in tmux > that's why hysteria is done like that. Also it is mostly running on > a remote machine where I don't have X. You can tunnel your traffic > but when your machin

[dev] [sic] [PATCH] Classic Suckless config.{def,}.h configurability

2014-09-29 Thread Eric Pruitt
--- Makefile |6 +- config.def.h |8 sic.c| 10 ++ 3 files changed, 19 insertions(+), 5 deletions(-) create mode 100644 config.def.h diff --git a/Makefile b/Makefile index d77b4f2..6fdcfbb 100644 --- a/Makefile +++ b/Makefile @@ -17,7 +17,11 @@ options:

[dev] Re: [sic] [PATCH] Classic Suckless config.{def,}.h configurability

2014-09-29 Thread Eric Pruitt
On Mon, Sep 29, 2014 at 07:14:23PM -0700, Eric Pruitt wrote: > config.def.h |8 I just noticed that "%F" support in strftime is a C99 feature, and if sic is targeting C89, it should be changed to "%Y-%m-%d". Either way, this changes the time format from the original %D, but I strongly

[dev] Re: [sic] [PATCH] Classic Suckless config.{def,}.h configurability

2014-09-29 Thread Eric Pruitt
On Mon, Sep 29, 2014 at 07:31:09PM -0700, Eric Pruitt wrote: > I just noticed that "%F" support in strftime is a C99 feature, and if > sic is targeting C89, it should be changed to "%Y-%m-%d". Either way, > this changes the time format from the original %D, but I strongly favor > ISO 8601 and think

[dev] [sic] [PATCH] Treat non-option arguments as commands

2014-09-29 Thread Eric Pruitt
--- sic.1 |3 +++ sic.c | 24 +--- 2 files changed, 24 insertions(+), 3 deletions(-) diff --git a/sic.1 b/sic.1 index aba8db8..bf72026 100644 --- a/sic.1 +++ b/sic.1 @@ -12,6 +12,7 @@ sic \- simple irc client .RB [ \-k .IR pass ] .RB [ \-v ] +.RB [ commands... ] .SH

[dev] Ideas for using sic

2014-09-29 Thread Eric Pruitt
I started using sic as my IRC client, and I'd just like to share my configuration. I have a script that invokes sic in a manner similar to the following command: rlwrap ./sic -h "$IRC_HOST" | tee -a irc-logs | grcat sic.grcat With [rlwrap][1], I get familiar input handling, tee(1) gives me lo