Skip to content

refactor: signal instead of busy-wait, debug call stack, immutable const bindings, string interpolation, linter fixes#40

Open
itsrenderman wants to merge 1 commit into
devSparkle:mainfrom
itsrenderman:refactor/signals-debug-consts-interpolation-linter
Open

refactor: signal instead of busy-wait, debug call stack, immutable const bindings, string interpolation, linter fixes#40
itsrenderman wants to merge 1 commit into
devSparkle:mainfrom
itsrenderman:refactor/signals-debug-consts-interpolation-linter

Conversation

@itsrenderman
Copy link
Copy Markdown
Contributor

@itsrenderman itsrenderman commented May 26, 2026

Library Loading

  • Use signals instead of threads and coroutine library.
    This eliminates the need to defer library loading.
  • Replace array of data dictionary with a map of module name indices and arrays of BindableEvents.
    This allows for faster retrieval of signals to indicate to LoadLibrary calls that the module is loaded, as we do not need to iterate over the whole cache.

Debugging

  • Replace busy-wait "infinite yield" warnings with BindableEvent signals
    Eliminates need to loop over the cache table every second which (especially during start-up) could cause performance degredation.
    Also eliminates need to delay cache removal by 1 second which (I believe) was previously done for debug logging purposes.
    Allows the "Debug" attribute to be changed during runtime and accordingly reflect onto newly loaded libraries.
    (I assume we do not want to rely on packages such as sleitnick/signal, to maintain a simple installation process without requiring Wally, hence BindableEvents)

  • Print the current function call stack to console when "infinite yield" warnings are logged.
    YouTube: Example of call stack logging
    This message has been constructed to resemble the default studio infinite yield warning message.
    Unfortunately the blue info text can currently only be achieved via TestService, though Engine API release 717 suggests we may be able to use LogService:Info in the future.

Immutable Constant Bindings

  • Replace local variable assignments to const binding declarations wherever appropriate.
    This newly available Luau declaration is great at informing code maintainers and readers that the variable is not going to be re-assigned during runtime.
    This declaration can also prevent unintented consequences of variable re-assignment, where perhaps specific parts of the code may not be expecting a variable to change.

Miscellaenous

  • Use string interpolation over string.format.
    String interpolation is generally favored nowadays over string.format for any interpolation that doesn't require formatting specifiers or flags, usually for number representation.

  • Function return types.
    Some methods didn't include their return type, but still opted to document it for Moonwave.
    All functions now properly indicate their return type, which is automatically detected by Moonwave.

  • Linter fixes.
    The formatting now adheres to the default customs set out by selene and luau-lsp.
    The defaults may not be favored by everyone, but following them does improve readability and (importantly) consistency.

…nst bindings, string interpolation, linter fixes
@itsrenderman
Copy link
Copy Markdown
Contributor Author

Just a few changes I thought might be cool to include in Overture. Lmk! 😄

@devSparkle
Copy link
Copy Markdown
Owner

That's an awesome group of changes! I'm still going to test performance and check for edge cases, but just a quick aside:

Moonwave was crashing when processing a file containing const, has this been fixed by them?

@itsrenderman
Copy link
Copy Markdown
Contributor Author

itsrenderman commented May 27, 2026

Moonwave was crashing when processing a file containing const, has this been fixed by them?

  • I tested building & running Moonwave and experienced no issues. With const being so new though, maybe it would be worth holding off migrating to it until it is more reliably supported within the Roblox development ecosystem?
    Afaik tools like Selene, luau-LSP and Moonwave support const, though I am experiencing an issue where the keyword is being coloured/formatted improperly in VS code (first world problems).
    Although the above is not a huge concern, it is worth considering that other toolings may not yet fully support const and if someone updates to a version of Overture which uses const, but another one of their packages/tools doesn't recognise it yet, it could cause issues.

That's an awesome group of changes!

☺️

I'm still going to test performance and check for edge cases

  • I have conducted personal testing using these changes as I am currently migrating Area 14's codebase to support modern Overture for a performance update.
    So far I've experienced no performance degradations or stability issues, if anything it has helped make the game load faster - though I do not have stats on hand to prove this.
    Hopefully this large codebase has already covered any problems that could arise with stability and performance but I look forward to your findings and seeing if my code is reliable. 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants