Syncheck:find-source-object

[greghendershott]

@robby

re holding onto fully expanded objects: The goal was to avoid having the programmer who is editing their program avoid having to wait through two expansions of the same code.

I totally understand and agree with the motivation!

@robby

So, if we're reading the data from the database and we didn't actually do a first expansion so no problem if we don't have the object saved. I guess one way to do this would be to have an API call to pdb that supplied as input the program to expand (via a port or string or filename etc) and got back the expansion results and, if the program actually was expanded, to get back the fully expanded object. So, if it isn't there to be gotten, then, np, just don't give it back. Does something like that sound workable?

I can totally do this and if that meets your needs, great.

---

One scenario I had in mind: Currently analyze-path has an optional #:import-depth argument, defaulting to 0:

;; #:import-depth says how many levels to recur and analyze imported
;; files, too. Reasonable values are 0 (none), 1 (just files directly
;; imported by the analyzed file, on the theory the user might access
;; one of them soon), or a very large integer (all that can be found
;; transitively, up to "opaque" modules like #%core and #%kernel).
;; Other values are legal but of dubious value. The analysis of these
;; imported files takes place on another thread, and does not
;; meaningfully delay returning results for the primary file.

I imagine something like {DrRacket VsCode Emacs} would, when the user opens some new file, want to supply analyze-path an import-depth like 1. Meaning, proactively and analyze/save the immediate imports. That way, if the user eventually opens a requiring file, analyze-path for that is likely "instant". Also, things like jump-to-definition are more likely to jump to a file that's already analyzed, and therefore moving to the exact location within will also be "instant". (Of course a tool could also let the user choose this depth to be 0 or 1 or whatever.)

If DrRacket depends on getting back expanded syntax from analyze-path, it can't/won't for one of those pre/eagerly analyzed files, or any file from the db.

But I guess you're saying if analyze-path were to return (or/c syntax? #f) -- either fully-expanded syntax or false -- it's OK when it returns false, you can just expand yourself. Is that correct?

[greghendershott]

1. I pushed some commits for returning expanded syntax when analysis not already in cache; see updated comments for analyze-path about fresh-analysis? and fresh-analysis-expanded-syntax.

2. Regarding kill-safety: I think it's already OK. If you continue to do the things you already do, wrt making/shutting-down a custodian for the thread on which you call analyze-path, it should be fine IIUC. (The only reason I went with break-thread was so I could disable breaks around a db operation, just to be safe, but the more I think about it that's probably not necessary.) Anyway I'm open to suggestions/changes.

Anyway, I feel like I'm fire-hosing this thread again. Thankfully Discourse lets people mute threads. If/as/when you want to try using this, maybe you could open a GitHub issue about any problems or design suggestion, so we could discuss over there instead.