gaijinentertainment/quirrel

Quirrel - Gaijin Entertainment dynamic script language

quirrel's Issues

Get script function from native not working anymore with sq_compile()

With the removal of this part:
fd46233#diff-3ce5ab9909a4ebc05d8c2da9a58ebc7f92713705f952b89b80e8619e9ae8900dL387-L398

the ability to get script functions with sqrat broke for me (Using the latest sqrat with m_rootTable->GetFunction()).
The root table keys before the commit included the "function" lines from scripts, afterwards it seems to be only native. Is there another way to get the functions (for Sqrat::Function)? Couldn't find it in the documentation.

Thanks!

string_view is not enabled under visual studio (__cplusplus is always 199711L)

#if __cplusplus >= 201703L
using string_view = std::basic_string_view;
#else
using string_view = string;
#endif

"The /Zc:__cplusplus compiler option enables the __cplusplus preprocessor macro to report an updated value for recent C++ language standards support. By default, Visual Studio always returns the value 199711L for the __cplusplus preprocessor macro."
https://learn.microsoft.com/en-us/cpp/build/reference/zc-cplusplus

Seems to be the same for sqrat

---

Even if the __cplusplus is correct the default C++ language standard for VS 2019 is C++14.
cmake has set(CMAKE_CXX_STANDARD 11) but it should probably be 17 now (for string_view)?

Evaluate using Profile-Guided Optimization (PGO) and LLVM BOLT

Hi!

Recently I checked Profile-Guided Optimization (PGO) improvements on multiple projects. The results are here. E.g. PGO results for LLVM-related tooling are here. According to the tests, PGO usually helps with the compiler and compiler-like workloads (like static analysis) - e.g. Clang gets +20% compilation speed with PGO, CPython achieves +10% in pybench. So I think optimizing Quirrel tooling (like VM, compiler and the static analyzer) with PGO would be a good idea at least to try.

I can suggest the following action points:

• Perform PGO benchmarks on the Quirrel tooling. If it shows improvements - add a note about possible improvements in Quirrel's performance with PGO.
• Providing an easier way (e.g. a build option) to build scripts with PGO can be helpful for the end-users and maintainers since they will be able to optimize the Quirrel tools according to their own workloads.
• Optimize pre-built binaries with PGO

Testing Post-Link Optimization techniques (like LLVM BOLT) would be interesting too (CPython, Clang, and Rustc already use BOLT as an addition to PGO) but I recommend starting from the usual PGO.

Here are some examples of how PGO optimization is integrated in other projects:

• ISPC: CMake scipts
• Rustc: a CI script for the multi-stage build
• GCC:
  • Official docs, section "Building with profile feedback" (even AutoFDO build is supported)
  • A part in a "wonderful" configure script
• Clang: Docs
• Python:
  • CPython: README
  • Pyston: README
• Go: Bash script
• V8: Bazel flag
• ChakraCore: Scripts
• Chromium: Script
• Firefox: Docs
  • Thunderbird has PGO support too
• PHP - Makefile command and old Centminmod scripts
• MySQL: CMake script
• YugabyteDB: GitHub commit
• FoundationDB: Script
• Zstd: Makefile
• Foot: Scripts
• Windows Terminal: GitHub PR
• Pydantic-core: GitHub PR
• file.d: GitHub PR
• OceanBase: CMake flag
• NodeJS: Configure script

The same issue was created for daScript since these two projects can have different lifecycles, priorities, and PGO can be tested and integrated into them independently.

Most tests fail if the CLOSURE_HOISTING_OPT ("-optCH") is disabled in testRunner.py

The CLOSURE_HOISTING_OPT is off by default in quirrel. Is it required now?
Compiled with Visual Studio 2019.

Thank You!

SQLexer::LexSingleToken() processes tabs ('\t') as a single space

causes the underliner pos to be off.

Could be just 4 spaces for now?

#define NEXT_TAB() {Next();_currentcolumn += 4;}

case _SC('\t'): _flags |= TF_PREP_SPACE; NEXT_TAB(); continue;

---

Best would probably if it counts the tabs and the underliner prints them.

quirrel failed to compile with MinGW

The problem is unrelated to msys2 as previously thought. Using cmake with ninja generator and a standalone MinGW distro (winlibs.com in my case), it failed to compile. Too many output displayed on the screen, I saw full of warnings but can't find any errors so I don't know what is the errors that caused this. Maybe I just missed it.

sqratLite.h (from sqmodules.h) clashes with sqrat

A lot of xxx already declared messages.

The comment at the top in sqmodules.h also states:
/*
This is not a production code, but a demonstration of concept of modules
*/

is this still the case? :)