From my point of view, the best programing languages to make macros in LibreOffice are Python and Javascript. Learning either of the two lets you reuse your knowledge. Moreover, JavaScript is the most popular programming language for a long time (first or second place). It is accessible and easy to learn for the end user. Also JavaScript is omnipresent and multipurpose in different areas (valued element for a user). I think there are many advantages to improve support for JavaScript in LibreOffice, however: - LibreOffice uses the Rhino engine to support JavaScript. Rhino is written in Java, it is heavy and slow for complex macros. - Java support in LibreOffice is optional ... A large percentage of user disables the Java runtime environment in LibreOffice, for many reasons. Macros, especially in Calc is a key feature, and enhance programming languages powerful and easy to learn seems like a good idea. It is also a bit to free themselves from dependence to Java in LO. Open source alternatives: SpiderMonkey and V8. Cheers
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/How_to_embed_the_JavaScript_engine Let's set to NEW and see what happens.
It seems choosing Spidermonkey would be shooting ourselves in the foot: https://lists.freedesktop.org/archives/polkit-devel/2015-August/date.html https://lists.freedesktop.org/archives/polkit-devel/2015-September/date.html An promising choice (that the Polkit devs are considering) would be http://duktape.org/ Duktape is easy to integrate into a C/C++ project: add duktape.c, duktape.h, and duk_config.h to your build, and use the Duktape API to call Ecmascript functions from C code and vice versa.
I was thinking to create an integration between dukescript and libreoffice. This could be a first step to give it a try. Already some work in progress in your side ? (I'm currently in the technical study step)
(In reply to Johan PIQUET from comment #3) > I was thinking to create an integration between dukescript and libreoffice. > This could be a first step to give it a try. > > Already some work in progress in your side ? > (I'm currently in the technical study step) Dukescript seems to be using Java: https://dukescript.com/ I think it would not be added to LibreOffice as they want to remove Java dependencies, but you can of course do it as an extension.
Sorry, I mean "duketape" not "dukescript".
(In reply to Johan PIQUET from comment #5) > Sorry, I mean "duketape" not "dukescript". Oh ok :) I'm not a dev, so have not done anything. You could study the thing a bit and then post a proposal to the developer mailing list.
> - LibreOffice uses the Rhino engine to support JavaScript. Rhino is written in Java, it is heavy and slow for complex macros. this is utterly irrelevant - your macro is going to call heavy and slow LibreOffice code via heavy and slow UNO bridge that looks up every method to call via UNO reflection, so it will never be fast anyway. SpiderMonkey and V8 are very large and complex C++ projects with unstable APIs so integrating them would be very painful (cf. the ongoing Firebird disaster). also they have their own GC whereas Rhino uses the Java GC, so switching would make our distributed-GC problem (which already exists between Java and Python) worse and leak memory (can't collect cycles). furthermore, ~nobody is using JavaScript (or BeanShell for that matter) for LO scripting anyway, there is ~no documentation for it, in fact there was a plan to unbundle all the Java Scripting Host based stuff to an extension and the only reason that didn't get done is that nobody had the time to work on it. see ESC minutes from 08.11.2012: http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/38646 + should we drop Rhino, Beanshell & javascript in 4.0 ? (Michael) + could be turned into an extension + was in the past was turned off (Stephan) AA: + disable Rhino / Beanshell unless in experimental mode (Michael) + for future deprecation / removal.
(In reply to Michael Stahl from comment #7) Sure you may be right, but to use Java to run a Javascript engine is not the most efficient way anyway. Maybe V8 or Spidermonkey are not the ideal solution, but the spirit is to remove Java dependencies in LibreOffice and improve performance. In my case not to use Java in LibreOffice, some friends either. Therefore could not use JavaScript for my macros (and other features that require Java). It really is a nuisance for users no-developers have to learn a new language and more complex to create macros. So... why javascript are not as used to create macros in LibreOffice? Well JavaScript is everywhere and is easy to use, but the JavaScript support in LibreOffice is bad. Regards
(In reply to Michael Stahl from comment #7) > > … > > furthermore, ~nobody is using JavaScript (or BeanShell for that matter) > for LO scripting anyway, there is ~no documentation for it, Which is sadly a Catch 22: Without documentation, it is no wonder that no one uses it. I think it would be great to have a better JS support and (better/any) documentation. JS is a widespread language and would enable to tap into a different group of devs (if that is wanted).
There is now also QuickJS from Fabrice Bellard & friends: https://bellard.org/quickjs/
Out of curiosity I tried Rhino and QuickJS on the bench-v8 version 7 benchmark (https://github.com/mozilla/arewefastyet/tree/master/benchmarks/v8-v7), used on the official QuickJS website as a comparison with other JS micro-engines (https://bellard.org/quickjs/bench.html). I wanted to benchmark Duktape too, but it would not compile on my Debian 11 system, since the build system requires Python2 YAML (which is not available anymore at the repositories). Rhino 1.7.14-SNAPSHOT 2021 09 14 java -classpath buildGradle/libs/rhino-1.7.14-SNAPSHOT.jar org.mozilla.javascript.tools.shell.Main -opt -1 -f bench-v8/combined.js //commented out a line with console.log (Rhino does not support it) PROGRESS Richards RESULT Richards 53.6 PROGRESS DeltaBlue RESULT DeltaBlue 55.3 PROGRESS Encrypt PROGRESS Decrypt RESULT Crypto 52.0 PROGRESS RayTrace RESULT RayTrace 134 PROGRESS Earley PROGRESS Boyer RESULT EarleyBoyer 167 PROGRESS RegExp RESULT RegExp 147 PROGRESS Splay RESULT Splay 302 PROGRESS NavierStokes RESULT NavierStokes 65.7 SCORE 100 QuickJS 2021-03-27 ./qjs bench-v8/combined.js PROGRESS Richards RESULT Richards 363 PROGRESS DeltaBlue RESULT DeltaBlue 350 PROGRESS Encrypt PROGRESS Decrypt RESULT Crypto 419 PROGRESS RayTrace RESULT RayTrace 483 PROGRESS Earley PROGRESS Boyer RESULT EarleyBoyer 676 PROGRESS RegExp RESULT RegExp 125 PROGRESS Splay RESULT Splay 893 PROGRESS NavierStokes RESULT NavierStokes 751 SCORE 442
Some more facts from Michael: https://lists.freedesktop.org/archives/libreoffice/2022-January/088381.html Quote: another problem is that Rhino cannot simply be replaced by packging yet another JS implementation; if you look at the examples we ship, they have: importClass(java.lang.Thread); importClass(java.lang.System); so any existing Rhino based macros will likely use the Java APIs and cannot work with a non-JVM based JS implementation. importClass(Packages.com.sun.star.uno.UnoRuntime); importClass(Packages.com.sun.star.lang.XMultiComponentFactory); importClass(Packages.com.sun.star.awt.XDialogProvider); importClass(Packages.com.sun.star.awt.XDialog); importClass(Packages.com.sun.star.uno.Exception); importClass(Packages.com.sun.star.script.provider.XScriptContext); also, Rhino relies on the Java-UNO bridge and some Java glue code in the scripting module to provide access to UNO APIs; this would need to be reimplemented in the form of a bridge for any non-JVM based JS implementation.