Problem with find-definition in Allegro 11 beta #613
Comments
|
Hello Robert. Sorry for not getting back to you earlier. I haven't got Allegro 11 beta to test this, and I've been away from CL from a while now. But I can give you some tips on debugging this. Definition finding has many ways to start, but the main way is For Allegro, this calls into the implementation of that interface, which lives in Using SLY to debug/develop SLY is generally possible and my recommendation is to have two connections: one for Allegro 10 and one for Allegro 11 and switch between them with I've solved some of these problems in the past (well in the past to be honest). If I recall correctly Allegro CL, the definition finding business is more convoluted than in other languages, and relies on some Allegro internals. For example, when compiling a definition with (defimplementation slynk-compile-string (string &key buffer position filename
line column policy)
(declare (ignore line column policy))
(handler-case
(with-compilation-hooks ()
(let ((*buffer-name* buffer)
(*buffer-start-position* position)
(*buffer-string* string))
(compile-from-temp-file string buffer position filename)))
(reader-error () nil)))And remember to also expand that Hope this helps, let me know if I can answer something more. if you can find me some Allegro 11 that I can use to test I might be able to find some time. It would also be worth it to check with the SLIME guys because usually these problems pop up there as well. Maybe @luismbo has some clues (though I think he doesn't use Allegro as much as he used to....). |
|
@joaotavora Thank you very much for the helpful write-up. It seems like buried somewhere down in there is an invocation of Allegro functions on the slynk side that is not terminating so that a new attempt to search fails. One possibility, it seems to me, is this function, which is used in the There's something going on in the interaction between emacs and CL that I really don't understand at all... |
I find this a bit odd. At least, I understand by "not terminating" something that times out on the Slynk side. For asynchronous Emacs -> Slynk requests ( So from what you've shown it seems that the underlying operation is simply returning an error. Maybe you can confirm this by showing a fragment of the ...
(:emacs-rex (slynk:find-definitions-for-emacs "xref>elisp") ":slynk" t
6)
(:return
(:ok
(("(:OPERATOR XREF>ELISP)"
(:location
(:file "/home/capitaomorte/Source/Emacs/sly/slynk/slynk.lisp")
(:offset 1 128614) nil))))
6)
...But in your case, it seems that (:emacs-rex (slynk:find-definitions-for-emacs "xref>elisp") ":slynk" t
46)
(:return (:ok ((":ERROR" "oh no"))) 46)Most likely the It is probably helpful to trace (either with CL's built-in (defun find-fspec-location (fspec type file top-level)
(handler-case
(etypecase file
(pathname
(let ((probe (gethash file *temp-file-map*)))
(cond (probe
(destructuring-bind (buffer offset) probe
(make-location `(:buffer ,buffer)
`(:offset ,offset 0))))
(t
(find-definition-in-file fspec type file top-level)))))
((member :top-level)
(make-error-location "Defined at toplevel: ~A"
(fspec->string fspec))))
(error (e)
(make-error-location "Error: ~A" e))))Anyway, you should trace a lot of functions, like this one and |
|
Recording my initial tracing results here. I will continue to look into this. Looks like things are going wrong in |
|
Further notes:
|
Thanks and keep posting your results here freely. |
|
Some more notes:
|
Yes, that is correct -- I pulled the junk out and then redid the
I'm not at all sure what Franz's file positions are. They don't seem to correspond to indices into characters of the file. From the fact that there's For what it's worth, I'm on the Mac, and wrote this code on a modern Mac, so the line endings should simply be newlines (no old-school Mac
Using revision annotate, I found two commits -- both pretty old -- that touch the enclosing and |
Alas, although it's exported, it doesn't have docstrings, and there's nothing in the Franz docs about the However I have a source license for Allegro (but unfortunately only for 10.1, not the 11 beta), and I can see the error in their SCM code. It happens when we reach the end of file without having reached the end of the source definition we are looking at. I'm looking and this almost looks like a simple fencepost error. But I really can't tell, since I have the source only for the version that used to work, not the current version that doesn't.
I'll have to work on this. The problem is that I have an M1 Mac and Allegro 10.1 doesn't run on my machine. I'll have to get set up on a linux box where I can test Allegro 10.1
I will have to see. More soon! |
It should be relatively easy to create a then |
|
Sorry about the long delay. It appears there is something about this particular file of code that is interfering with Allegro's source finding, so an MWE is not easy to make. Trying to shim in enough time to check what has changed in the source tracking (Franz very kindly supplied me source under NDA). |
|
I have little more to report, except to say that Allegro 11 express edition should now be available at the Franz download site. I continue to work on this as other responsibilities permit. |
When I try to find a definition after the first time with SLY and Allegro 11, I get errors that look like this:
I wasn't able to find that error string looking around in the sly code, so I am a little bit lost. Is there some way to track this down? It looks like some transaction between Emacs and CL is stuck in a weird state. If anyone could point me towards a location in the sly/slynk code, I would have a whack at fixing it.
Another thing that would help would be if I could gather more information -- like maybe dump a backtrace to a file.
The text was updated successfully, but these errors were encountered: