On 6/4/14, Mark Kettenis wrote:
>> Date: Mon, 2 Jun 2014 21:18:26 -0400
>> From: Daniel Dickman
>>
>> >
>> > Another bug. Intel chose an extended precision format with an
>> > explicit integer bit, and the code doesn't handle that. Assuming we
>> > don't support machines with extended precision
On 6/2/14, Mark Kettenis wrote:
>> Date: Mon, 2 Jun 2014 10:17:53 +0200 (CEST)
>> From: Mark Kettenis
>>
>> > Date: Mon, 02 Jun 2014 09:34:20 +0200
>> > From: Benjamin Baier
>> >
>> > You might want to read up on floating point arithmetic. (rounding and
>> > representation)
>>
>> Well, the diffe
On 2/12/14, Donovan Watteau wrote:
> On Thu, 6 Feb 2014, Donovan Watteau wrote:
>> David Coppa wrote:
>> > Take the following reduced test-case, adapted from what R's code
>> > does:
>> >
>> > ---8<---
>> >
>> > #include
>> > #include
>> > #include
>> >
>> > int main(void) {
>> >double thet
> Here's a diff that sticks a bit closer to the original code. It's
> equivalent to your diff, and admittedly purely a matter of taste which
> version to prefer.
I prefer my version better. It's not '93 anymore and compilers are
able to convert 0.0L and -1.0L precisely, otherwise we have a huge
Yup.Does this diff fix it for you?
On 2/6/14, Daniel Dickman wrote:
> I think I recently ran into a similar issue but I suspect the root cause
> might be the same. I think the floorl function is wrong for numbers slightly
> larger than -1 to numbers slightly below 0. In this range floorl retu
On 4/18/11, Matthew Dempsky wrote:
> On Sun, Apr 17, 2011 at 5:29 PM, Philip Guenther wrote:
>> I haven't worked through all the bit-twiddling and asm, but what I
>> have looks good and the abundance of regress tests that keep showing
>> up in "cvs up -d" inspires confidence. With that x87-->__x
The diff I sent before has been corrupted by Gmail (wrapped diff lines).
I'm re-attaching it below.
Index: include/Makefile
===
RCS file: /cvs/src/include/Makefile,v
retrieving revision 1.157
diff -u -r1.157 Makefile
--- include/Make
On 3/22/11, Mark Kettenis wrote:
>> Date: Sun, 20 Mar 2011 03:08:41 +0200
>> From: Martynas Venckus
>>
>> Index: include/fenv.h
>> ===
>> RCS file: include/fenv.h
>> diff -N include/fenv.h
&
> Delivered-To: marty...@venck.us
> Received: by 10.231.147.205 with SMTP id m13cs105662ibv;
> Tue, 15 Mar 2011 01:48:25 -0700 (PDT)
> Received: by 10.43.46.135 with SMTP id uo7mr4936656icb.50.1300178905343;
> Tue, 15 Mar 2011 01:48:25 -0700 (PDT)
> Return-Path:
> Received: from sh
> Delivered-To: marty...@venck.us
> Received: by 10.100.109.13 with SMTP id h13cs81395anc;
> Sun, 9 Jan 2011 14:09:58 -0800 (PST)
> Received: by 10.42.176.2 with SMTP id bc2mr3471559icb.517.1294610998158;
> Sun, 09 Jan 2011 14:09:58 -0800 (PST)
> Return-Path:
> Received: from shear
Our lrint, llrint, lrintf, llrintf always return 0 for inputs close
to 0. However, depending on the rounding mode, they should actually
return -1 or 1.
Here's my test case:
#include
#include
#include
int
main(void)
{
fpsetround(FP_RM);
printf("%ld\n", lrint(-0.2));
fp
> Delivered-To: marty...@venck.us
> Received: by 10.100.125.2 with SMTP id x2cs7548anc;
> Wed, 8 Dec 2010 00:00:53 -0800 (PST)
> Received: by 10.231.32.197 with SMTP id e5mr738073ibd.188.1291795252925;
> Wed, 08 Dec 2010 00:00:52 -0800 (PST)
> Return-Path:
> Received: from shear.uc
On 4/2/11, Paul Irofti wrote:
> What about devices that should support _DOS and don't support
> brightness? I've tested this on a D620 (which has the methods but does
> brightness through the BIOS) and the relevant dmesg diff is:
>
> -acpivout0 at acpivideo1: TV__
> -acpivout1 at acpivideo1: CRT_
Please test, details below.
We attach acpivout(4) to every device enumerated in _DOD. However,
if you read ACPI spec. closely, it says that _DOD (unlike _DOS) is
not required if the system supports LCD brightness control.
In my case the situation is even worse--_DOD enumerates only 0x400
(which
On 3/21/11, Matthieu Herrb wrote:
> rain(6) is useless. but still it should provide sane defaults
> ihmo. ok?
Or use sane defaults based on terminal speed; like worms(8) does.
Index: rain.6
===
RCS file: /cvs/src/games/rain/rain.6,
Hi,
I've taken a look at the amd64 part of the diff. Comments inline.
I'm in the progress of implementing support for the remaining
architectures, if anyone could provide me with remote access that
would speed up the process.
> Delivered-To: marty...@venck.us
> Received: by 10.231.207.5 with SM
On 8/24/10, Miod Vallat wrote:
>> the little operating system we wrote eventually panic'd (overflowed
>> heap); standalone ufs.c implementation we've used leaks f_buf
>> everytime ufs_open fails
>
> This is correct, but you may be leaking fp->f_blk[] as well. What about
> this instead?
yup i thi
the little operating system we wrote eventually panic'd (overflowed
heap); standalone ufs.c implementation we've used leaks f_buf
everytime ufs_open fails
Index: ufs.c
===
RCS file: /cvs/src/sys/lib/libsa/ufs.c,v
retrieving revision
it crashes for me about 50% of the times like this
$ make install
===> docbook-4.4p0 depends on: docbook-dsssl-* - not found
===> Verifying install for docbook-dsssl-* in textproc/docbook-dsssl
===> Checking files for docbook-dsssl-1.72
>> Fetch http://downloads.sourceforge.net/sourceforge/docb
every time x starts i get "is lvds". i think this is a debugging
leftover, since the official xf86-video-intel tree never had it?
Index: i830_display.c
===
RCS file: /cvs/xenocara/driver/xf86-video-intel/src/i830_display.c,v
retrievi
:36 kevlo Exp $ */
/*-
+ * Copyright (c) 2009 Martynas Venckus
* Copyright (c) 2008 Weongyo Jeong
*
* Permission to use, copy, modify, and distribute this software for any
@@ -79,6 +80,8 @@
} urtw_devs[] = {
#defineURTW_DEV_RTL8187(v, p) \
{ { USB_VENDOR_
21 matches
Mail list logo
