All ToJSVal/FromJSVal definitions are put in a separate header.
Remove AssignOr[To/From]JSVal duplication.
The functions were already static so this is rather straightforward.
Follows 34b1920e7b and 2bae30c454
Differential Revision: https://code.wildfiregames.com/D3953
This was SVN commit r25428.
Finishes work started in f3aedf88a6.
This removes the boost-CPP function wrappers entirely, in favour of pure
templated code in FunctionWrapper.h
The Call* functions were already heavily templated, so there is nothing
really new here. I just use tag dispatch to reduce the number of
overloads slightly.
The new functions do not need the script interface, only the script
request.
Differential Revision: https://code.wildfiregames.com/D3912
This was SVN commit r25354.
This is the same commit as 4bb31f084e, reverted in 5d1899785a. Noted
issues were fixed.
Partial revert/fix of 2f19cf86d3 and 2567fee329.
Before this diff, it was possible for a mod containing a cache/ or a
config/ folder to get written to incorrectly.
The issue is VFS can map multiple directories to one 'virtual' path, for
reading mods. However, writing data is problematic: which path to
choose?
The only viable solution is to use a path relative to the highest
priority directory encountered in the VFS path, or write paths could be
'hijacked' by lower-priority mods.
This fixes these issues by:
- Adding a new lookup mode ('Real-path') that explicitly picks the real
path relative to the highest-priority subdirectory in the VFS Path.
- Preventing overwriting a real directory with a lower priority one in
general.
- Revert c0c8132dd4's GetRealPath change, re-introducing the function as
GetOriginalPath.
This also cleans up some duplication that led to empty mod folders in
the user mod path, and cleans up loading the 'user' mod.
It also makes it explicit that a directory must be passed to Mount().
Note that the new 'realpath' lookup can still be somewhat complex with
many mount points at various hierarchy levels, but it is at least
predictable/deterministic without having to be careful about populating
order.
Fixes#2553
Differential Revision: https://code.wildfiregames.com/D3728
This was SVN commit r25107.
- Check for pending exceptions after function calls and script
executions.
- Call LOGERROR instead of JS_ReportError when there is a conversion
error in FromJSVal, since that can only be called from C++ (where JS
errors don't really make sense). Instead, C++ callers of FromJSVal
should handle the failure and, themselves, either report an error or
simply do something else.
- Wrap JS_ReportError since that makes updating it later easier.
This isn't a systematical fix since ToJSVal also ought return a boolean
for failures, and we probably should trigger errors instead of warnings
on 'implicit' conversions, rather a preparation diff.
Part of the SM52 migration, stage: SM45 compatible (actually SM52
incompatible, too).
Based on a patch by: Itms
Comments by: Vladislavbelov, Stan`
Refs #742, #4893
Differential Revision: https://code.wildfiregames.com/D3093
This was SVN commit r24187.
SM52 essentially replaces JSRuntime with JSContext (though JSContext
itself was replaced with JSCompartment).
To prepare for this migration, rename all Runtime-related things to
Context.
Part of the SM52 migration, stage: SM45 compatible.
Patch by: Itms
Refs #4893
Differential Revision: https://code.wildfiregames.com/D3091
This was SVN commit r24181.
ScriptInterface is now a wrapper around a JSCompartment, and thus always
has a well-defined global.
The error reporter is moved to ScriptRuntime in anticipation of that
handling JSContext in a later diff.
Part of the SM52 migration, stage: SM45 compatible.
Patch by: Itms
Tested By: Freagarach
Refs #4893
Differential Revision: https://code.wildfiregames.com/D3090
This was SVN commit r24180.
JSAutoRequest is required before calling into most JSAPI methods, for GC
reasons.
Calling it is required and fragile as one must not forget.
Further, SM52 and later make manipulating JSContext* dangerous as that
can cross Compartment(Realm in SM68) barriers (and ScriptInterface now
matches a Compartment).
The solution to both problems is to avoid using JSContext* in 0 A.D.
itself. To achieve this, a Request class is introduced, and must be used
to access a JSContext* from a scriptInterface. Further, Request is
passed to other ScriptInterface functions isntead of JSContext*, making
it obvious that the caller has already called it, reducing errors and
redundant JSAutoRequest calls.
Only JSNative functions now get a naked JSContext* without protection,
but the likelihood of forgetting a request is lower since many
ScriptInterface functions now expect it.
JSContext* is directly passed to JSAPI functions only.
Part of the SM52 migration, stage: SM45 compatible
Based on a patch by: Itms
Tested By: Freagarach
Refs #4893
Differential Revision: https://code.wildfiregames.com/D3088
This was SVN commit r24176.
SpiderMonkey uses UTF16 internally, and only provides APIs for that
encoding, so stop hacking UTF8 strings: properly convert them to and
from UTF16 when passing them through SM.
Patch By: wraitii
Differential Revision: https://code.wildfiregames.com/D2838
This was SVN commit r23795.
Remove unused SGUIBaseSettings and GUI comment.
Fix indentation of a macro, refs D794.
Differential Revision: https://code.wildfiregames.com/D838
Review by: leper.
Itms came up with the same patch for the SpiderMonkey 45 update
independently.
This was SVN commit r20062.
64bit conversions (including the long ones) are not safe, because not
every number can be converted to the 2^53 JS numbers and pretending to
do so is asking for bugs.
Explicitly use the double type in the Replay menu, because std::time_t
is unspecified and some platforms like Ubuntu yakkety:i386 fail to
build, looking for long.
Double should work for the next 285 million years, becomes consistent
with SavedGame.cpp, is tested by test_ScriptConversions.cpp and doesn't
pretend to cover all 64bit numbers.
Patch By: echotangoecho
Differential Revision: https://code.wildfiregames.com/D205
Refs #3848 D84 D112
This was SVN commit r19367.
Template-ize CallFunctionVoid.
Changes CallFunction parameter order to make template parameter
deduction with
variadic parameters work nicely.
Reviewed By: Itms, wraitii, Yves
Differential Revision: https://code.wildfiregames.com/D77
This was SVN commit r19183.
Changes CallFunction and CallFunctionVoid to use a HandleValue as object
parameter. Also changes some JS serialization/deserialization functions
to only support the JSAPI rooted types (drop support for CScriptVal and
CScriptValRooted there). Some other functions got changed too because
they were closely related.
Refs #2415
Refs #2462
This was SVN commit r15592.
JS::MutableHandleValue is similar to JS::HandleValue, but the whole
JS::Value it points to can be replaced.
This change is needed for support of exact stack rooting and moving GC.
Contains a few other trivial API adjustments and style improvements too.
Refs #2462
Refs #2415
This was SVN commit r15534.
JS::HandleValue is basically a wrapper around a JS::Value that is safe
for exact stack rooting and moving GC.
I've tried to keep this changeset rather small and isolated and
therefore create additional JS::Rooted<T> values at some places where
the function should eventually directly take a JS::Handle<T>.
The functions "CallFunction" and "CallFunctionVoid" put their arguments
inside a JS::AutoValueVector because this will be passed directly to
"CallFunction_" with ESR31.
Refs #2462
Refs #2415
This was SVN commit r15517.
The tests crashed on my Debian systems but not on my Ubuntu system.
The crash happened in line 142 of SpiderMonkey's ThreadLocal.h.
I know that I had to use a workarounnd for contexts to avoid destroying
the context that was created first. I also had in mind that in newer
versions a JS_Init function got introduced which presumably solves this
kind of issues.
Based on this experience I assumed runtimes could have a similar problem
and this patch indeed fixes the issues.
Unfortunately the correct usage of JSRuntimes in that regard is not
documented.
There's only a rater misterious comment in JSAPI.h which hasn't been
cleared up so far and is most likely completely outdated
(https://bugzilla.mozilla.org/show_bug.cgi?id=992641).
This was SVN commit r14995.
This commit contains all the required changes to our source files and
build scripts (hopefully).
A next commit will remove the old stuff of SpiderMonkey 1.8.5.
Spcial thanks to:
- H4writer who helped a lot mainly with the performance issues we
had/have, but also with other problems or questions.
- Leper for the review.
- Historic_bruno for implementing the build scripts on Mac OS X and
testing on the Mac.
- The people from the #jsapi channel and from
mozilla.dev.tech.js-engine who answered a lot of questions and helped
solving problems.
- All the other people who helped
Refs #1886Fixes#2442Fixes#2416
This was SVN commit r14877.
Handle AIProxy entirely through scripts.
Support structured clones of script values.
Improve performance.
Support multiple script contexts sharing a runtime.
Use a separate context per AI player.
This was SVN commit r8866.
wposix: Define int8_t compatibly with SpiderMonkey.
Remove unused camera, lightenv JS interfaces.
Remove most of vector JS interface.
Remove some of the redundant JS string conversion functions.
Remove unneeded vmem, _lodBias functions.
Clean up some formatting.
This was SVN commit r8629.
Giant merge from
http://svn.wildfiregames.com/hg-source/file/5fb522019d5e
Infrastructure is largely complete, gameplay is largely missing
Disabled by default; use command-line flag "-sim2"
(Second attempt at commit...)
This was SVN commit r7259.
