Custom Query (1030 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (208 - 210 of 1030)

Ticket Resolution Summary Owner Reporter
#1059 fixed Intermediate overflow in math functions David Findlay
Description

I wrote some code to exercise CCL's math functions and found that there were cases where intermediate computations were causing floating point overflows.

Functions affected are exp, tan, atan, tanh and atanh:

exp: fails for very large negative real rationals.

tanh: fails for complex arguments with very large real parts.

atanh: fails for numbers of the form 1 + iy for very small y.

tan and atan: analogous failures as for tanh and atanh.

I'm attaching (i) the code to exercise the functions (you just load it into Lisp) and (ii) a file of patches that fix the issues. (Apart from the exp issue, these are present in the fix to 869 - sorry.)

#1058 fixed Stress test failure with conditional-store Gary Byers James M. Lawrence
Description

(This assumes ccl::conditional-store should work even though it's not officially supported.)

The RUN function below eventually hangs on Linux and Darwin. On 32-bit it generally hangs sooner. The time until hanging decreases as the thread count increases. The number of threads reported by ccl:all-processes is relatively constant, and hanging still occurs with a 2-second sleep added to the loop.

Unfortunately I could not reproduce with a CAS-based stack, and CAS spin locks have been fixed (#1030), which leaves us with the more complex CAS queue. I hope the implementation below is straightforward enough. I'm confident that it is correct, so please double-check before blaming the queue. I've included SBCL support for reference (it runs on SBCL without a problem).

#+ccl
(defmacro conditional-store (&rest args)
  `(ccl::conditional-store ,@args))

#+sbcl
(eval-when (:compile-toplevel :load-toplevel :execute)
  (import '(sb-thread:make-semaphore
            sb-thread:signal-semaphore
            sb-thread:wait-on-semaphore))
  (defmacro conditional-store (place old new)
    (check-type old symbol)
    `(eq ,old (sb-ext:compare-and-swap ,place ,old ,new)))
  (defun process-run-function (name function)
    (sb-thread:make-thread function :name name)))

;;;; queue

;;; The following invariants hold except during lag across threads:
;;;
;;; (node-cdr (queue-tail queue)) == nil
;;;
;;; If the queue is empty, (queue-head queue) == (queue-tail queue).
;;;
;;; If the queue is non-empty, (node-car (node-cdr (queue-head queue)))
;;; is the next value to be dequeued and (node-car (queue-tail queue))
;;; is the most recently enqueued value.

(defstruct (node (:constructor make-node (car cdr)))
  (car (error "no car"))
  (cdr (error "no cdr")))

(defstruct (queue (:constructor %make-queue (head tail)))
  (head (error "no head"))
  (tail (error "no tail")))

(defconstant +dummy+ 'dummy)

(defun make-queue ()
  (let ((dummy (make-node +dummy+ nil)))
    (%make-queue dummy dummy)))

(defun enqueue (value queue)
  (let ((new (make-node value nil)))
    (loop (when (conditional-store (node-cdr (queue-tail queue)) nil new)
            (setf (queue-tail queue) new)
            (return value)))))

(defun dequeue (queue)
  (loop (let* ((head (queue-head queue))
               (next (node-cdr head)))
          (cond ((null next)
                 (return (values nil nil)))
                ((eq next +dummy+)) ; try again
                ((conditional-store (queue-head queue) head next)
                 (let ((result (node-car next)))
                   (setf (node-cdr head) +dummy+
                         (node-car head) +dummy+)
                   (return (values result t))))))))

;;;; test

(defun test (message-count thread-count)
  (let ((queue (make-queue)))
    (loop repeat thread-count
          do (process-run-function
              "test"
              (lambda ()
                (loop repeat message-count
                      do (enqueue :hello queue))
                (enqueue :done queue))))
    (loop with done-count = 0
          until (and (eq :done (dequeue queue))
                     (= (incf done-count) thread-count)))))

(defun run ()
  (loop
     (test 10000 64)
     (format t ".")
     (finish-output)))
#1057 fixed patch for fixing amd64 build failure for gnustep header Faheem Mitha
Description

Hi,

See patch below, which follows the Debian DEP3 standard.

I think the information in the patch description is mostly sufficient to explain the issue. It is possible this build issue is specific to Debian and not a problem elsewhere. It is also possible that this additional flag will break builds on other platforms. I cannot test either of these possibilities easily. In any case, I'm forwarding this patch upstream, as per Debian guidelines. If this patch is included upstream, then it will not need to be included in Debian.

Please also note that the x86-headers64 used was from

svn://svn.clozure.com/openmcl/release/1.8/x86-headers64

The corresponding web link is

http://svn.clozure.com/publicsvn/openmcl/release/1.8/x86-headers64/gnustep/C/populate.sh

BTW, I notice that the interface databases are only built for the gnustep headers on amd64. I tried copying them to i386 and building the databases on i386, but got a segfault.

Description: Fix error when running x86-headers64/gnustep/C/populate.sh
Without this patch, when running x86-headers64/gnustep/C/populate.sh,
the following error occurs.
.
  In file included from
  /usr/include/GNUstep/Foundation/NSClassDescription.h:30, from
  /usr/include/GNUstep/Foundation/Foundation.h:49, from
  /usr/include/GNUstep/Cocoa/Cocoa.h:33, from
  /tmp/Cocoa.h.tmp_8LoKm:1:
  /usr/include/GNUstep/Foundation/NSException.h:42:2: error: #error
  The current setting for native-objc-exceptions does not match that
  of gnustep-base ... please correct this.
.
Reference: In [Compile Objective-C Programs Using gcc]
(http://blog.lyxite.com/2008/01/compile-objective-c-programs-using-gcc.html)
there is the following:
.
  Also note that if you did not include -D_NATIVE_OBJC_EXCEPTIONS, you may run into the following error:
.
  /usr/include/GNUstep/Foundation/NSException.h:42:2: error: #error The
  current setting for native-objc-exceptions does not match that of
  gnustep-base ... please correct this.
Author: Faheem Mitha
Bug: <URL to the upstream bug report if any, implies patch has been forwarded, optional>
Forwarded: <URL|no|not-needed, useless if you have a Bug field, optional>
Applied-Upstream: <version|URL|commit, identifies patches merged upstream, optional>
Last-Update: Mon Feb  4 2013
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
diff -r b9b89814e0e0 -r 2b8f5332445e x86-headers64/gnustep/C/populate.sh
--- a/x86-headers64/gnustep/C/populate.sh       Sun Feb 03 13:15:57 2013 -0500
+++ b/x86-headers64/gnustep/C/populate.sh       Sun Feb 03 13:57:12 2013 -0500
@@ -1,2 +1,2 @@
 #!/bin/sh
-h-to-ffi.sh -m64 -I/usr/include/GNUstep /usr/include/GNUstep/Cocoa/Cocoa.h
+h-to-ffi.sh -m64 -D_NATIVE_OBJC_EXCEPTIONS -I/usr/include/GNUstep /usr/include/GNUstep/Cocoa/Cocoa.h
Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.