On 6/2/14, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Mon, 2 Jun 2014 10:17:53 +0200 (CEST)
From: Mark Kettenis mark.kette...@xs4all.nl
Date: Mon, 02 Jun 2014 09:34:20 +0200
From: Benjamin Baier program...@netzbasis.de
You might want to read up on floating point arithmetic.
Yup.Does this diff fix it for you?
On 2/6/14, Daniel Dickman didick...@gmail.com 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
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
On 2/12/14, Donovan Watteau tso...@gmail.com 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 stdio.h
#include stdlib.h
#include math.h
int main(void) {
double
On 3/21/11, Matthieu Herrb matthieu.he...@laas.fr 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:
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 4/2/11, Paul Irofti p...@irofti.net 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
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: owner-tech+m22...@openbsd.org
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 ieeefp.h
#include math.h
#include stdio.h
int
main(void)
{
fpsetround(FP_RM);
printf(%ld\n,
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:
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:
On 3/22/11, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Sun, 20 Mar 2011 03:08:41 +0200
From: Martynas Venckus marty...@venck.us
Index: include/fenv.h
===
RCS file: include/fenv.h
diff -N include/fenv.h
--- /dev/null
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
---
On 4/18/11, Matthew Dempsky matt...@dempsky.org wrote:
On Sun, Apr 17, 2011 at 5:29 PM, Philip Guenther guent...@gmail.com 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
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
On 8/24/10, Miod Vallat m...@online.fr 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
16 matches
Mail list logo
