Re: About removing Beanshell/Javascript (Rhino) ?

2022-01-27 Thread Thorsten Behrens
Stephan Bergmann wrote:
> You mean the BeanShell scripting, with an editor window (with a
> "Run" button) via "Tools - Macros - Organize Macros - BeanShell... -
> Edit"?  Removal of which is what this thread is about.
>
Aye.

> Someone would need to create such an extension, then.  (Assuming
> that it's actually possible to provide such scripting backends
> through extensions, but I strongly assume it is.)
>
Right. I mean, removing the stuff is also work, that someone's gotta
do.

It's possible that its not worth it; what I would still suggest is to
look at the area (developer/power user/automation stories) a bit more
holistically. Beyond Basic, our dev story for integrating & scripting
is not great, and it ain't getting better by removing options.

Cheers,

-- Thorsten


signature.asc
Description: PGP signature


Re: About removing Beanshell/Javascript (Rhino) ?

2022-01-27 Thread Stephan Bergmann

On 24/01/2022 10:00, Thorsten Behrens wrote:

FWIW, I find this Java REPL thingit very useful (is it called Groovy?)
for rapid prototyping of Java code. There's a (very basic) editor for
that buried in the macro dialog.


You mean the BeanShell scripting, with an editor window (with a "Run" 
button) via "Tools - Macros - Organize Macros - BeanShell... - Edit"? 
Removal of which is what this thread is about.



Whether that's something that needs to remain in core, or can be just
shunted into an extension, I've got no strong opinions on.


Someone would need to create such an extension, then.  (Assuming that 
it's actually possible to provide such scripting backends through 
extensions, but I strongly assume it is.)




Re: About removing Beanshell/Javascript (Rhino) ?

2022-01-24 Thread Michael Stahl

On 24.01.22 11:42, Michael Stahl wrote:
also, Rhino relies on the Java-UNO bridge and some Java glue code in the 
scripting model


oops, i meant to write "scripting module" of course



Re: About removing Beanshell/Javascript (Rhino) ?

2022-01-24 Thread Michael Stahl

On 22.01.22 13:35, Ilmari Lauhakangas wrote:

On 22.1.2022 13.27, Julien Nabet wrote:

Hello,

Reading https://en.wikipedia.org/wiki/BeanShell, specifically:

"Since Java 9, Java instead includes JShell 
, a different read–eval–print 
loop 
 
(REPL) shell based on Java syntax, indicating that BeanShell will not 
be continued"


I wonder if we could remove Beanshell part from LO.

Also, we use Rhino as Javascript engine (Rhino is written in Java). 
Some people proposed C/C++ engine like Spidermonkey or V8 (see 
https://bugs.documentfoundation.org/show_bug.cgi?id=97827) but it 
seems they may be problematic too because of instable API and specific 
GC, see Michael's comment here: 
https://bugs.documentfoundation.org/show_bug.cgi?id=97827#c7


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 model 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.


Re: About removing Beanshell/Javascript (Rhino) ?

2022-01-24 Thread Thorsten Behrens
Stephan Bergmann wrote:
> As always, hard to tell if anybody is actually using this.
>
FWIW, I find this Java REPL thingit very useful (is it called Groovy?)
for rapid prototyping of Java code. There's a (very basic) editor for
that buried in the macro dialog.

Whether that's something that needs to remain in core, or can be just
shunted into an extension, I've got no strong opinions on.

Cheers,

-- Thorsten


signature.asc
Description: PGP signature


Re: About removing Beanshell/Javascript (Rhino) ?

2022-01-23 Thread Stephan Bergmann

On 1/22/22 20:40, Caolán McNamara wrote:

On Sat, 2022-01-22 at 12:27 +0100, Julien Nabet wrote:

shouldn't we ... remove the 2 others or at least Beanshell ?


FWIW I agree, I don't think the beanshell or rhino integration has ever
really been particularly useful. For RedHat's RHEL we've built without
them (--disable-scripting-beanshell --disable-scripting-javascript)
since 2019 and the same will be true for Fedora from F36 onward.

The rhino jar is from 2007/2008 when it was bumped to the last rhino
1.5 release version (by me) in the only change to it since the initial
version of 2003 and it's a similar story for bsh. IMO it's only
demoware for the at-that-time-new scripting framework.

http://www.openoffice.org/framework/scripting/scriptingf1


As always, hard to tell if anybody is actually using this.  One way to 
find out would be to mark them as deprecated in the upcoming 7.3 release 
notes and remove each of them (individually, for easier resurrection, 
just in case) on master.  Maybe we should briefly bring that up in the 
next ESC meeting.




Re: About removing Beanshell/Javascript (Rhino) ?

2022-01-23 Thread Tomaž Vajngerl
Hi,

On Sun, Jan 23, 2022 at 9:57 AM Tomaž Vajngerl  wrote:

>
> Probably it is better to invest into integrating a WebAssembly runtime
> like Wasmer. Not only would we get JS but also support for a bunch of other
> languages and have support for a platform independent binary execution
> format.
>

Just a quick update regarding this, following the IRC conversation:
I noticed that wasm doesn't actually support compiling to JS, so we can't
actually use Wasmer or other runtimes to use as an alternative. There are a
bunch of JS or TypeScript subset languages that are supported or
alternatively use QuickJS or JavaScriptCore compiled into wasm and use that
to interpret (which could serve as a temporary solution). I still think it
would be an interesting idea to support wasm as it would solve some issues
for us like having a platform independent binary execution format for
extensions and support for Rust, Go, Swift, C#,.. We could probably even
standardize on it in the future, but it won't help to solve this problem.

Regards, Tomaž

>


Re: About removing Beanshell/Javascript (Rhino) ?

2022-01-22 Thread Tomaž Vajngerl
Hi,

On Sat, Jan 22, 2022 at 9:35 PM Ilmari Lauhakangas <
ilmari.lauhakan...@libreoffice.org> wrote:

> Indeed, there are engines better suited for embedding, but then the
> question becomes how well they keep up with all the new features
> introduced into JS standard each year.
>
> QuickJS[0] appeared on the scene in 2019 and caused a lot of excitement
> due to the nice support for new JS features. However, it has remained as
> more of a "man throws code over the wall occasionally" type of project.
>
> Duktape[1] is lagging behind in the latest JS features, but is still
> actively developed, is used by many projects[2] and has a very good
> Linux packaging coverage[3]. One widely-deployed project currently
> adopting Duktape is polkit[4] (moving away from mozjs).
>
>
Probably it is better to invest into integrating a WebAssembly runtime like
Wasmer. Not only would we get JS but also support for a bunch of other
languages and have support for a platform independent binary execution
format.

Regards, Tomaž


Re: About removing Beanshell/Javascript (Rhino) ?

2022-01-22 Thread Caolán McNamara
On Sat, 2022-01-22 at 12:27 +0100, Julien Nabet wrote:
> shouldn't we ... remove the 2 others or at least Beanshell ?

FWIW I agree, I don't think the beanshell or rhino integration has ever
really been particularly useful. For RedHat's RHEL we've built without
them (--disable-scripting-beanshell --disable-scripting-javascript)
since 2019 and the same will be true for Fedora from F36 onward.

The rhino jar is from 2007/2008 when it was bumped to the last rhino
1.5 release version (by me) in the only change to it since the initial
version of 2003 and it's a similar story for bsh. IMO it's only
demoware for the at-that-time-new scripting framework.

http://www.openoffice.org/framework/scripting/scriptingf1



Re: About removing Beanshell/Javascript (Rhino) ?

2022-01-22 Thread Ilmari Lauhakangas

On 22.1.2022 13.27, Julien Nabet wrote:

Hello,

Reading https://en.wikipedia.org/wiki/BeanShell, specifically:

"Since Java 9, Java instead includes JShell 
, a different read–eval–print loop 
 
(REPL) shell based on Java syntax, indicating that BeanShell will not be 
continued"


I wonder if we could remove Beanshell part from LO.

Also, we use Rhino as Javascript engine (Rhino is written in Java). Some 
people proposed C/C++ engine like Spidermonkey or V8 (see 
https://bugs.documentfoundation.org/show_bug.cgi?id=97827) but it seems 
they may be problematic too because of instable API and specific GC, see 
Michael's comment here: 
https://bugs.documentfoundation.org/show_bug.cgi?id=97827#c7


However, shouldn't we focus on Basic support and Python and remove the 2 
others or at least Beanshell ?


Goal: diminish Java dependency and maintaining burden by removing code.

Now I must recognize I don't know if these 2 features are used or not. 
Considering number of bugtrackers it doesn't seem so but perhaps it's 
because there are very few bugs.


Thanks for the heads up regarding JShell.

Indeed, there are engines better suited for embedding, but then the 
question becomes how well they keep up with all the new features 
introduced into JS standard each year.


QuickJS[0] appeared on the scene in 2019 and caused a lot of excitement 
due to the nice support for new JS features. However, it has remained as 
more of a "man throws code over the wall occasionally" type of project.


Duktape[1] is lagging behind in the latest JS features, but is still 
actively developed, is used by many projects[2] and has a very good 
Linux packaging coverage[3]. One widely-deployed project currently 
adopting Duktape is polkit[4] (moving away from mozjs).


For editing JavaScript macros, instead of BeanShell the same approach 
could be taken as with Python, using an external IDE.


Ilmari

0: https://bellard.org/quickjs/
1: https://duktape.org/
2: https://wiki.duktape.org/projectsusingduktape
3: https://repology.org/project/duktape/versions
4: https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/97
5: https://wiki.documentfoundation.org/Macros/Python_Basics


About removing Beanshell/Javascript (Rhino) ?

2022-01-22 Thread Julien Nabet

Hello,

Reading https://en.wikipedia.org/wiki/BeanShell, specifically:

"Since Java 9, Java instead includes JShell 
, a different read–eval–print loop 
 
(REPL) shell based on Java syntax, indicating that BeanShell will not be 
continued"


I wonder if we could remove Beanshell part from LO.

Also, we use Rhino as Javascript engine (Rhino is written in Java). Some 
people proposed C/C++ engine like Spidermonkey or V8 (see 
https://bugs.documentfoundation.org/show_bug.cgi?id=97827) but it seems 
they may be problematic too because of instable API and specific GC, see 
Michael's comment here: 
https://bugs.documentfoundation.org/show_bug.cgi?id=97827#c7


However, shouldn't we focus on Basic support and Python and remove the 2 
others or at least Beanshell ?


Goal: diminish Java dependency and maintaining burden by removing code.

Now I must recognize I don't know if these 2 features are used or not. 
Considering number of bugtrackers it doesn't seem so but perhaps it's 
because there are very few bugs.


Julien