Re: [armedbear-devel] [j-devel] slime swank-abcl.lisp
On 9/12/09 7:45 AM, Alan Ruttenberg wrote:
Here's a patch against the current swank-abcl.lisp to make a couple of things work for the trunk abcl.
I don't want to check it in, as I don't know whether there are issues with it working for older versions of abcl.
The fixes make edit definition work, and arglists for generic functions.
Is there anyone out there who is currently active on slime development that is comfortable checking these in?
Applied to SLIME CVS HEAD. Thanks for the patch! I tested with abcl-0.{15,16} and HEAD with the patch working as I expected. Keeping compatibility with more ancient versions of ABCL takes a too much of my scant resources, but if someone is stuck with a previous version of ABCL they wish to maintain compatibility with SLIME CVS HEAD, drop me an email to work something out. For those following the "old" armedbear-j-devel@lists.sourceforge.net list, and perhaps wondering why things have been so quiet lately, note that we moved [ABCL specific traffic to common-lisp.net][1] some months ago. [1]: http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Mark Evenson <evenson@panix.com> writes:
On 9/12/09 7:45 AM, Alan Ruttenberg wrote:
Here's a patch against the current swank-abcl.lisp to make a couple of things work for the trunk abcl.
I don't want to check it in, as I don't know whether there are issues with it working for older versions of abcl.
The fixes make edit definition work, and arglists for generic functions.
Is there anyone out there who is currently active on slime development that is comfortable checking these in?
Applied to SLIME CVS HEAD. Thanks for the patch!
I think there's an off-by-one in SOURCE-LOCATION. In Emacs, a buffer starts at 1, but in Common Lisp a file-position starts at 0. (Caveat: `(goto-char 0)' in DWIM fashion will also bring you to the beginning of a buffer.) I think that's the reason why you put the (PLUSP POS) there to guard against this issue, but merely passing (IF POS (1+ POS) 1) should also suffice. Perhaps you want to put this into an extra function so the casual hacker will be aware of it more easily. -T.
On 9/16/09 12:23 AM, Tobias C. Rittweiler wrote: […]
I think there's an off-by-one in SOURCE-LOCATION. In Emacs, a buffer starts at 1, but in Common Lisp a file-position starts at 0.
(Caveat: `(goto-char 0)' in DWIM fashion will also bring you to the beginning of a buffer.)
I think that's the reason why you put the (PLUSP POS) there to guard against this issue, but merely passing (IF POS (1+ POS) 1) should also suffice. Perhaps you want to put this into an extra function so the casual hacker will be aware of it more easily.
There certainly is an "off-by-one" here if Emacs buffers start at 1 (this surprised me!), but I don't quite understand what Tobias is proposing here. The intention of the first operand in the (AND POS (PLUSP POS) was to guard against getting a nil from EXT:SOURCE-FILE-POSITION, right? So don't we want this implementation: (defun source-location (symbol) (when (pathnamep (ext:source-pathname symbol)) (let ((pos (ext:source-file-position symbol))) `(((,symbol) (:location (:file ,(namestring (ext:source-pathname symbol))) ,(if pos (list :position (1+ pos)) (list :function-name (string symbol))) (:align t))))))) -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Mark Evenson writes:
On 9/16/09 12:23 AM, Tobias C. Rittweiler wrote: […]
I think there's an off-by-one in SOURCE-LOCATION. In Emacs, a buffer starts at 1, but in Common Lisp a file-position starts at 0.
(Caveat: `(goto-char 0)' in DWIM fashion will also bring you to the beginning of a buffer.)
I think that's the reason why you put the (PLUSP POS) there to guard against this issue, but merely passing (IF POS (1+ POS) 1) should also suffice. Perhaps you want to put this into an extra function so the casual hacker will be aware of it more easily.
There certainly is an "off-by-one" here if Emacs buffers start at 1 (this surprised me!), but I don't quite understand what Tobias is proposing here.
The intention of the first operand in the (AND POS (PLUSP POS) was to guard against getting a nil from EXT:SOURCE-FILE-POSITION, right? So don't we want this implementation:
(defun source-location (symbol) (when (pathnamep (ext:source-pathname symbol)) (let ((pos (ext:source-file-position symbol))) `(((,symbol) (:location (:file ,(namestring (ext:source-pathname symbol))) ,(if pos (list :position (1+ pos)) (list :function-name (string symbol))) (:align t)))))))
Yes, exactly. -T.
On 9/16/09 4:05 PM, Tobias C. Rittweiler wrote: […]
The intention of the first operand in the (AND POS (PLUSP POS) was to guard against getting a nil from EXT:SOURCE-FILE-POSITION, right? So don't we want this implementation:
(defun source-location (symbol) (when (pathnamep (ext:source-pathname symbol)) (let ((pos (ext:source-file-position symbol))) `(((,symbol) (:location (:file ,(namestring (ext:source-pathname symbol))) ,(if pos (list :position (1+ pos)) (list :function-name (string symbol))) (:align t)))))))
Yes, exactly.
Committed to SLIME CVS HEAD. Thanks for the help. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
participants (2)
-
Mark Evenson -
Tobias C. Rittweiler