ebeast: electron + beast

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ebeast: electron + beast

Tim Janik-6
Hi Stefan,

I've just pushed the 'ebeast' branch onto github.

Beware, the branch *might* see non-linear rebasing in the future.

It contains the start of an electron based Beast UI ('ebeast') plus Bse JS bindings.

Here's a short rundown of the contents:

ebeast/:
Makefile.am - build rules for 'run', 'app', 'package.json'
main.js - the main electron 'executable' it pops up a content window
ebeast.html - HTML + JS for the ebeast content window, just test code so far
package.json - metadata required by electron, generated from package.json.in

ebeast/v8bse/:
v8bse.node - Bse JS bindings, compiled as node.js module (for dlopen)
binding.gyp - build info for node-gyp, the build tool for v8bse.node
Makefile.am - generates v8bse.cc and binding.gyp
nodemodule.cc - manual binding code
V8Stub.py - aidacc generator for C++ → JS binding code, based on v8pp
v8bse.cc - code generated by V8Stub.py
v8pp/ - V8 JS binding project using C++11 templates, at the moment
                  this is a git submodule, we might change that later

Because we're now using git submodules, we need to tell git to pull the
submodules together with the git repo:
  git clone --recursive /opt/src/beast/  # pull repo + all submodules
Or to get a non-empty v8pp/ dir in an existing repo:
  git submodule update --init --recursive # update all submodules

About the build rules in ebeast/:

make all
Currently this just gives short usage info, nothing builds by default, so the
normal build isn't affected by ebeast or any of its dependencies.

make app
Generates package.json from all the build info we have in the Makefiles. Then
this will download and locally install electron + electron build tools. The only
thing needed for this to work is npm. After that, v8bse.node is built using
aidacc and the electron build tools.

make run
Given a successful 'make app' build, this will simply preload libbse (to avoid
picking up an old installed library from /usr/lib etc) and start the ebeast
electron app. So far, ebeast.html is displayed in a desktop window and shows
version information. But that's already a full fledged desktop app:

- The ebeast.html window renders its contents from HTML + CSS.

- The version information retrieved is gathered from javascript.

- The info about Bse and Vorbis are already pulled from the Bse bindings.

- You can start the developer console in the window via the menu or by pressing
  "Shift+Ctrl+i". The Console can be used to inspect the HTML DOM tree just
  like its possible in Chrome or Firefox, and the Javascript console can use
  the generated Bse bindings. At the console, just type:
        Bse.server.get_version()

The bindings still need work wrg to vectors, object identity, signals, int64_t
and probably other bugs. But in principle the object system, methods and
properties are basically working now.

Please give 'make run -C ebeast' a try and provide feedback. I've tried to set
things up to be used and built as easily as possible. The next step here is to
make use of electron-packager to implement 'make install -C ebeast'.

About v8pp, I had to fork the original project at https://github.com/pmed/v8pp/
to submit pull requests for a couple bugs, and a few extensions needed by Bse.
As long as not all of those are merged, ebeast/v8bse/v8pp/ just points to the
'for-beast' branch of my fork at https://github.com/tim-janik/v8pp/.
Updates to the 'for-beast' branch will almost always be non-linear in order
to follow the upstream project.


--
Yours sincerely,
Tim Janik

https://testbit.eu/timj/
Free software author.
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ebeast: electron + beast

Stefan Westerfeld
   Hi!

On Wed, Feb 22, 2017 at 01:04:00AM +0100, Tim Janik wrote:
> I've just pushed the 'ebeast' branch onto github.
>
> [...]
>
> It contains the start of an electron based Beast UI ('ebeast') plus Bse JS bindings.
>
> Please give 'make run -C ebeast' a try and provide feedback. I've tried to set
> things up to be used and built as easily as possible. The next step here is to
> make use of electron-packager to implement 'make install -C ebeast'.

Ok, make app works, but make run hangs (nothing happens after this):

$ make run
make[1]: Verzeichnis „/home/stefan/src/2nd-tree/beast/ebeast/v8bse“ wird betreten
make[1]: „v8bse.node“ ist bereits aktuell.
make[1]: Verzeichnis „/home/stefan/src/2nd-tree/beast/ebeast/v8bse“ wird verlassen
LD_PRELOAD="/home/stefan/src/2nd-tree/beast/bse/.libs/libbse-0.so" \
./node_modules/electron/dist/electron .

Seems that there is a crash involved, as a core file appears in the ebeast dir

$ gdb ./node_modules/electron/dist/electron core
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./node_modules/electron/dist/electron...(no debugging symbols found)...done.
[New LWP 20244]
[New LWP 20245]
[New LWP 20246]
[New LWP 20247]
[New LWP 20248]
[New LWP 20258]
[New LWP 20255]
[New LWP 20249]
[New LWP 20250]
[New LWP 20260]
[New LWP 20257]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/home/stefan/src/2nd-tree/beast/ebeast/node_modules/electron/dist/electron --ty'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  Rapicorn::parse_settings_and_args (vsettings=..., args=..., argv=<optimized out>, argcp=0x0) at rcore/main.cc:165

warning: Source file is more recent than executable.
165       const size_t argc = *argcp;
[Current thread is 1 (Thread 0x7fba5d1ffa80 (LWP 20244))]
(gdb) bt
#0  0x00007fba545491d9 in Rapicorn::parse_init_args(int*, char**, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (vsettings=..., args=..., argv=<optimized out>, argcp=0x0) at rcore/main.cc:165
#1  0x00007fba545491d9 in Rapicorn::parse_init_args(int*, char**, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (argcp=0x0, argv=<optimized out>, args=...) at rcore/main.cc:203
#2  0x00007fba5cdacf83 in sfi_init(int*, char**, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) () at sfiwrapper.cc:55
#3  0x00007fba5cc5ffa2 in initialize_with_argv() () at bsemain.cc:223
#4  0x00007fba5cc61464 in _bse_init_async(int*, char**, char const*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) () at bsemain.cc:271
#5  0x00007fba44be4001 in v8bse_register_module() () at ../nodemodule.cc:129
#6  0x00007fba5c24813c in node::DLOpen(v8::FunctionCallbackInfo<v8::Value> const&) ()
    at /home/stefan/src/2nd-tree/beast/ebeast/node_modules/electron/dist/libnode.so
#7  0x00007fba5baa0868 in v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) () at /home/stefan/src/2nd-tree/beast/ebeast/node_modules/electron/dist/libnode.so
#8  0x00007fba5bad7b91 in  () at /home/stefan/src/2nd-tree/beast/ebeast/node_modules/electron/dist/libnode.so
#9  0x00007fba5bafe60f in  () at /home/stefan/src/2nd-tree/beast/ebeast/node_modules/electron/dist/libnode.so
#10 0x000025e530506147 in  ()
#11 0x000025e530506081 in  ()
#12 0x00007ffe979776f0 in  ()
#13 0x0000000300000000 in  ()
#14 0x00007ffe979777d0 in  ()
#15 0x000025e530677313 in  ()
#16 0x00001dd1bd704399 in  ()
#17 0x0000347f2e31e2a1 in  ()
#18 0x000036e9d3622799 in  ()
#19 0x000036e9d3624d81 in  ()
#20 0x0000347f2e326579 in  ()
#21 0x00001dd1bd7c9bd9 in  ()
#22 0x00001dd1bd7043e1 in  ()
#23 0x00001dd1bd7043e1 in  ()
#24 0x00001dd1bd704399 in  ()
#25 0x00001dd1bd704399 in  ()
#26 0x00001dd1bd704279 in  ()
#27 0x000036e9d3622799 in  ()
#28 0x000036e9d3626881 in  ()
#29 0x00001dd1bd704399 in  ()
#30 0x00001dd1bd704399 in  ()
#31 0x0000000000000000 in  ()

Seems that argcp is a nullptr here,

(gdb) print argcp
$1 = (int *) 0x0

and should not be dereferenced.

   Cu... Stefan
--
Stefan Westerfeld, http://space.twc.de/~stefan
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ebeast: electron + beast

Tim Janik-6
On 22.02.2017 13:43, Stefan Westerfeld wrote:

>    Hi!
>
> On Wed, Feb 22, 2017 at 01:04:00AM +0100, Tim Janik wrote:
>> I've just pushed the 'ebeast' branch onto github.
>>
>> [...]
>>
>> It contains the start of an electron based Beast UI ('ebeast') plus Bse JS bindings.
>>
>> Please give 'make run -C ebeast' a try and provide feedback. I've tried to set
>> things up to be used and built as easily as possible. The next step here is to
>> make use of electron-packager to implement 'make install -C ebeast'.
>
> Ok, make app works, but make run hangs (nothing happens after this):
>
> $ make run
> make[1]: Verzeichnis „/home/stefan/src/2nd-tree/beast/ebeast/v8bse“ wird betreten
> make[1]: „v8bse.node“ ist bereits aktuell.
> make[1]: Verzeichnis „/home/stefan/src/2nd-tree/beast/ebeast/v8bse“ wird verlassen
> LD_PRELOAD="/home/stefan/src/2nd-tree/beast/bse/.libs/libbse-0.so" \
> ./node_modules/electron/dist/electron .
>
> Seems that there is a crash involved, as a core file appears in the ebeast dir

> Seems that argcp is a nullptr here,

Eeek, sorry, I ran into this a couple days ago, fixed it locally in Rapicorn and
totally forgot about it.
Just pull the fix from Rapicorn master now, you've diagnosed this correctly.

>
> (gdb) print argcp
> $1 = (int *) 0x0
>
> and should not be dereferenced.
>
>    Cu... Stefan
>

--
Yours sincerely,
Tim Janik

https://testbit.eu/timj/
Free software author.
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ebeast: electron + beast

Stefan Westerfeld
    Hi!

On Wed, Feb 22, 2017 at 04:00:48PM +0100, Tim Janik wrote:

> On 22.02.2017 13:43, Stefan Westerfeld wrote:
> >    Hi!
> >
> > On Wed, Feb 22, 2017 at 01:04:00AM +0100, Tim Janik wrote:
> >> I've just pushed the 'ebeast' branch onto github.
> >>
> >> [...]
> >>
> >> It contains the start of an electron based Beast UI ('ebeast') plus Bse JS bindings.
> >>
> >> Please give 'make run -C ebeast' a try and provide feedback. I've tried to set
> >> things up to be used and built as easily as possible. The next step here is to
> >> make use of electron-packager to implement 'make install -C ebeast'.
> >
> > Ok, make app works, but make run hangs (nothing happens after this):
> >
> > $ make run
> > make[1]: Verzeichnis „/home/stefan/src/2nd-tree/beast/ebeast/v8bse“ wird betreten
> > make[1]: „v8bse.node“ ist bereits aktuell.
> > make[1]: Verzeichnis „/home/stefan/src/2nd-tree/beast/ebeast/v8bse“ wird verlassen
> > LD_PRELOAD="/home/stefan/src/2nd-tree/beast/bse/.libs/libbse-0.so" \
> > ./node_modules/electron/dist/electron .
> >
> > Seems that there is a crash involved, as a core file appears in the ebeast dir
>
> > Seems that argcp is a nullptr here,
>
> Eeek, sorry, I ran into this a couple days ago, fixed it locally in Rapicorn and
> totally forgot about it.
> Just pull the fix from Rapicorn master now, you've diagnosed this correctly.

Ok, now that I've rebuilt everything, ebeast console works as advertised.

   Cu... Stefan
--
Stefan Westerfeld, http://space.twc.de/~stefan
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ebeast: electron + beast

Tim Janik-6
Good to see that it works for you.

I'm pondering to integrate the electron app build into the regular build
process, i.e. essentially make beast depend on npm and everything required
for electron ebeast packaging is then fetched via npm.
Well except for v8pp, that is. We'll have to maintain a patched version it seems
[1].

So I'm pondering to:

a) Possibly include a v8pp copy into beast, to spare everyone the git submodule
hassle (I don't know why git didn't opt to handle submodules *transparently*).

b) Introduce a hard dependency on npm and package ebeast via electron-packager +
several other modules that npm fetches.

Feedback, comments?



On 22.02.2017 17:50, Stefan Westerfeld wrote:
>> Eeek, sorry, I ran into this a couple days ago, fixed it locally in Rapicorn and
>> totally forgot about it.
>> Just pull the fix from Rapicorn master now, you've diagnosed this correctly.
>
> Ok, now that I've rebuilt everything, ebeast console works as advertised.
>
>    Cu... Stefan
>

[1] Due to an unmerged patch:
        https://github.com/pmed/v8pp/issues/39#issuecomment-281151273
--
Yours sincerely,
Tim Janik

https://testbit.eu/timj/
Free software author.
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ebeast: electron + beast

Stefan Westerfeld
   Hi!

On Wed, Mar 08, 2017 at 05:53:36PM +0100, Tim Janik wrote:

> Good to see that it works for you.
>
> I'm pondering to integrate the electron app build into the regular build
> process, i.e. essentially make beast depend on npm and everything required
> for electron ebeast packaging is then fetched via npm.
> Well except for v8pp, that is. We'll have to maintain a patched version it seems
> [1].
>
> So I'm pondering to:
>
> a) Possibly include a v8pp copy into beast, to spare everyone the git submodule
> hassle (I don't know why git didn't opt to handle submodules *transparently*).

Do what works for you. I can live with submodule stuff, and it is not so uncommon
these days. You could check if the file ebeast/v8bse/v8pp/v8pp/module.hpp (or something)
exists in configure, and fail with a "use git submodule" message otherwise.

> b) Introduce a hard dependency on npm and package ebeast via electron-packager +
> several other modules that npm fetches.

Would it be much more work to make it depend on npm and build ebeast by default,
but allow disabling it with a configure switch? (like --without-ebeast)

That would allow packagers to ship just beast (without ebeast) for the timespan
that ebeast is not yet considered ready for end users.

   Cu... Stefan
--
Stefan Westerfeld, http://space.twc.de/~stefan
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ebeast: electron + beast

Tim Janik-6


On 09.03.2017 12:52, Stefan Westerfeld wrote:

>    Hi!
>
> On Wed, Mar 08, 2017 at 05:53:36PM +0100, Tim Janik wrote:
>> Good to see that it works for you.
>>
>> I'm pondering to integrate the electron app build into the regular build
>> process, i.e. essentially make beast depend on npm and everything required
>> for electron ebeast packaging is then fetched via npm.
>> Well except for v8pp, that is. We'll have to maintain a patched version it seems
>> [1].
>>
>> So I'm pondering to:
>>
>> a) Possibly include a v8pp copy into beast, to spare everyone the git submodule
>> hassle (I don't know why git didn't opt to handle submodules *transparently*).
>
> Do what works for you. I can live with submodule stuff, and it is not so uncommon
> these days. You could check if the file ebeast/v8bse/v8pp/v8pp/module.hpp (or something)
> exists in configure, and fail with a "use git submodule" message otherwise.

I just figured that it broke the other night because the v8pp repo had a
non-linear update in the for-beast branch. *And* I figured I couldn't possibly
restore last month's exact configuration that way.
Which led me to read up on git submodule and I found lots of articles about why
you shouldn't use it (due to these and other problems).

I've since managed to replace the submodule use with git subtree in my local
branch, that essentially includes a squashed copy of the v8pp repo and looks
like an ordinary merge commit. So it is completely transparent to any beast.git
user, and you only need to fiddle with the git subtree command if you want to
pull new changes from v8pp upstream or if you want to push local mods.

>> b) Introduce a hard dependency on npm and package ebeast via electron-packager +
>> several other modules that npm fetches.
>
> Would it be much more work to make it depend on npm and build ebeast by default,
> but allow disabling it with a configure switch? (like --without-ebeast)
>
> That would allow packagers to ship just beast (without ebeast) for the timespan
> that ebeast is not yet considered ready for end users.

Ah, interesting input. That shouldn't be too hard, IIRC we can simply have a
conditional make dependency for 'all: $(CONDITION) app' and similarly for the
installation.

>
>    Cu... Stefan
>

--
Yours sincerely,
Tim Janik

https://testbit.eu/timj/
Free software author.
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Loading...