ScriptX
ScriptX copied to clipboard
Tencent
A versatile script engine abstraction layer.
如题，至今引擎加载源码都只能依靠读取文件然后eval，在适配其他引擎过程中此种加载方式会带来一些困扰 比如 - V8 engine 和 embedded NodeJs 需要使用.mjs后缀判定此文件为ES Module文件，以启动ES Module支持 - Python解释器用import可以更方便地实现实例隔离，而非使用其标准中尚不太完善的subinterpreter - 等等 因此有必要为Engine.h提供支持加载指定路径文件的eval，并在不同引擎做特殊处理
调用栈： - Engine.hpp:39 是把引擎类型从ScriptEngine向下转型为V8Engine, scriptDynamicCast返回了NULL; - 工程开启了rtti, scriptDynamicCast的实现使用了dynamic_cast; scriptDynamicCast参数类型： R: V8Engine T: ScriptEngine scriptDynamicCast里测试代码来看： - 使用static_cast 转换时t_static_cast非空； - 使用dynamic_cast 转换时t_forward_dynamic_cast 为空； 请问是否scriptDynamicCast的实现在向下类型转换时有问题？
请问如何配置python单元测试？ ```md ######## ScriptX config ########## # 1. import ScriptX # set which backend engine to use set(SCRIPTX_BACKEND Python CACHE STRING "" FORCE) ``` 我将test文件夹的cmake改成这样 结果编译时仍有v8的引用 配置cmake时我发现有仓库的克隆 但是文件里面我并没有发现git链接 就感觉很奇怪
# WIP > 功能已经全部编写完毕并经过社区项目实际运行检验（https://github.com/LiteLDev/LiteLoaderBDS） > github actions测试还有些小问题（少量内存泄漏等），最近将修复，请暂时不要合并此PR # 概况 如题，为ScriptX完成了Python后端支持。 此PR包含：完整的Python适配、针对Python测试进行适配的UnitTest、docs中的增加的双语文档。提交的代码去除了所有的私有commit，仅包含完整的适配代码。 # 测试情况 Windows下使用MSVC编译，单元测试全部通过： 在Ubuntu使用GCC编译，单元测试全部通过： 运行性能还麻烦作者大大亲自测试，截图时开着好几个IDE，机子负载较大，导致单测运行时间较长 经实际运行环境测试引擎工作正常。如果有什么需要修改的还请提出，我们将继续进行修改。 # TODOs 现在剩余一些TODO需要协助，这些操作我们无法自行完成 1. 在合并此PR之前，需要首先通过一下另一个PR https://github.com/LanderlYoung/ScriptXTestLibs/pull/3 这个PR上传了编译工具链自动下载的python头文件以及库文件。缺失这些会导致github actions中的单元测试无法正常编译通过。 2. 由于手头没有Mac设备，因此TestLib仅附带了win64、linux64的CPython头文件和库，未对Mac版进行编译测试。如果需要的话您可以按下面的步骤提供Mac适配： 1. 去项目 https://github.com/indygreg/python-build-standalone/releases...
开发环境是VS2022 C++20 void exportHostAbility(const std::shared_ptr& engine) { using host_ability::HostImage; // wrapper inherits from HostImage and ScriptClass class HostImageWrapper : public HostImage, public script::ScriptClass { public: using script::ScriptClass::ScriptClass; }; static script::ClassDefine...
使QuickJS可以正常使用ESM的import和export机制。默认的JS_EVAL_GLOBAL不支持ESM，此处修改为JS_EVAL_MODULE，并加载了qjs-libc默认提供的es6 module loader. 经过测试可以完全正常工作。 其次，JS_EVAL_MODULE的行为与JS_EVAL_GLOBAL不同。JS_EVAL_GLOBAL在执行多行JS代码时，会将最后一行代码的返回值作为整个eval调用的返回值，而JS_EVAL_MODULE不会这样。这个也可以理解，因为module是针对文件调用而设计的。 （同样的，python backend的eval和文件加载也具有和上述完全一样的行为） 因此，为了解决这两种 **读取文件执行** 与 **普通eval** 语义不同的问题，又联想到 #89 issue，为各引擎增加了一个loadFile函数，针对loadFile的特殊情况进行处理，与普通的eval分开。 不需要特殊处理的引擎的loadFile将读取文件后直接调用eval。
With this simple changes in these two files are possible to acess the QuickJs `std` and `os` modules (these modules seems to work on any plataform, i have tested it...
