Is it hard to update spidermonkey?

[Sturm]

Pls, allow me one of those boring questions from non-developer people.  Why not update Spidermonkey to even newer versions? Is this a very arduous task?

[asterix]

45 minutes ago, Sturm said:

Pls, allow me one of those boring questions from non-developer people.  Why not update Spidermonkey to even newer versions? Is this a very arduous task?

I believe most precise answer have either @Stan` or @wraitii since they usually did those upgrades. Also the commit was right when feature freeze started. Main reason is that wraitii already provided the patch and as of this writing, it is the last long term support version. Yes it is arduous task since it needs to be tested a updated a lot of code of 0ad see e.g. 

 

[Stan`]

2 hours ago, Sturm said:

Pls, allow me one of those boring questions from non-developer people.  Why not update Spidermonkey to even newer versions? Is this a very arduous task?

There are multiple factors to take into account. Some updates require a lot of changes on our end,  so that takes time, some have unintended side effects, some are okay, but distributions changed in the meantime. And since the whole game relies on it, and all Oses must have the same version it can be a bit tricky to get it right.

[Bellaz89]

On 21/01/2023 at 8:22 PM, Sturm said:

Pls, allow me one of those boring questions from non-developer people.  Why not update Spidermonkey to even newer versions? Is this a very arduous task?

Hi. I did some tests in the past in porting 0ad to SM68/78 before the support was officially added by the core team. You might remember the following threads

The biggest challenges I faced back then were(added to points already raised):

1. Spidermonkey's team policy is not to keep a stable c++ API from version to version. In fact, for that upgrade, the hierarchy of SM classes (roles, responsibilities, meaning) was deeply changed. Since Spidermonkey is the backbone of 0ad, any big change in the former requires rethinking the structure of the latter. And this is particularly difficult when you need to change several thousands lines of code (without introducting bugs at the same time).
2. Spidermonkey is not really meant IMHO to be used as an embedded interpreter by the general public (unlike e.g. Lua). The documentation is lacking at best(at least, this was the situation 2 years ago), and some features can only be discovered by looking at the library headers. TBH some efforts wre done done to change the situation https://github.com/mozilla-spidermonkey/spidermonkey-embedding-examples but still, there is not a complete coverage of the API. On top of that, there is not much consistency between various parts of the API. I would say that even after having spent several hours at looking at SM sources, the meaning of many classes/functions is still very obscure to me.
3. Due to 2. and the fact that SM is a very complex piece of software, you can end up after changing thousands of lines with a project that explodes for inexplicable reasons. Usually this is because the API was used in the wrong way. It might also be a bug in SM. In both cases good luck figuring out the reason
4. For that upgrade, also some Javascript API changed.
5. Some tuning assumptions done on the older versions of the interpreter might not be valid in the newer versions. So further profiling and even more source digging is required.

Hopefully future changes will be less dramatic than the huge jump to v68/78 . But I bet it is still not going to be a 'plug-n-play' change.

Said that I am very happy that a project like SM (and Firefox) exists these are great piece of software that I use everyday. Also, when looking for a scripting language/VM pair that is both well known by many people, high performance and portable, there is not much choice out there.. (Mono? V8? LuaJIT? JVM?)

Edited March 5, 2023 by Bellaz89