Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Neil Schemenauer <nas@py...> - 2003-05-20 23:40:04
> OK, I managed to talk to Sourceforge's CVS.
> I have actually re-ordred teh patch-file and hand-edited out two lines that
> were just in there for testing. It is hopefully still valid, though.
You really want to be using unified diffs. The easiest way to do that
with CVS is to create $HOME/.cvsrc containing the line "diff -u".
I'm guessing the diff is not valid. If you want to edit unified diffs,
it's generally only safe to remove complete "hunks". A hunk starts with
"@@" and ends just before the next hunk or EOF.
>OK, I managed to talk to Sourceforge's CVS.
>I have actually re-ordred teh patch-file and hand-edited out two lines that
>were just in there for testing. It is hopefully still valid, though.
And now with "diff -u" patch-file.
Ingvar <ingvar@...> writes:
> And now with "diff -u" patch-file.
> +(defmacro compiler-note-conditional (note-type format-string &rest format-args)
> + `(progn (unless (or ,@(loop for sym in note-type collect (list 'member sym '*ignore-compiler-note-class-list*)))
> + (compiler-note ,format-string ,@format-args))
> + (values)))
> - (compiler-note
> + (compiler-note-conditional '(:return)
> - (compiler-note "couldn't inline expand because expansion ~
> + (compiler-note-conditional (:NO-INLINE) "couldn't inline expand because expansion ~
> - (give-up-ir1-transform "BOOLE code is not a constant."))
> + (give-up-ir1-transform '(:boole :no-inline) "BOOLE code is not a constant."))
Here's a good argument for more type-checking: those QUOTEs, if I'm not
mistaken, are going to cause a problem. :-)
OK, I think this is a good start. However, I think I would rather see
something that uses the condition system. The comment above
COMPILER-NOTE says that it used to signal conditions; however, in the
process of modernising the code, that was removed, basically because
in SBCL a compiler note really is a note, not a STYLE-WARNING. I
think it ought to be possible to reintroduce conditions for compiler
notes, with a hierarchy that looks something like
SIMPLE-COMPILER-NOTE (mixin: SIMPLE-CONDITION, for uncategorized)
Then you can get the effect of your patch by having an outer handler,
discarding the condition based on its type (and a special variable,
say *ignored-note-types*); but also user code can handle these beasts
selectively, maybe with a declaration interface to quieten the
Does that make any sense? I suppose the thing that using the
condition system buys us is a little more power for reflection.
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)