-
-
Notifications
You must be signed in to change notification settings - Fork 20.2k
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
Scripting: Fix script docs not being searchable without manually recompiling scripts #95821
base: master
Are you sure you want to change the base?
Conversation
58e4ff3
to
7fde3a4
Compare
7fde3a4
to
88966ec
Compare
59d1345
to
53cc97c
Compare
I think it's better to fix this by checking the tab type. Doc tabs should never truncate the name, only script tabs. |
53cc97c
to
eff26b9
Compare
Why the difference? You can still get the full path by hovering and it's at the top of the help document. This way it feels like behavior is at least consistent? |
Works great!! Good job!! I tested this PR merging locally #95965 and #96002 There's a last problem where the doc loading thread can be reloading the doc script cache while the EditorFileSystem is scanning and updating the doc. That could lead to problems where the cache is loaded after the remove_doc or add_doc was called so the last version of the script is still in the documentation. Worst, we could try to read the cache while trying to delete it and vice versa. I suggest the script cache loading should be postponed after the first scan. You already done the logic when the cache is not present to wait for signal Tested:
|
Good news, this prerequisite PR has been merged: #95965 |
Perfect, rebased, fixed a couple of things and pushed! Been too sleepy/tired to work on this, but I don't know that we have an immediately obvious solution to the problem you mentioned. If we want to wait to load the cache until the first scan is complete, maybe If regenerating the cache: 1) First scan -> 2) Regenerate cache from scratch I'm worried about creating a race condition where EditorHelp is waiting for first scan, but before first scan finishes, it waits for EditorHelp to load the cache. Will try to give this some more thought when life allows! |
5232ea7
to
b5a000c
Compare
This entire summer i couldn't understand what was the issue with custom Documentations and why i had to resave scripts in order to make them working again. |
608ee4f
to
36513a2
Compare
Rebased once more and the crash seems to have been fixed, even in a project wit 8192 files. Will dig into the script updating but not the script doc! |
Very very nice modifications that you made on your last commit. I like the way you postponed the cache loading until the first scan is done and that you keep track of the changes while scanning and apply them after the cache is loaded!!!
The PR #96002 fixes the issue where the doc is not updated in memory, but there's still a issue if the doc is opened in the script editor, it's not updated, the doc needs to be closed and reopened. I'm not sure it's supposed to be fixed in this current PR, I'll look into it in #96002. Tested:
|
I have been able to replicate the crash. It happens when
It tries to print one line for each of 8192 resources being loaded onto the console, which I believe causes it to run out of memory. |
a89be95
to
c48336f
Compare
Tested the following with a 8000+ .gd file project: Godot open:
Godot closed:
I can no longer replicate the issue above, though it happened consistently for a few minutes. Tried with many combinations of different .gd files & docs open or closed in the ScriptEditor. I thought it might be from simultaneous reads/writes to That said, I'm not sure it's worth adding mutexes and locking for a low probability situation which can be fixed manually relatively easily? |
I think I created some regressions with #96002, it could be caused by that. This PR could maybe fix the intermittent problem. I'm not sure it should be investigated further here. It's being addressed in #97168
I'm pretty sure it's not necessary to use mutex because the |
Updated PR with latest feedback! And sounds great! I will try to get some time and look into those PRs, though I think you're right on this PR maybe not being the problem. These are my attempts to understand the possible issues, just for documentation purposes. The issue I was thinking would happen if I followed whether
So we are sure But maybe the issue is in 2), where |
This PR adds a script documentation cache in the project folder. It is loaded at alongside native documentation caches. This makes scripts fully accessible through Search Help, including their members, etc, right from project start, without having to compile every single script. Co-authored-by: Hilderin <[email protected]>
c48336f
to
3f2ef8d
Compare
This PR adds a script documentation cache in the project folder. It is loaded at alongside native documentation caches. This makes scripts fully accessible through Search Help, including their members, etc, right from project start, without having to compile every single script.
Testing with GDScript but, in theory, should work for any scripting language that has documentation support. Might be worth splitting the cache into a per-language basis to reduce conflicts, though if there are conflicts with e.g. a MyClass in GDScript and MyClass in C#, that already leads to problems with the current documentation system.
EditorFileSystem
's documentation updates is done by #95965, until then the cache will persist docs from deleted scriptsDiagram of call behavior that I needed to try to organize this in my brain:
Grey background runs on whatever thread called it. Orange background runs in
worker_thread
. Blue background represents waiting for one shotfilesystem_updated
signals depending on whetherEditorFileSystem::is_scanning()
is true.Implementation details:
EditorHelp::worker_thread
.worker_thread
connects toEditorFileSystem::filesystem_changed
signal, indicating the end ofEditorFileSystem
's scan, and ends its execution. It spools back up once the signal is fired to regenerate the cache, this time usingEditorFileSystemDirectory
, therefore not accessing underlying OS filesystem calls.EditorFileSystem
catch changes like deleted/added files to ensure docs are kept up to date.DocTool
method forwarding toEditorHelp
to help maintain cache consistency. It is meant to track whether changes affect script docs or other docs. These forwarded methods should be used from now on instead of e.g.get_doc_data()->add_doc()
."new_script.gd"
becomesnew_script.gd
, since this resulted in messy truncations of paths (to test, createnew_folder/new_script.gd
andnew_script.gd
and open both their documentations on stable.Fixes #72406, fixes #86577.