New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve recording of source information for most kinds of definitions <http://abcl.org/trac/ticket/415> #5
Conversation
…property sys::%source-by-type
@alanruttenberg: As I understand your intention after this patch is finished, we will have two properties on symbols with associated source:
where Once the code works well enough for SLIME, we would no longer need
Instead of
Why does your code comment out the call to SET-ARGLIST in the precompiler? Does this need additional work, or an oversight on your part?
Why do functions need to record their names with a cons in place of a simple keyword (probably something basic than I am not getting)? Shouldn't we distinguish between DEFUN, DEFMETHOD, and DEFGENERIC definitions for functions? i.e. shouldn't we just replace the
If you agree on the symbol property key being 'SYSTEM:SOURCE', and can explain the bit about function source location using a cons to record its type, I'd go for merging this as a work in progress. |
I had some trouble building with the arglist being set there. I think it is set elsewhere. Try getting arglists in the new build. mop:add-direct-method is at least defined with defun at that location. It is later defined using atomic-defgeneric and looking at the expansion of that I can see that it is doing some funny business. It will need to be special-cased. It defines the generic function on a gensym.
(describe 'print-object) to see methods and generic-functions recorded
Functions are defined as cons because sometimes they are the symbol and sometimes they are the (setf xxx). In the latter case the source information is also kept on xxx. e.g.
:defstruct should be :structure. I'm trying to follow this bit in swank/sbcl.lisp. Will fix.
I'm fine with system:source |
…d source for methods defined in defgeneric. Fix some cases where file-compile recorded source but load didn't
Committed changes to address some issues discussed. |
squashed commits and added better doc to commit message. |
property sys:source. Implementation record-source-information-by-type (name type &optional source-pathname source-position) type is either a symbol or list. Functions, methods, and generic functions are lists: (:generic-function function-name) (:function function-name) (:method method-name qualifiers specializers) function-name or method name can be a 'symbol or '(setf symbol) Other types are just symbols, and follow sbcl's in slime (https://github.com/slime/slime/blob/bad2acf672c33b913aabc1a7facb9c3c16a4afe9/swank/sbcl.lisp#L748) :class, :variable, :condition, :constant, :compiler-macro, :macro, :package, :structure, :type, :setf-expander, :source-transform Modifications are in two places, one at the definitions, calling record-source-information-by-type and then again in the file-compiler, which writes forms like (put 'source name (cons (list type pathname position) (get 'source name))) In theory this can lead to redundancy if a fasl is loaded again and again. I'm not sure how to fix this yet. Forms in the __loader__ get called early in build when many of the sequence functions aren't present. Will probably just filter when presenting in slime.
Still testing; and thinking. Apologies. |
…ol (Alan Ruttenberg) The interface to recording information on the SYS:%SOURCE plist for a symbol is now deprecated and will be removed with abcl-1.7. Implementation -------------- Source information for ABCL is now recorded on the SYS::SOURCE property. The appropiate information for type is recorded by the SYS::RECORD-SOURCE-INFORMATION-BY-TYPE function: record-source-information-by-type (name type &optional source-pathname source-position) TYPE is either a symbol or list. Source information for functions, methods, and generic functions are represented as lists of the following form: (:generic-function function-name) (:function function-name) (:method method-name qualifiers specializers) Where FUNCTION-NAME or METHOD-NAME can be a either be of the form 'symbol or '(setf symbol). Source information for all other forms have a symbol for TYPE which is one of the following: :class, :variable, :condition, :constant, :compiler-macro, :macro :package, :structure, :type, :setf-expander, :source-transform These values follow SBCL'S implemenation in SLIME c.f. <https://github.com/slime/slime/blob/bad2acf672c33b913aabc1a7facb9c3c16a4afe9/swank/sbcl.lisp#L748> Modifications are in two places, one at the definitions, calling record-source-information-by-type and then again in the file-compiler, which writes forms like (put 'source name (cons (list type pathname position) (get 'source name))) In theory this can lead to redundancy if a fasl is loaded again and again. I'm not sure how to fix this yet. Forms in the __loader__ get called early in build when many of the sequence functions aren't present. Will probably just filter when presenting in slime. <> :closes <http://abcl.org/trac/ticket/421> . <> :merges <#5> .
Merged with commits through 9e27334 |
…ol (Alan Ruttenberg) The interface to recording information on the SYS:%SOURCE plist for a symbol is now deprecated and will be removed with abcl-1.7. Implementation -------------- Source information for ABCL is now recorded on the SYS::SOURCE property. The appropiate information for type is recorded by the SYS::RECORD-SOURCE-INFORMATION-BY-TYPE function: record-source-information-by-type (name type &optional source-pathname source-position) TYPE is either a symbol or list. Source information for functions, methods, and generic functions are represented as lists of the following form: (:generic-function function-name) (:function function-name) (:method method-name qualifiers specializers) Where FUNCTION-NAME or METHOD-NAME can be a either be of the form 'symbol or '(setf symbol). Source information for all other forms have a symbol for TYPE which is one of the following: :class, :variable, :condition, :constant, :compiler-macro, :macro :package, :structure, :type, :setf-expander, :source-transform These values follow SBCL'S implemenation in SLIME c.f. <https://github.com/slime/slime/blob/bad2acf672c33b913aabc1a7facb9c3c16a4afe9/swank/sbcl.lisp#L748> Modifications are in two places, one at the definitions, calling record-source-information-by-type and then again in the file-compiler, which writes forms like (put 'source name (cons (list type pathname position) (get 'source name))) In theory this can lead to redundancy if a fasl is loaded again and again. I'm not sure how to fix this yet. Forms in the __loader__ get called early in build when many of the sequence functions aren't present. Will probably just filter when presenting in slime. <> :closes <http://abcl.org/trac/ticket/421> . <> :merges <armedbear/abcl#5> . git-svn-id: http://abcl.org/svn@14914 1c010e3e-69d0-11dd-93a8-456734b0d56f
…ol (Alan Ruttenberg) The interface to recording information on the SYS:%SOURCE plist for a symbol is now deprecated and will be removed with abcl-1.7. Implementation -------------- Source information for ABCL is now recorded on the SYS::SOURCE property. The appropiate information for type is recorded by the SYS::RECORD-SOURCE-INFORMATION-BY-TYPE function: record-source-information-by-type (name type &optional source-pathname source-position) TYPE is either a symbol or list. Source information for functions, methods, and generic functions are represented as lists of the following form: (:generic-function function-name) (:function function-name) (:method method-name qualifiers specializers) Where FUNCTION-NAME or METHOD-NAME can be a either be of the form 'symbol or '(setf symbol). Source information for all other forms have a symbol for TYPE which is one of the following: :class, :variable, :condition, :constant, :compiler-macro, :macro :package, :structure, :type, :setf-expander, :source-transform These values follow SBCL'S implemenation in SLIME c.f. <https://github.com/slime/slime/blob/bad2acf672c33b913aabc1a7facb9c3c16a4afe9/swank/sbcl.lisp#L748> Modifications are in two places, one at the definitions, calling record-source-information-by-type and then again in the file-compiler, which writes forms like (put 'source name (cons (list type pathname position) (get 'source name))) In theory this can lead to redundancy if a fasl is loaded again and again. I'm not sure how to fix this yet. Forms in the __loader__ get called early in build when many of the sequence functions aren't present. Will probably just filter when presenting in slime. <> :closes <http://abcl.org/trac/ticket/421> . <> :merges <armedbear/abcl#5> . git-svn-id: http://abcl.org/svn/trunk/abcl@14914 1c010e3e-69d0-11dd-93a8-456734b0d56f
e.g.
I followed the source types in slime's swank/sbcl.lisp
This is preliminary to adding support for using this information in slime.
What should be recorded:
Implementation
fdefinition.lisp
has the functionrecord-source-information-for-type
For interactive evaluation it does the work. For file compiling there are additions tocompile-file.lisp
that add forms after the prologue that add the information when fasl loading, during which recording byrecord-source-information-for-type
is disabled, so it doesn't record the source positions in the fasl header.As you see, I haven't got rid of the now redundant sys:%source property. Once slime has been adjusted it might be worth doing so.
Right now the absolute pathnames are recorded, but it might make sense to use logical pathnames if there were ones set up, though I expect the slime support with do some dwimming in any case.