Live data from Hacker News

Duktape: an embeddable JavaScript engine

duktape.org

41–44 of 44 posts

Re: Duktape: an embeddable JavaScript engine

#41
post #24

Earlier quoted context omitted.

Do you happen to know an embeddable Lisp that can easily bind to C++ objects (rather like AngelScript or luabind)? I too would mostly rather a Lisp, but doing all the plumbing sucks .

If Lua's semantics are acceptable, you can make a loader that runs your Lisp in Lua. This is probably less effort than it sounds like. Moonscript is a decent example of a mostly expression-oriented language as a Lua loader, so it should be simple to make it read a Lisp instead.

Interesting approach, thank you. I don't much care for Lua (either as a language or as an API, especially when dealing with C++), but this is a pretty neat concept to think about.

Re: Duktape: an embeddable JavaScript engine

#42

Earlier quoted context omitted.

SpiderMonkey is easily embeddable like I said. The Mozilla Public License is less liberal than BSD/MIT, but for most practical purposes it's the same. It's not tiny though (for an underbelly feeling, I found an old binary Windows build online of about 800kb). Looking at the current SpiderMonkey docs, things look like they've only improved. Back in the day, I just took SpiderMonkey from the "js" subdirectory of the Fi…

After a quick glance it also seems that newer versions of SpiderMonkey only offer a C++ API, so you can't embed it anymore into C apps without some glue code. I checked out jsapi.h in SpiderMonkey24 - maybe some trick is needed to use SM from C?

New versions of SpiderMonkey only expose a C++ API (because of exact rooting), but we'll need to fix that at some point as part of Servo since this is a hazard for Rust. Currently we use an old version of SpiderMonkey for this reason.

Re: Duktape: an embeddable JavaScript engine

#43
post #33
post #19

Earlier quoted context omitted.

Agreed. I really like the engineering behind V8, but the interface is such a pain to work with. I actually switched my game from C++ to the JVM so I could use Rhino.

> I actually switched my game from C++ to the JVM so I could use Rhino. Would you mind elaborating a bit what makes v8 tedious to work with?

https://developers.google.com/v8/embed

EDIT:

V8 is quite powerful, don't get me wrong. But, it requires a bit more knowledge of C++ to use and use well, and sometimes that can be a bit much. Also, if you're exporting functionality via a static library, you really don't always want to use anything other than vanilla C.

Post reply on HN