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
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 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 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
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 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
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
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 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
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 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 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
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 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
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 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
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
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
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
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 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
21 matches
Mail list logo
