Fixes#73374
As of godot 4 On windows/osx the game window will be frozen and will not
be updated.
In the debugger loop it calls
OS::get_singleton()->process_and_drop_events();
which allows windows/osx to handle system events. If the window doesn't
handle these events then both systems will judge the window to be 'not
responding' (osx beachball cursor)
When the event processing code was migrated from OS to DisplayServer the
process_and_drop_events() logic was moved to DisplayServer, but the call
inside the remote debugger pause loop was not updated to call the
DisplayServer version, there are currently no implementations of
OS::process_and_drop_events() so i removed it and switched to the new
DisplayServer::force_process_and_drop_events() method.
* Replaces `find(...) != -1` with `contains` for `String`
* Replaces `find(...) == -1` with `!contains` for `String`
* Replaces `find(...) != -1` with `has` for containers
* Replaces `find(...) == -1` with `!has` for containers
Random-access access to `List` when iterating is `O(n^2)` (`O(n)` when
accessing a single element)
* Removed subscript operator, in favor of a more explicit `get`
* Added conversion from `Iterator` to `ConstIterator`
* Remade existing operations into other solutions when applicable
This allows to include script_instance.h directly in the
generated gdvirtual.gen.inc, and remove excessive includes
from the codebase.
This should also allow Resource to use GDVIRTUAL macros,
which wasn't possible previously due to a circular dependency.
* This implementation adds threads on the side of the client (script debugger).
* Some functions of the debugger are optimized.
* The profile is also now thread safe using atomics.
* The editor can switch between multiple threads when debugging.
This PR adds threaded support for the script language debugger. Every thread has its own thread local data and it will connect to the debugger using multiple thread IDs.
This means that, now, the editor can receive multiple threads entering debug mode at the same time.
When using the command line debugger (godot -d) on Unix systems, when
entering an EOF (ctrl+D), the debugger enters an infinite loop.
Adding a check for EOF in the debugger loop exits the debugger when EOF
is entered.
Fixes#50170.
On Linux, thread IDs were not properly assigned with the current approach.
The line:
`std::thread new_thread(&Thread::callback, _thread_id_hash(thread.get_id()), p_settings, p_callback, p_user);`
does not work because the thread ID is not assigned until the thread starts.
This PR changes the behavior to use manually generated thread IDs. Additionally, if a thread is (or may have been created) outside Godot, the method `Thread::attach_external_thread` was added.
As many open source projects have started doing it, we're removing the
current year from the copyright notice, so that we don't need to bump
it every year.
It seems like only the first year of publication is technically
relevant for copyright notices, and even that seems to be something
that many companies stopped listing altogether (in a version controlled
codebase, the commits are a much better source of date of publication
than a hardcoded copyright statement).
We also now list Godot Engine contributors first as we're collectively
the current maintainers of the project, and we clarify that the
"exclusive" copyright of the co-founders covers the timespan before
opensourcing (their further contributions are included as part of Godot
Engine contributors).
Also fixed "cf." Frenchism - it's meant as "refer to / see".
* Map is unnecessary and inefficient in almost every case.
* Replaced by the new HashMap.
* Renamed Map to RBMap and Set to RBSet for cases that still make sense
(order matters) but use is discouraged.
There were very few cases where replacing by HashMap was undesired because
keeping the key order was intended.
I tried to keep those (as RBMap) as much as possible, but might have missed
some. Review appreciated!
Forcing draw during debug break is now handled by ServersDebugger, and
only happens when the proper message is sent from the EditorDebugger
("servers:draw").
In a similar way, briging the window in foreground is now also handled
by ServersDebugger upon receiving "servers:foreground" which is sent by
the EditorDebugger when resuming from a break ("continue").