> What processador do you use in your port? intel or ibm?
I'm on OS X 10.9 on an Intel Mac Pro, using LLVM + Clang.
> There was a discussion in this list sometime ago about this
> topic, and I think this was the best solution (if someone can
> find the messages ...), but I agree that if char is s
On Thu, Aug 14, 2014 at 04:38:24PM -0500, Steven Degutis wrote:
> Convenience link to the line: http://git.suckless.org/st/tree/st.c#n2315
>
> Here, techo is calling ISCONTROL(c) where c is a 'char'. But
> ISCONTROLC1 is always going to return false for a char.
This is not true, char can be signe
Convenience link to the line: http://git.suckless.org/st/tree/st.c#n2315
Here, techo is calling ISCONTROL(c) where c is a 'char'. But
ISCONTROLC1 is always going to return false for a char.
Perhaps it should test against ISCONTROLC0 instead? Or is this line
intended to use ISCONTROL for some reas
On Thu, Aug 14, 2014 at 07:16:55PM +, Ben Golding wrote:
> As you pointed out, '-ar' behaves as '-a', connecting in read-write mode
> without any warning. Using '-a -r' connects in read-only mode.
Yes I might change the command line parsing code to also accept the former.
> > > As the other u
Hi Marc,
Indeed, changing the socket perms to 777 does allow the other user to connect.
As you pointed out, '-ar' behaves as '-a', connecting in read-write mode
without any warning.
Using '-a -r' connects in read-only mode.
So now someone has tried it :)
> > As the other user, I run 'abduco -ar
Hi,
Sorry for the late reply, I'm currently busy with exams and a proof
of concept for a text editor.
> I just switched from dtach to abduco, so that I could try to share a
> session (view-only) with another user.
> Is that expected to work?
I have never tried it but in principle it should.
> I
On Thu, 14 Aug 2014 10:35:23 +0100
Dimitris Papastamos wrote:
> Must be some other BSD because iirc OpenBSD doesn't have sendfile.
> I think FreeBSD does though.
Ah, my bad. It was freebsd[0].
[0]: http://www.freebsd.org/cgi/man.cgi?query=sendfile&sektion=2
--
FRIGN
On Thu, Aug 14, 2014 at 10:57:50AM +0200, FRIGN wrote:
> ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
> int sendfile(int fd, int s, off_t offset, size_t nbytes,
> struct sf_hdtr *hdtr, off_t *sbytes, int flags);
>
> And this is just Linux and OpenBSD.
On Thu, Aug 14, 2014 at 10:57:50AM +0200, FRIGN wrote:
> On Thu, 14 Aug 2014 09:35:07 +0100
> Dimitris Papastamos wrote:
>
> Hey Dimitris,
>
> thanks for the patches you sent in earlier!
>
> > Obviously these numbers do not mean anything unless compared to
> > some other http server implementat
On Thu, 14 Aug 2014 09:52:44 +0100
Dimitris Papastamos wrote:
> One thing that needs to be fixed in the current model
> is to timeout existing connections that we have received no
> data from in a time interval.
>
> So consider the following:
>
> for i in $(seq 1 1000); do
> nc 127.0.0.1
On Thu, 14 Aug 2014 09:35:07 +0100
Dimitris Papastamos wrote:
Hey Dimitris,
thanks for the patches you sent in earlier!
> Obviously these numbers do not mean anything unless compared to
> some other http server implementation.
>
> From some quick testing that me and Hiltjo did yesterday, we fo
One thing that needs to be fixed in the current model
is to timeout existing connections that we have received no
data from in a time interval.
So consider the following:
for i in $(seq 1 1000); do
nc 127.0.0.1 &
done
This will create 1000 processes on the server, all of them
blocked on
Hi all,
I've used wrk[0] to benchmark quark over a loopback interface.
With the latest code in git we have:
$ ./wrk -t1 -c200 -d30s http://127.0.0.1
Running 30s test @ http://127.0.0.1
1 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 4.5
13 matches
Mail list logo
