On Mon, Dec 12, 2011 at 5:54 AM, David Coppa wrote:
> While working on enabling upnp/natpmp support into net/mldonkey,
> I've found we miss pthread_mutex_timedlock().
>
> For now I've the diff below, which is ripped/adapted from xine-lib,
> and it seems to do the trick...
>
> Would it be useful to
updating regress tests, i've noticed that some of the optimizer
tests are failing with additional (unoptimized) rules popping out.
digging deeper has shown that is indeed a bug introduced by af-to
(sorry!). the fix is simple though.
ok?
Index: parse.y
On 2011/12/12 20:14, Alexandre Ratchov wrote:
> By default sndiod (aka aucat) uses 2940 frame blocks at 44.1kHz, iirc
> to please uaudio, but this is not required anymore. On the other hand,
> programs that use audio block rate for synchronization (ex. mplayer)
> need smaller blocks (ex. to get smo
[demime 1.01d removed an attachment of type image/jpeg which had a name of
entumecimiento.jpg]
[demime 1.01d removed an attachment of type image/jpeg which had a name of
tmenopausia.jpg]
On Thu, Dec 08, 2011 at 07:34:16PM +0100, Mike Belopuhov wrote:
> patches for portable openssh should go to the portable openssh mailing lists:
> http://mindrot.org/portable-openssh.html
> (you can't apply them to openbsd source tree)
>
> and you should probably use unified diffs (diff -up).
Here
By default sndiod (aka aucat) uses 2940 frame blocks at 44.1kHz, iirc
to please uaudio, but this is not required anymore. On the other hand,
programs that use audio block rate for synchronization (ex. mplayer)
need smaller blocks (ex. to get smooth video).
If you're using sndiod (or aucat, if you
On Mon, Dec 12, 2011 at 10:06 AM, Pascal Stumpf
wrote:
> On Mon, 12 Dec 2011 16:55:04 +0100 (CET), Mark Kettenis wrote:
>> > Date: Mon, 12 Dec 2011 16:51:48 +0100
>> > From: Pascal Stumpf
>> >
>> > On Mon, 12 Dec 2011 16:26:42 +0100, Marc Espie wrote:
>> > > On Mon, Dec 12, 2011 at 04:00:44PM +0
On Mon, 12 Dec 2011 16:55:04 +0100 (CET), Mark Kettenis wrote:
> > Date: Mon, 12 Dec 2011 16:51:48 +0100
> > From: Pascal Stumpf
> >
> > On Mon, 12 Dec 2011 16:26:42 +0100, Marc Espie wrote:
> > > On Mon, Dec 12, 2011 at 04:00:44PM +0100, Pascal Stumpf wrote:
> > > > On Mon, 12 Dec 2011 14:41:45
> Date: Mon, 12 Dec 2011 16:51:48 +0100
> From: Pascal Stumpf
>
> On Mon, 12 Dec 2011 16:26:42 +0100, Marc Espie wrote:
> > On Mon, Dec 12, 2011 at 04:00:44PM +0100, Pascal Stumpf wrote:
> > > On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote:
> > > >
> > > > The s/restrict/__restri
On Mon, 12 Dec 2011 16:26:42 +0100, Marc Espie wrote:
> On Mon, Dec 12, 2011 at 04:00:44PM +0100, Pascal Stumpf wrote:
> > On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote:
> > >
> > > The s/restrict/__restrict/g in cstdio shouldn't be necessary.
> >
> > Apparently, clang++ interpret
On 12 December 2011 16:28, Marc Espie wrote:
> On Mon, Dec 12, 2011 at 04:15:23PM +0100, Mathieu - wrote:
>> restrict is a C99 keyword and has no meaning (ie doesn't exist) in the
>> C++ standard.
>
> Wrong answer. What's the C++ standard ? C++98 or C++2011 ?
>
> A lot of things that are valid C++
On Mon, Dec 12, 2011 at 04:15:23PM +0100, Mathieu - wrote:
> restrict is a C99 keyword and has no meaning (ie doesn't exist) in the
> C++ standard.
Wrong answer. What's the C++ standard ? C++98 or C++2011 ?
A lot of things that are valid C++ don't exist in any C++ standard,
since they're include
On Mon, Dec 12, 2011 at 04:00:44PM +0100, Pascal Stumpf wrote:
> On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote:
> >
> > The s/restrict/__restrict/g in cstdio shouldn't be necessary.
>
> Apparently, clang++ interprets "restrict" as parameter name, i.e.:
>
> attr.cc:1:50: error: re
oups include the list this time sorry for the noise Pascal.
On 12 December 2011 16:00, Pascal Stumpf wrote:
> On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote:
>> > Date: Sun, 11 Dec 2011 19:18:40 +0100
>> > From: Pascal Stumpf
>> >
>> > > I still think this should be investigated
On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote:
> > Date: Sun, 11 Dec 2011 19:18:40 +0100
> > From: Pascal Stumpf
> >
> > > I still think this should be investigated deeper. Matthew did a bit
> > > of digging jusdging from:
> > >
> > >http://marc.info/?l=openbsd-ports&m=12978
Hi,
While working on enabling upnp/natpmp support into net/mldonkey,
I've found we miss pthread_mutex_timedlock().
For now I've the diff below, which is ripped/adapted from xine-lib,
and it seems to do the trick...
Would it be useful to add it to libpthread?
Reference is at:
http://pubs.opengro
> Date: Sun, 11 Dec 2011 19:18:40 +0100
> From: Pascal Stumpf
>
> > I still think this should be investigated deeper. Matthew did a bit
> > of digging jusdging from:
> >
> >http://marc.info/?l=openbsd-ports&m=129783295016631&w=2
> >
> > That raises the question what difference between the
Bug description:
HTTP POST requests with short Content-Lenght hangs (see attached file
request)
Test setup: relayd configured to relay client requests to the internet. I use
a relay which is in lateconnect mode.
$ cat request | nc 127.0.0.1
Bug analysis:
- relay_read_http() reads the Conte
Hi,
I recently encountered a similar bug like this one
http://www.freebsd.org/cgi/query-pr.cgi?pr=76690 in openbsds pthread
library. It seems that if the malloc lock is not obtained before the
fork bad things may happen on following free's in the forked child. This
is my take at fixing this b
19 matches
Mail list logo
