On Monday 16 July 2007 14:06:57 Garrett Cooper wrote:
> I ran some tests and I noticed a large difference in the cumulative
> sums of fwrite(2) vs write(3) and fread(2) vs read(3) (3-fold
> differences on a real machine).
This difference is at least partially explained when looking
at /usr/in
On Tuesday 17 July 2007 02:46:07 [EMAIL PROTECTED] wrote:
> Yeah, that's what I meant. I was rather tired when I made that post
> at 5:30 this morning. Heh. Thank you for the additional info though. That
> was brief, but comprehensive :). -Garrett
For more comprehensive info, "check the (POS
On Wednesday 18 July 2007 04:36:08 Eric Anderson wrote:
> On 07/17/07 20:04, Rogelio Bastardo wrote:
> > Might there be some sort of BSD version of SELinux going on here? No
> > one has any info on what "changed" on the box to make it not work.
> > I've never had this problem on Cacti on the other
Could the admin of mx.kash.tomsk.ru (presumably, he's reading this list)
please turn off "reposts" for mails delivered to him/her via this list? The
address the mail is getting delivered to (and which reinjects it
for [EMAIL PROTECTED] and possibly other mail addresses, in the case of the
mail
Hey all!
I'm currently trying to implement (and use) a C++ member function template,
but GCC won't eat the code I feed it.
The problem is most probably related to the fact that the group of member
functions is only discriminated by return type (i.e., the template parameter
defines the return t
Am Donnerstag, 27. Dezember 2007 16:42:29 schrieb Erich Dollansky:
> Hi,
>
> Heiko Wundram (Beenic) wrote:
> > The problem is most probably related to the fact that the group of member
> > functions is only discriminated by return type (i.e., the template
> > parame
Am Donnerstag, 27. Dezember 2007 17:15:50 schrieb Erich Dollansky:
> wasn't your question that you have a class with several member functions
> which would all be identical except of the return type?
No, that's perfectly clear that that won't work. My question was about a
templated member functio
Am Mittwoch, 9. Januar 2008 10:29:43 schrieb Joshua Isom:
> Why not try to take out some user processes? Going with a combination
> of process priority and memory usage, it should at least be more
> tolerable than a panic.
Ahemm. No. That's not tolerable in real world conditions. Have you ever ha
Hey all!
I'm currently in the need to get the protocol family that was used to create a
socket (and passed via a unix domain socket to another program), and I've not
really come up with a proper scheme other than to use getsockname and
retrieve sa_family from the resulting socket (which current
Am Donnerstag, 31. Januar 2008 10:03:22 schrieb Julian Elischer:
> I'm having to use mercurial.
> I'm not really enjoying it.
> works ok for small projects. BSD is a bit big for it.
> doe work foe offline editing, but loses all your BSD history.
We're using mercurial pretty much for all of our (10
Am Donnerstag, 31. Januar 2008 16:31:32 schrieben Sie:
> "Heiko Wundram (Beenic)" <[EMAIL PROTECTED]> writes:
> > I'm currently in the need to get the protocol family that was used to
> > create a socket (and passed via a unix domain socket to another
> >
Am Donnerstag, 31. Januar 2008 17:50:20 schrieb Dag-Erling Smørgrav:
> "Heiko Wundram (Beenic)" <[EMAIL PROTECTED]> writes:
> > Currently, you're basically required to do a getsockname to a struct
> > sockaddr_storage and typecast that to the actual socket ad
Am Freitag, 1. Februar 2008 14:07:48 schrieb Dag-Erling Smørgrav:
> "Heiko Wundram (Beenic)" <[EMAIL PROTECTED]> writes:
> > At the moment, there are two different kinds of connections being
> > handled by front-end plugins (which basically accept on a listeni
Hey all!
Before I go post this as a PR (or go about fixing the libc code), I just
wanted to ask whether this is a known issue (and I simply haven't been able
to find it), or if it's simply my stupidity that makes this fail.
Basically, I have the following code:
addrinfo hints;
addrinfo* res;
Am Montag, 18. Februar 2008 09:53:23 schrieb Ulrich Spoerlein:
> When will mere mortals like us get a chance to play with it? I found
> valgrind _very_ useful back in the 5.x and 6.x days.
I just wanted to say that I'd also be very interested in testing it out (if
you need testers for it), becaus
Am Montag, 18. Februar 2008 12:50:36 schrieben Sie:
> The ports version is a little outdated, but it works fine on i386. What
> peter@ and phk@ are doing in p4 is to port a newer version to FreeBSD
> and add amd64 support. Hopefully, the upstream vendor will adopt those
> patches so it doesn't ha
Hey all!
I'm currently working on a project using zlib and bzlib, and I'm currently
slightly stomped by the fact that both define the input buffer in their
stream structure as non-const. Generally, I'd assume that the input buffer is
never changed (by any of the compression/decompression functi
Am Freitag, 22. Februar 2008 11:28:42 schrieb Sharad Chandra:
> Does usleep work for you? i just saw it is implemented over nanosleep
> which passes a struct timeval to "select".
Quoting from POSIX:
"""
The usleep() function will cause the calling thread to be suspended from
execution unti
Am Montag, 25. Februar 2008 10:10:56 schrieb Sharad Chandra:
> So does it mean, freebsd has limitation. sleeping will only work for its
> value more than 1 milli sec because % of +- error value is comparitivly
> low? I am curious to know, is there any method which sleeps for few
> microseconds. Som
Am Montag, 25. Februar 2008 11:45:02 schrieb Sharad Chandra:
> I got out-of-order captured packets on my starfire dual port card ie ack
> get lower time-stamp than its corresponding seq in tcp traffic. I don't
> have much nic card level knowledge, so decided to produce delay to send ack
> and incre
Am Montag, 25. Februar 2008 14:15:46 schrieb Robert Woolley:
> On Mon, 25 Feb 2008 10:39:59 +0100
> "Heiko Wundram (Beenic)" <[EMAIL PROTECTED]> wrote:
> > Am Montag, 25. Februar 2008 10:10:56 schrieb Sharad Chandra:
> > > So does it mean, freebsd has limitati
21 matches
Mail list logo
