Godot: Integrate javascript support as scripting language

[yuri-karadzhov]

As javascript is well known and really popular language it will be grate for godot to implement it as scripting language. As godot already supports C it can be done with help of this project http://duktape.org/

[reduz]

I'd rather programmers learn GDScript and then have a good experience, than
use something they know and then have a bad experience, so probably never
going to happen.

On Sun, Dec 7, 2014 at 1:48 PM, Yuri Karadzhov [email protected]
wrote:

As javascript is well known and really popular language it will be grate
for godot to implement it as scripting language. As godot already supports
C it can be done with help of this project http://duktape.org/

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/937.

[reduz]

even if it means they'd rather not use Godot

On Sun, Dec 7, 2014 at 3:41 PM, Juan Linietsky [email protected] wrote:

I'd rather programmers learn GDScript and then have a good experience,
than use something they know and then have a bad experience, so probably
never going to happen.

On Sun, Dec 7, 2014 at 1:48 PM, Yuri Karadzhov [email protected]
wrote:

As javascript is well known and really popular language it will be grate
for godot to implement it as scripting language. As godot already supports
C it can be done with help of this project http://duktape.org/

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/937.

[yuri-karadzhov]

I believe as an option it's not a problem to provide js syntax and precompile it to gdscript. There is no big difference between these languages. It seems API is the one that matter.

[SuperUserNameMan]

I've discovered Godot rencently, and learning GDscript syntax and its special features was easy and fast.
The only thing that I missed was the switch/case statement and the C++ multiline comment, mainly because I'm too lazy to replace them with if/then/else and a # for each line.

I'd be curious to know what features you miss from JS in GDscript ?

[godotengine]

you can use multiline comments python style with """

On Sun, Dec 7, 2014 at 6:03 PM, UsernameIsAReservedWord <
[email protected]> wrote:

I've discovered Godot rencently, and learning GDscript syntax and its
special features was easy and fast.
The only thing that I missed was the switch/case statement and the C++
multiline comment, mainly because I'm too lazy to replace them with
if/then/else and a # for each line.

I'd be curious to know what features you miss from JS in GDscript ?

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/937#issuecomment-65954920.

_OkamStudio_

[SuperUserNameMan]

@okamstudio : thanks for the info ! I'll test it more seriously tomorrow, because I tried 3 " at the begining, and 3 others " at the end, and the editor just told me : Parse Error : Unexpected token: Constant:.

[yuri-karadzhov]

@UsernameIsAReservedWord Personally I do not care about the language itself and look at API, but in terms of community it can be good to have support of popular languages.

[reduz]

The problem is that it's impossible to use an existing VM and have it work
as well as GDScript, the experience will be worse and that is undersired

On Sun, Dec 7, 2014 at 6:25 PM, Yuri Karadzhov [email protected]
wrote:

@UsernameIsAReservedWord https://github.com/UsernameIsAReservedWord
Personally I do not care about the language itself and look at API, but in
terms of community it can be good to have support of popular languages.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/937#issuecomment-65955849.

[yuri-karadzhov]

Got it, it is hard to support two VM simultaneously. But instead it is possible to use preprocessor that compiles JS to GDScript or C++ directly. Probably it will be possible to use some kind of source map for debugging.

[reduz]

It's not really a problem of supporting two VMs, Godot is well designed for
that (and for a long time GDScript and Squirrel both worked).
The problem is that godot expects a lot from VMs, and most (lua, python,
JS, etc) can't deliver, such as:

-ability to run in multiple threads and share a context (most VMs are stack
based so this fails)
-ability to use vector types efficiently (most fail at this)
-ability to run in interpreted mode if JIT is not supported (most JS VMs do
not support this)

This rules out pretty much everything,

I think it's more attractive to have something that works, even if you have
to learn a new language, than having something patched up that does not
deliver or is inconsistent, even if familiar to existing users.

On Sun, Dec 7, 2014 at 6:46 PM, Yuri Karadzhov [email protected]
wrote:

Got it, it is hard to support two VM simultaneously. But instead it is
possible to use preprocessor that compiles JS to GDScript or C++ directly.
Probably it will be possible to use some kind of source map for debugging.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/937#issuecomment-65956661.

[adolson]

@UsernameIsAReservedWord - in addition to the multiline comment reduz mentioned, you can toggle comment on many lines all at once by just highlighting all the lines, then press Ctrl+/
This will work in the most recent devel and stableRC releases, and newer.

[SuperUserNameMan]

@adolson : thanks for this info ! I tried Alt+/ with RC1, but it did not work. Maybe because I'm using an AZERTY keyboard ?

@okamstudio : I tried the python style multiline comment again. It seems to work only inside functions, though the editor does not highlight all the lines in brown.
Outside func, the editor complains about an Unexpected token constant.
Duno if it's a normal behavior, or if RC1 is already outdated compared to all the recent fixes and pushes in the github ? Should I open an issue about this ?

[adolson]

@UsernameIsAReservedWord - sorry, I meant Ctrl+/ - try that! (will update earlier comment as well)

[SuperUserNameMan]

@adolson : this works ! thanks !

[korinVR]

JavaScript is popular, but not a good language for 3D. I don't think there is a merit to specifically support it on game engines.

There is an insightful article about that.

"JavaScript and 3d graphics don't mix"
http://mortoray.com/2014/01/06/javascript-and-3d-graphics-dont-mix/

[yuri-karadzhov]

This article actually proves nothing. The same problems appears in many other languages. JS 7 will have types ad operators overloading (UnityScript and ActionScript have them already, but GDScript don't). And when it comes to performance - there is no such concept as language performance, instead there is VM performance. So there is nothing wrong with language itself but the author appears to have some troubles with three.js API and modern browsers.

[korinVR]

GDScript has built-in Vector/Matrix types. It solves the problems written in the article elegantly. That the reason you don't need operator overloading in GDScript.

ActionScript does not have operator overloading. As for ECMAScript 7 types, I don't believe it will be available within 5-10 years. And even UnityScript has operator overloaded geometry classes, almost all Unity users use C#.

JavaScript is a great language, but it is not for games. C/C++, C# and some script languages (like Lua or GDScript) are popular in the game industry.

[yuri-karadzhov]

The same way you can make realization of Vector/Matrix types and use them in JS. So the article mostly mentioned problems of tree.js.

It does not matter when ES7 comes to browser, we talk about language not browsers or VMs. Thats not true many Unity users use UnityScript for supplementary tasks. However due to lack of convinient class system they prefer C# for more serious tasks (but still it's not a problem of JS).

Few years ago it was not for servers or desktop app, and now we have cocos2d and can use JS for everything. JS is not worse or better then python, lua or other general purpose script language, so it's only a question is ES standard suits Godot execution model and should we use this standard or may be we can use just syntax for decresing learning curve.

[korinVR]

I don't think you understand the problems well. It is sure there are a number of 2D games written in JavaScript, but a bit complex game physics will bring you into hell easily (therefore I prefer Cocos2D-x rather than the JavaScript binding). And when it comes to 3D, the complexity increases exponentially. It's the problem of the language itself, not Three.js's.

But at least ECMAScript 7 is going to address the issue. Probably time will tell.

[yuri-karadzhov]

I don't think you understand the answer and the ticket itslef.

And when it comes to 3D, the complexity increases exponentially

This is nonsense, it increases linearly.

Talking about the article:

1. By reference assignment - the same in C# and other high level languages
2. Lack of type safety - same in every dynamic languages (ES7 will have it)
3. No (operator) overloading - ES7 will have it
4. Performance - have sense only if we discuss VM

So, as I wrote before, we can use ES7 syntax right here and right now and precompile it to GDScript with some source map.

[reduz]

let me put it simply:

if you want to contribute this yourself and make sure you maintain it until
it's bug-free, and help everyone having problems with it, then fine.

Otherwise I think there are way too many things that are more important to
dedicate time to.

On Mon, Dec 29, 2014 at 10:35 AM, Yuri Karadzhov [email protected]
wrote:

I don't think you understand the answer and the ticket itslef.

And when it comes to 3D, the complexity increases exponentially
This is nonsense, it increases linearly.

Talking about an article:

1. By reference assignment - the same in C# and other high level languages
2. Lack of type safety - same in every dynamic languages (ES7 will have it)
3. No (operator) overloading - ES7 will have it
4. Performance - have sense only if we discuss VM

So, as I wrote before, we can use ES7 syntax right here and right now and
precompile it to GDScript with some source map.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/937#issuecomment-68253869.

[yuri-karadzhov]

@reduz definetly, there are many things that most important than JS in godot. I am able to write precompiller which translate ES7 syntax to GDScript, but I won't have time to support it properly and integrate debugging into godot. So that was idea for others to implement and discussion that there is nothing wrong with JS.

I believe some day it can come to life.

[akien-mga]

Archiving as this likely won't be implemented based on a feature request. Support of additional languages has been discussed many times, but it's not a priority right now.

[rosshadden]

I didn't see it mentioned anywhere here so I wanted to point out that the absolute best reason to use an existing, standardized language is that they tend to have well-established ecosystems. This is more true for JavaScript than any other such language, as npm is currently the biggest package repository in existence. When you add the fact that the language itself is battle-tested, evolving, and that ES2015/2016/2017 are _very_ well-suited for gamedev, I don't think it's smart to just write it off. I would go as far as to say that ideally JS should be the _only_ language supported, but of course I know that would be too abrasive a request and get immediately rejected.

I know you hear complaints and requests for this a lot, and I really do respect that there are things on your plate that you feel are more important than this. So really, I want to know how you would feel if we the community attempted to implement it ourselves. From the perspective of an outsider to godot, having to use what many people would label a "dead-end language" because it's only ever going to be for this specific application, is by far the biggest turn-off. If you are not going to consider such efforts I don't want to waste my time, but if you are not opposed to it two years after this issue was opened (a two years that has seen amazing progress in the EcmaScript standard I might add), I might try to lead the charge and rally people to help me.

[reduz]

It is not technically possible to do this, it was explained several times
why. It's in the docs and the FAQ.

On Sat, Dec 31, 2016 at 3:12 PM, Ross Hadden [e-mail]
wrote:

I didn't see it mentioned anywhere here so I wanted to point out that the
absolute best reason to use an existing, standardized language is that they
tend to have well-established ecosystems. This is more true for JavaScript
than any other such language, as npm is currently the biggest package
repository in existence. When you add the fact that the language itself is
battle-tested, evolving, and that ES2015/2016/2017 are very well-suited
for gamedev, I don't think it's smart to just write it off. I would go as
far as to say that ideally JS should be the only language supported,
but of course I know that would be too abrasive a request and get
immediately rejected.

I know you hear complaints and requests for this a lot, and I really do
respect that there are things on your plate that you feel are more
important than this. So really, I want to know how you would feel if we the
community attempted to implement it ourselves. From the perspective of an
outsider to godot, having to use what many people would label a "dead-end
language" because it's only ever going to be for this specific application,
is by far the biggest turn-off. If you are not going to consider such
efforts I don't want to waste my time, but if you are not opposed to it two
years after this issue was opened (a two years that has seen amazing
progress in the EcmaScript standard I might add), I might try to lead the
charge and rally people to help me.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/937#issuecomment-269876297,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2_bEHG5znPCuXg08JCJ5-2MFwOTcks5rNpr7gaJpZM4DFSv6
.

[bojidar-bg]

@rosshadden Well, you are welcome to implement it as a module -- there is no way we can stop you :wink:

If you do it, we would be happy to advertise it around, and, maybe, some day have semi-official modules build with it.

That being said, I would like to note that to me, JS is a dying language in agony -- IHMO it is a ship to stay away from, just so that if it sinks, it won't take your vessel with it to the bottom. That is obviously my personal opinion, which nobody has to take. Still, too much hype, way too many libraries and plenty of community divisions (plus even more plenty of languages to compile to and fro to it), and adding a mix of new features in ES6/7 while supporting the previous ones is going to make even more libraries, and more hype and more community divisions (IMO).
(Again, this is here just as a 2¢ -- I don't really think it would be constructive to discuss at all, just something I would like others to keep in mine)

[AbhimanyuAryan]

javascript as a language is picking really fast

• Clean Syntax(ES5, ES6, ES7)
• Web Frameworks(React, React360, ThreeJS, AFrame)
• Machine Learning & Deep Learning(TensorFlow JS)
• Data Visualization (D3)

It's growing exponential and Javascript has a huge developer community. If Godot picks Javascript there is huge chance that of other JS developers to contribute to this project including employees from Google/Mozilla

Also, Unity has ML-Agent which is the future of robotics and so many things. We should definitely move GODOT to that area of AI & Simulations

Future is JS not GodotScript or C#

[AbhimanyuAryan]

I'll try to reimplement GODOT in Javascript. I don't know if that's possible or not but now I have set my intention. Nothing will change if you change nothing 💯

[AbhimanyuAryan]

My vision is that Godot should get as modular as any other JS module

npm install -g godot-animation
npm install -g godot-cinemachine

Even if you are building WebGL games you should be able to mix React Native code in that to build better game UI for iOS/Android

I don't know how to begin but I think I'll have to write down my entire plan on white sheet of paper and build a solid plan before I begin to code this bad boy :)

[vnen]

I'll try to reimplement GODOT in Javascript.

Well, I'm not sure if this even possible. Assuming you want to run on a browser with WebGL it might be, but it's a very huge endeavor, there's a lot of code to port. Especially if you consider all the dependencies.

Now, if you want just to use JavaScript inside Godot as a scripting language, you don't need to reimplement anything, just create a module with a custom language, or use PluginScript (which is used for the Python scripting support).

[etamity]

I have been doing research about embed V8 engine into game engine.
https://www.reddit.com/r/gamedev/comments/52tlqu/integrating_v8_into_your_game_engine/

[vnen]

Well, it's not something I haven't tried on the past: https://github.com/vnen/godot/tree/v8

The main problem was dealing with threads. But my attempt is massively outdated. Now it would be simpler to use PluginScript to embed JS if you want, like it's done for Python.

[etamity]

@vnen thank you for the response, can you give me some direction about PluginScript? I couldn't find any document about it?

[jkb0o]

I tried to do it using PluginScript with several backends - JavaScriptCore, ChakraCore, Duktape and JerryScript. I wrote bindings to atomic types (Vector, Transform, RID, etc.). I used something like this code to test performance:

// Vector2 is bindings to Godot's Vector2
// JSVector2 is pure JS implementation

// test how fast pure js calculations
var k = new JSVector2();
for (var i =0; i< 1000000; i++){
  k = k.multiply(1.00001);
}
print(time_to_calcculate_k)

// test how fast js -> c++ bridge
var v = new Vector2(1, 1)
for (var i = 0; i < 1000000; i++){
  v = v.multiply(1.00001);
} 
print(time_to_calculate_v)

I compare all backends with similar code written on GDScript.

Well, Duktape and JerryScript are 50-100 times slower then GDScript in both cases (pure JS and C++ bridge).

ChakraCore and JavaScriptCore both perform superfast pure js calculations (50-200 times faster then GDScript), I suppose it is because of JIT. But using the bridge to C++ is still very slow (10-30 times slower then GDScript) and I suppose this can't be improved (at least with those backends). I took a look into ReactNative (this framework allows you to write logic in JavaScript and render on mobile devices using native modules), and found it is focused to reduce JS->native messaging to the minimum as it is a bottleneck. As far as I can't reduce JS->native messaging in Godot I decide to drop this idea.

[rosshadden]

Wow great work @jjay! It's a shame that the bridge to C++ is slow. Now that you have mentioned it, someone here might come up with an idea on how that problem could be solved or mitigated. @vnen maybe?

[Geequlim]

@jjay Would you mind share the code how you bind javascript with these backends ?

[sankumar-ari]

@jjay please share the code how you bind javascript with these backends?

[jkb0o]

@Geequlim @sankumar-ari shame on me, it is on a broken laptop only. I will fix it and share code in 2-3 weeks.

[Geequlim]

I'm working on the duktape binding for godot. I think it is possiable to achive the same performence level with gdscript.

[arimus]

@Geequlim @jjay any code you have or information about the challenges you run into around bindings for JavaScript would be much appreciated. Looking for the same and trying to pick apart the other binding projects (e.g. Python, Rust, GoLang) to get there. Cheers.

[arimus]

I've eaten up my weekend, but I was able to get an extremely rudimentary native binding example set up for Godot and Duktape working, with a little assistance from dukglue to make life easy out the gates. Currently, only binding a single class and print method to call Godot::print, since that seemed like a good choice for testing (Godot appears to swallow all of stdout...perhaps a setting I'm missing somewhere?).

Still need to auto-gen all the bindings from the api.json now, for which I'm using the godot-cpp binding_generator.py script as an example. Also need to generate some TypeScript definitions while I'm at it. I don't think that part will be too difficult now that I've gotten the above end-to-end working and have a feel for what I'm doing. I'll report back in the near future when I have something more useful to share and provide some results and code.

Btw, Duktape has mostly been straight forward for integration thus far, however performance is likely to be a bit more meh than desired, given it isn't a JIT-capable engine and has no plans to be. Once I get this prototype working, I may look into V8 or another embed-able engine that's known for performance, but first thing's first. It's been awhile since I flexed my C++ muscles ;)

[Geequlim]

@arimus If you are interested in the work of my binding you can refer this repo https://github.com/Geequlim/ECMAScript
It not finished yet. All classes defined in C++ can work correctly in javascript now. It still in development and a lot of work need to do.

[arimus]

@Geequlim thanks. I'll take a look to see if it helps me.

[rosshadden]

I do recommend trying with a much faster engine, like v8 or ChakraCore. They are a lot harder to embed, but I don't think Duktape will ever quite cut it. From my experiences with it I found it not only slower than the others, but also it's not very far along the ECMAScript standards path. They implement everything from scratch and are pretty lacking in terms of the kind of ECMAScript features that are more useful for gamedev.

I tried doing what you guys are talking about before PluginScript was a thing (or at least before I knew about it), and found that ChakraCore is _far_ easier to work with embedding than v8. But I didn't really know what I was doing so hopefully you guys with better field knowledge can figure it out.

[arimus]

Just an update. Was trying my hand integrating SpiderMonkey, given it targets a wide-range of platforms, but there were some challenges along the way. Switched over to V8 integration, for both speed and size (substantially smaller). Unfortunately iOS won't be supported given some iOS limitations for JIT runtimes going this route, but can always wedge in WebKit like the Chrome devs do at some point.

In any case, I have some very minimal test code working and will be trying to wire everything up into a semblance of something usable. V8 integration is much more complex than something like DukTape unfortunately, but I'm giving it a go in my spare time. No promises, but I'll try to share where I leave off no matter what.

[Geequlim]

@rosshadden Here are some reason why I choose Duktape for the initial ECMAScript engine.

1. Duktape is small. About 100kB after compiled.
2. Duktape can run on all major platforms which godot runs on.
3. Duktape is easy to integrate into godot.
4. The script performence is reasonable. It is the same level with GDScript.
5. ECMAScript E5/E5.1 compliant. So it is ready for ES6/TypeScript with tools like webpack.

My plan is to find a good way to bind JavaScript into Godot.
The first implementation with Duktape will save a lot of time.
I will abstract the binding process with minimal engine dependence. After this binding process is verified, we can replace other faster engines in the same way in the future.

[arimus]

@Geequlim It is easier to work with for sure. The performance will definitely be on the slower side of things, but as you point out it would still likely be functional for many use cases. However the testing notes from @jjay above are of general concern.

Either way, I'm trying to use an adapter class, such that any JS engine could be plugged in moving forward. That way it's flexible enough to use DukTape, V8, WebKit, etc. In either case, automatically generating the adapter bindings for Godot integration will be key, as manual bindings would be tedious to maintain over the long-haul.

[arimus]

Still working on the Godot bindings themselves, but I have a rudimentary setup that I'm posting which is using duktape and the built in console logging extra. I've created a github project for it (https://github.com/godot-js/godot-js), so feel free to take a peek if you are interested.

Again, my C++ skills are rusty, so forgive the roughness. The repo has a working example of the latest Godot executing an index.js file which just prints a log line. Took me awhile to clean everything up and make it semi-presentable, but it does provide a starting point. Check the README for details.

I tabled V8 for the moment, but looking to get a good prototype working with DukTape end-to-end first. Then, perhaps another more performance implementation may be in order. For now, up next is automating the bindings generation using the API JSON data to generate DukTape integration classes.

Cheers

[rosshadden]

@arimus Have you looked into ChakraCore? It's one of those things (like TypeScript) that I had initially unfairly/ignorantly written off because it was made by Microsoft, but is really good. Like I said, it was far easier to work with its bindings than V8 in my experience. I think you're a LOT better than me at this stuff, so you would benefit even more than I did in the simplicity. Their examples are extremely helpful and practical.

It's the best JS engine for embedding that I've seen other than Duktape, and while I understand and appreciate what @Geequlim is saying about just using that as a starting point (I do prototypes like that all the time!), I would hope that any successes with Duktape would quickly be sought to be replaced with another engine. Yes you can transpile to their ES 5.1 (which when I used it was actually _not_ compliant and had many bugs with normal JS things like Sets and Maps), but polyfilling things like Promises and and for-of loops are orders of magnitude less performant than using an engine that supports them first-class, and many features are not possible to polyfill. In my opinion ES6/2015/whatever you call it is very intriguing for a gamedev scripting language, but <=ES5 seems like essentially trying to use JS for the sake of trying to use it, not to benefit from the recent niceties in the spec. WeakMaps for example are pretty much critical for gamedev, and proxies are very useful.

[rosshadden]

For reference on just how slow-moving Duktape is for spec support, these issues that I was commenting a lot in and very invested in at the time were opened way back in mid 2015 and 2016 respectively: https://github.com/svaarala/duktape/issues/276 and https://github.com/svaarala/duktape/issues/1015

Edit: I'm not meaning to sound negative. Progress is progress! Duktape is great for what it is, and I've used it before in a game engine of my own, and dealt with it while using Atomic Game Engine as well. Maybe embedding a bigger engine would have size problems on mobile. I am admittedly thinking about this more from a desktop platform mindset, on which I would much rather have speed and features than a small footprint. So the idea of supporting multiple engines might be good too. I don't know.

[Geequlim]

@rosshadden There are a lot of tools to compile TypeScript/ES6 to ES5. So don't worry about that.

Here is an example it works with my binding in typescript

@gdclass("MyNode", "res://icon.png")
class MyNode extends godot.Control {

    private time = 0;
    private label = null;

    constructor() {
      super();
      print("MyNode.constructor");
    }

    _ready() {
        print("MyNode._ready");
        this.label = this.get_node("Label");
    }

    _process(delta) {
        this.time += delta;
        this.label.text = `${this.time}`;
    }
}

Some feature like Promise or setTimeout won't be supported as we don't inruduce something like libuv. We may implement that in godot way in the future.

[Geequlim]

It starting work with my duktape binding.
This is the pong demo implemented in TypeScript.

[arimus]

Nice! Do you happen to have build instructions or that sample project
available for testing? I can give it a whack on my side too.

On Fri, Feb 22, 2019, 7:02 AM Geequlim [e-mail] wrote:

It starting work with my duktape binding.
This is the pong demo implemented in TypeScript.
[image: 2019-02-22 22-54-26]
https://user-images.githubusercontent.com/6964556/53250631-bef31580-36f5-11e9-9d2b-8944d00964f4.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/937#issuecomment-466426177,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN8Kmsh-ozDLdb5JJOxxKhkkoyH2RkFks5vQAZvgaJpZM4DFSv6
.

[Geequlim]

Here is an example project to use TypeScript in godot

https://github.com/Geequlim/ECMAScriptDemos/tree/master/HelloWorld-TS

[Geequlim]

@jkb0o Tested with the duktape implement of JS binding. The BunnymarkV2 test case shows the duktape binding is about 2.1 times slower than GDScript.

[arimus]

@Geequlim do you have more information / build instructions for this module? Getting the following when dropping your folder into modules/

modules/ECMAScript//duktape/builtin_binding_generator.py
Traceback (most recent call last):
  File "modules/ECMAScript//duktape/builtin_binding_generator.py", line 218, in <module>
    generate_duktape_builtin_bindings()
  File "modules/ECMAScript//duktape/builtin_binding_generator.py", line 215, in generate_duktape_builtin_bindings
    file.write(generate_binding_code())
  File "modules/ECMAScript//duktape/builtin_binding_generator.py", line 197, in generate_binding_code
    open(API_FILE, 'r', encoding='utf8')
TypeError: 'encoding' is an invalid keyword argument for this function

Even after removing the encoding flag from the script, I get a number of additional errors:

modules/ECMAScript/tools/editor_tools.cpp:27:8: warning: use of enumeration in a nested name specifier is a C++11 extension [-Wc++11-extensions]
                case MenuItem::ITEM_RELOAD_LIBS:
                     ^
modules/ECMAScript/tools/editor_tools.cpp:30:8: warning: use of enumeration in a nested name specifier is a C++11 extension [-Wc++11-extensions]
                case MenuItem::ITEM_GEN_DECLAR_FILE:
                     ^
modules/ECMAScript/tools/editor_tools.cpp:61:9: error: conversion from 'long' to 'Variant' is ambiguous
        return NULL;
               ^~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include/stddef.h:100:18: note: expanded from macro 'NULL'
#    define NULL __null
                 ^~~~~~
./core/variant.h:239:2: note: candidate constructor
        Variant(bool p_bool);
        ^

Building on OSX atm and I can build godot without this module just fine. What are the build requirements? For instance, does the build require a version of Python > 2.7 (osx system default)?

Any assistance would be helpful. Thanks.

[Geequlim]

Not tested on osx and clang.
Could you give me more information about compile error instead warnings ？

arimus [e-mail] 于 2019年3月6日周三 10:31写道：

@Geequlim https://github.com/Geequlim do you have more information /
build instructions for this module? Getting the following when dropping
your folder into modules/

modules/ECMAScript//duktape/builtin_binding_generator.py
Traceback (most recent call last):
File "modules/ECMAScript//duktape/builtin_binding_generator.py", line 218, in
generate_duktape_builtin_bindings()
File "modules/ECMAScript//duktape/builtin_binding_generator.py", line 215, in generate_duktape_builtin_bindings
file.write(generate_binding_code())
File "modules/ECMAScript//duktape/builtin_binding_generator.py", line 197, in generate_binding_code
open(API_FILE, 'r', encoding='utf8')
TypeError: 'encoding' is an invalid keyword argument for this function

Building on OSX atm. What are the build requirements? For instance, does
the build require a version of Python > 2.7 (osx system default)?

Any assistance would be helpful. Thanks.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/937#issuecomment-469942621,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGpFTFgxJI-OYGyLbAlj1FoHvlnMA1HQks5vTyiagaJpZM4DFSv6
.

[arimus]

That stack above has 2 warnings to start with, but that third entry is an error...

modules/ECMAScript/tools/editor_tools.cpp:61:9: error: conversion from 'long' to 'Variant' is ambiguous
        return NULL;
               ^~~~

[Geequlim]

@arimus I updated the code and push it to the module repo. Could you test it and feedback here https://github.com/Geequlim/ECMAScript/issues/2 ?

[arimus]

@Geequlim Seems better, although I still had a few errors like:

$ scons platform=osx
scons: Reading SConscript files ...
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Checking for C header file mntent.h... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
[  7%] Compiling ==> modules/ECMAScript/duktape/duktape_binding_helper.cpp
modules/ECMAScript/duktape/duktape_binding_helper.cpp:432:13: error: conversion from 'long' to 'Variant' is ambiguous
                                Variant re = NULL;
                                        ^    ~~~~
./core/variant.h:239:2: note: candidate constructor
        Variant(bool p_bool);
        ^

Forgive me if I went down the wrong path here, but I made a couple changes to get things compiling. I'm not sure they are correct, given my inexperience with the internals of Godot.

$ git diff
diff --git a/duktape/duktape_binding_helper.cpp b/duktape/duktape_binding_helper.cpp
index 1eb665c..de08322 100644
--- a/duktape/duktape_binding_helper.cpp
+++ b/duktape/duktape_binding_helper.cpp
@@ -455,7 +455,7 @@ Variant DuktapeBindingHelper::duk_get_godot_variant(duk_context *ctx, duk_idx_t
                                                ret = *(static_cast<Transform2D*>(ptr));
                                                break;
                                        default:
-                                               ret = NULL;
+                                               ret = Variant::NIL;
                                                break;
                                }
                                return ret;
@@ -1078,12 +1078,12 @@ ECMAScriptGCHandler DuktapeBindingHelper::create_ecma_instance_for_godot_object(
 Variant DuktapeBindingHelper::call_method(const ECMAScriptGCHandler &p_object, const ECMAMethodInfo &p_method, const Variant **p_args, int p_argcount, Variant::CallError &r_error) {
        if (p_object.is_null()) {
                r_error.error = Variant::CallError::CALL_ERROR_INSTANCE_IS_NULL;
-               return NULL;
+               return Variant::NIL;
        }

        if (p_method.is_null()) {
                r_error.error = Variant::CallError::CALL_ERROR_INVALID_METHOD;
-               return NULL;
+               return Variant::NIL;
        }
        duk_push_heapptr(ctx, p_method.ecma_object);
        duk_push_heapptr(ctx, p_object.ecma_object);
diff --git a/ecmascript_instance.cpp b/ecmascript_instance.cpp
index 78cf76c..345471a 100644
--- a/ecmascript_instance.cpp
+++ b/ecmascript_instance.cpp
@@ -58,7 +58,7 @@ Variant::Type ECMAScriptInstance::get_property_type(const StringName &p_name, bo

 Variant ECMAScriptInstance::call(const StringName &p_method, const Variant **p_args, int p_argcount, Variant::CallError &r_error) {

-       ERR_FAIL_COND_V(script.is_null() || ecma_object.is_null(), NULL);
+       ERR_FAIL_COND_V(script.is_null() || ecma_object.is_null(), Variant::NIL);

        ECMAClassInfo *cls = script->get_ecma_class();
        if (cls == NULL) {

I was able to build, run and even run the Hello World demo! But something along the way broke when trying to run Pong and now it seems I can't even run Hello World any more. Godot dies with the following:

0: ./bin/godot.osx.tools.64
Current path: /Users/arimus/workspace/godot
OpenGL ES 3.0 Renderer: NVIDIA GeForce GT 650M OpenGL Engine
Editing project: /Users/arimus/workspace/ECMAScriptDemos/hello_world (::Users::arimus::workspace::ECMAScriptDemos::hello_world)
arguments
0: /Users/arimus/workspace/godot/bin/godot.osx.tools.64
1: --path
2: /Users/arimus/workspace/ECMAScriptDemos/hello_world
3: --editor
Current path: /Users/arimus/workspace/godot
handle_crash: Program crashed with signal 4
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] 1   libsystem_platform.dylib            0x00007fff75909f5a _sigtramp + 26
OpenGL ES 3.0 Renderer: NVIDIA GeForce GT 650M OpenGL Engine
[2] 2   ???                                 0x0000000000000006 0x0 + 6
ERROR: grab_focus: Condition ' !is_inside_tree() ' is true.
   At: scene/gui/control.cpp:2074.
ERROR: safe_eval_text: Condition ' Thread::get_caller_id() != Thread::get_main_id() ' is true. returned: ERR_UNAVAILABLE
   At: modules/ECMAScript/duktape/duktape_binding_helper.cpp:153.
ERROR: set_path: Another resource is loaded from path: res://ECMAClass/Main.es (possible cyclic resource inclusion)
   At: core/resource.cpp:79.

[Geequlim]

@arimus Your diff content seems contains error. But I'm not sure the crash of yours is because of that.
I updated the code again it should compiles with clang.
Make sure your typescript is compiled to JS before you run the code without the editor mode.

[arimus]

To compile, I still had one error with this line of code:

$ git diff -u
diff --git a/duktape/duktape_binding_helper.cpp b/duktape/duktape_binding_helper.cpp
index c6ee235..f9f7d67 100644
--- a/duktape/duktape_binding_helper.cpp
+++ b/duktape/duktape_binding_helper.cpp
@@ -462,7 +462,7 @@ Variant DuktapeBindingHelper::duk_get_godot_variant(duk_context *ctx, duk_idx_t
                                                ret = *(static_cast<Basis*>(ptr));
                                                break;
                                        default:
-                                               ret = NULL;
+                                               ret = Variant::NIL;
                                                break;
                                }
                                return ret;

Compiled fine, but still having issues loading up the project in the editor:

$ ./bin/godot.osx.tools.64
arguments
0: ./bin/godot.osx.tools.64
Current path: /Users/arimus/workspace/godot
OpenGL ES 3.0 Renderer: NVIDIA GeForce GT 650M OpenGL Engine
Editing project: /Users/arimus/workspace/ECMAScriptDemos/pong (::Users::arimus::workspace::ECMAScriptDemos::pong)
arguments
0: /Users/arimus/workspace/godot/bin/godot.osx.tools.64
1: --path
2: /Users/arimus/workspace/ECMAScriptDemos/pong
3: --editor
Current path: /Users/arimus/workspace/godot
handle_crash: Program crashed with signal 4
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
OpenGL ES 3.0 Renderer: NVIDIA GeForce GT 650M OpenGL Engine
[1] 1   libsystem_platform.dylib            0x00007fff75909f5a _sigtramp + 26
[2] 2   ???                                 0x0000000000000000 0x0 + 0
ERROR: grab_focus: Condition ' !is_inside_tree() ' is true.
   At: scene/gui/control.cpp:2074.
ERROR: safe_eval_text: Condition ' Thread::get_caller_id() != Thread::get_main_id() ' is true. returned: ERR_UNAVAILABLE
   At: modules/ECMAScript/duktape/duktape_binding_helper.cpp:153.
ERROR: safe_eval_text: Condition ' Thread::get_caller_id() != Thread::get_main_id() ' is true. returned: ERR_UNAVAILABLE
   At: modules/ECMAScript/duktape/duktape_binding_helper.cpp:153.
ERROR: safe_eval_text: Condition ' Thread::get_caller_id() != Thread::get_main_id() ' is true. returned: ERR_UNAVAILABLE
   At: modules/ECMAScript/duktape/duktape_binding_helper.cpp:153.
ERROR: safe_eval_text: Condition ' Thread::get_caller_id() != Thread::get_main_id() ' is true. returned: ERR_UNAVAILABLE
   At: modules/ECMAScript/duktape/duktape_binding_helper.cpp:153.

[Geequlim]

@arimus Can you provide the demo project which crashes your editor?

This error won't crash your editor

ERROR: safe_eval_text: Condition ' Thread::get_caller_id() != Thread::get_main_id() ' is true. returned: ERR_UNAVAILABLE
   At: modules/ECMAScript/duktape/duktape_binding_helper.cpp:153.

BTW we should move to a repo to avoid disturbing other people who are watching Godot.

[Geequlim]

The implementation of duktape binding proves that the way of abstracting the JavaScript binding process works. It is also confirmed that the performance of duktape binding is difficult to optimize to a satisfactory level.

After a few months I gave up to optimize the duktape binding. The QuickJS was born. It supports the latest ECMAScript specification while being as lightweight as duktape, and has slightly more performance than Lua. I think it is the most suitable JS engine for me to binding to godot.

Now the duktape has now been replaced by QuickJS. At the same time, it supports more complete functions such as builtin operator overloading, multi-threading, etc. The performance test results are also acceptabl.

For everyone who interested in JavaScript binding of godot. You can get the code in this repository. And you can also get compiled binary with godot 3.2beta for Windows and Linux platform.

https://github.com/Geequlim/ECMAScript

[claytongulick]

@Geequlim this is amazing work, thanks!!

One question: have you thought about trying deno?

It's a NodeJS replacement, with one of the stated project goals being simple v8 embedding for external languages (v8 is a beast to build).

[Geequlim]

@clayjohn
Deno is an application but not an ECMAScript engine. So it is not something meaningful for godot engine.

[claytongulick]

@Geequlim afaik, deno was also designed to be easily embedded in rust, and c/++ via libdeno

https://denolib.gitbook.io/guide/codebase-basics/infrastructure

https://github.com/denolib/guide/blob/master/advanced/interaction-with-v8.md

It ships with a rust crate for this purpose

https://crates.io/crates/deno_core

I'm a big fan of quickjs, but if you really wanted to use v8, maybe borrowing from the hard work the deno folks have done on the v8 build system and exposing isolated via c and rs api is worth checking out?

[Geequlim]

@claytongulick Thnaks for your advice.
If I really want V8 I'd like to integrate it in C++ to avoid itroduce more dependencies.