Custom Query (1030 matches)
Results (820 - 822 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1056 | wontfix | a supported extension to support (un)reifying deferred warnings | ||
| Description |
ASDF 2.26.x introduces support for saving deferred warnings and re-playing them in a different session. It currently does it by peeking and poking at the internals of CCL (and SBCL). Could you export a supported variant of that functionality in CCL 1.9 and later? See the code in asdf/lisp-build.lisp. The entry points are reify-deferred-warnings unreify-deferred-warnings reset-deferred-warnings |
|||
| #1057 | fixed | patch for fixing amd64 build failure for gnustep header | ||
| 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 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 |
|||
| #1058 | fixed | Stress test failure with conditional-store | ||
| 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)))
|
|||
