Custom Query (1030 matches)
Results (151 - 153 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #861 | invalid | overzealous and flaky warning about SETQ'd unused lexical variable/ | ||
| Description |
Sometimes the compiler warns
where FOO is some variable I've SETQ'd but then not referred to. That's annoying enough. I don't think that should be done at all. It's a pain to have to throw away documentary (multiple-value-setq (x y z) ...) variables or go through other hoops just to get rid of this warning. Also, it's "used" by reasonable definition: it's set, just not "read" or "eval'd". Whatever. It's a pain to encounter and to work around. But that's not the main point. Sometimes -- not always!! -- I cannot even still the compiler by simply placing the variable inline to be evaluated. The compiler first of all is so clever as to optimize out the reference, then turns on me and tells me it's not referenced. That is quite frustrating to put it mildly. Seems to happen in big functions. Small functions work fine, so I cannot give you an example. But it's like this:
(defun foo (a b)
(let (c d)
(multiple-value-setq (c d) (round a b))
c))
always warns about D "unused" (annoying to me, but I can deal with it) (defun foo (a b)
(let (c d)
(multiple-value-setq (c d) (round a b))
d
c))
not in this case, but in some larger functions, warns about D -- unacceptable, bug, etc.! Note: let me know if this is a known problem: that is, the flakyness (dependency on function size, or whatever), or -- if not -- if you need an example. I'll put cycles on it, but would rather not if it's already known. Version info:
CCL::*OPENMCL-MAJOR-VERSION*, Value: 1
CCL::*OPENMCL-MINOR-VERSION*, Value: 6
|
|||
| #864 | duplicate | Command line processing for SAVE-APPLICATION | ||
| Description |
When building a standalone binary using SAVE-APPLICATION and :PREPEND-KERNEL T, I found the command line argument processing of the resulting binary undesirable. I have a patch that solves the problem for me, however, it might not be the best way of doing things. The problem as I see it is as follows: When only one argument (which does not begin with a '-') is provided to a binary which consists of (kernel + heap-image), the current kernel code automatically tries to load that argument as the image even though it should clearly use the image attached to the binary itself. As a result, one has to always use the '--' argument to end processing of the kernel arguments. This behavior is not expected for unix command line tools and shouldn't be expected here either IMHO. The attached patch provides a sub-optimal solution which basically detects the case when the heap image is already included in the binary and so does not try to load the image from that first argument. The problem with this is that since '--' is not required, other kernel level command line flags, such as -I, -R, -S, etc, that are not passed on to the application may cause some confusion. Another solution is to completely disable those kernel level flags if the heap image is attached to the kernel, but the loss of control over those parameters is also undesirable. |
|||
| #865 | fixed | restart-case mishandles cerror | ||
| Description |
? (defun test (name) (restart-case (cerror "foo ~s" "bar ~s" name) (a-restart () nil))) TEST ? (test 'hah) > Error: bar HAH > While executing: TEST, in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: foo #<error printing object>
Note the (pprint (macroexpand-1 '(restart-case (cerror "foo ~s" "bar ~s" name)
(a-restart () nil))))
(BLOCK #:G672
(LET* ((#:G673 (%CONS-RESTART 'A-RESTART NIL NIL NIL NIL))
(#:G670 (LIST #:G673)))
(DECLARE (DYNAMIC-EXTENT #:G673 #:G670))
(CATCH #:G670
(LET ((%RESTARTS% (CONS #:G670 %RESTARTS%)))
(DECLARE (DYNAMIC-EXTENT %RESTARTS%))
(RETURN-FROM #:G672
(LET ((#:G671
(CONDITION-ARG "bar ~s" (LIST NAME) 'SIMPLE-ERROR)))
(WITH-CONDITION-RESTARTS
#:G671
#:G670
(CERROR "foo ~s" #:G671)))))))
|
|||
