Tools for debugging electron (e.g. safe_examples/demo_app)

If anyone is poking around in the demo_app code, which is a node.js application using the electron framework, please share your tips, tools etc on this topic.

I’ll start with the first post about using node-inspector and eclipse/nodeclipse (on Debian)…

1 Like

Debian

I’m on Debian Jesse and like eclipse, but node-inspector seems the most promising.

node-inspector

This seems to work like a dream, although I have not tried using the debug features yet. I have just run the demo_app from within the debug console and it seems to work great :slightly_smiling:

You’ll need Chrome installed first.

npm install -g node-inspector
cd safe_examples/demo_app
node-debug tasks/start.js

eclipse

eclipse is good for browsing the source, but not working for debugging so far.

I’ve installed nodeclipse within eclipse
On the command line you seem to need to run this:

cd safe_examples/demo_app
node --debug-brk tasks/start.js

Then in eclipse you right-click on start.js and choose Debug As > Node Application

I quickly get an error in the console and the code is not running. So, this doesn’t work for me yet.

1 Like

Much of the logic is also in the frontend when developing in electron. For the safe launcher frontend and the safe demo app frontend, since the devs used common boilerplate approaches, it appears the regular chrome dev tools will be opened if you start from local node instead of a dist. Of course that’s just for debugging the frontend part. You might find either atom or vscode as decent backend approaches for debugging (e.g. breakpoints and what not)…

2 Likes

@cretz I have zero experience with node so I don’t understand the terms you are using here (“local node” and “dist”). Can you explain a bit more for a complete node noob? :slightly_smiling:

Can you also explain what you mean about the frontend and backend here - is it something like electron boilerplate versus something else? Or you can elaborate a bit about what you observe about how the demo_app has been put together, I could then google about the bits for more info.

I have very little time to spend, so can’t learn this stuff from the bottom up. I’m just jumping in at the deep end and poking around.

1 Like

Basically if you start the executable it is in “dist” (i.e. “production”) mode. If you start from a CLI w/ node locally, i.e. npm install on first clone, and the npm start, it will be in “development” mode which means the Chrome dev tools are embedded because of the conditional in app/background.js. This is basically using the boilerplate from https://github.com/szwacz/electron-boilerplate which is a pretty popular way to bootstrap Electron app building these days.

In Electron parlance this is actually known as “main” vs “renderer”. The former is a headless node app and the latter is the embedded chrome browser. IPC is commonly used to communicate between, granted a lot of people just embed a bunch of node code inside the renderer side. Electron’s docs explain all of this: http://electron.atom.io/docs/v0.36.8/tutorial/quick-start/.

I don’t really like Electron but it’s the best viable option for apps that need a cross platform UI with tons of features and not force C++ on people.

Understood. Unfortunately with some of this, the ecosystems are so large that keeping up is almost a full time job. My day job is as a Scala dev, so I also have to use hobby time here and I have kept up with Electron/nw.js. I would recommend running through the Electron quickstart. An easy way is just to follow https://github.com/szwacz/electron-boilerplate#quick-start and you can see how it makes running an app easy. From there it’s just tinkering depending upon what you want to do.

Also I would strongly discourage use of Eclipse for this. I use Sublime Test 3, but admittedly Atom and especially VSCode are better IDE-ish editors for this use case (and guess what their runtime is? :-)).

2 Likes

Thanks @cretz that is extremely helpful :slightly_smiling:

I use ST3 too, but it is quite a lot of work to get into its features and I’ve not got on well with it, so not using it to its potential, so for me it’s a nice, snappy, but basic editor. I like eclipse because it is easy to use it for all kinds of different task with a single UI, and nothing new to learn. As I only get time to dabble lightly these days, anything that “just works” helps me more than something that will do a better job if I put time into learning and customisation.

To prove how helpful @cretz and @Krishna_Kumar have been, I now have a modified version of safe_launcher running in a debugger…

As you can see, this includes a link to the SAFE Webring once you have logged in.

Build and run instructions for this (on Debian 8/Jesse):

# Assumes:
# 1) You have npm installed and have a directory called ~/src/safe-stable
# 2) You have downloaded the safe_launcher demo and unpacked it in ~/safe-releases/2016-03-08/safe_launcher-linux-x64
# 
#   (Note: some steps are repeated to make copying and pasting sections easier).

npm install -g gulp

cd ~/src/safe-stable
git clone https://github.com/maidsafe/safe_ffi/
cd safe_ffi
cargo build --release

cd ~/src/safe-stable
git clone https://github.com/maidsafe/safe_launcher/
cd safe_launcher
npm install

cd ~/src/safe-stable
cd safe_launcher
cp ../safe_ffi/target/release/libsafe_ffi.so app/api/ffi

# Resume here after any code edits...
gulp package --env=development

# Copy the config file from the MaidSafe safe_launcher download. This allows you
# to connect to the live testnet.
cp ~/safe-releases/2016-03-08/safe_launcher-linux-x64/safe_launcher.crust.config ./app_dist/safe_launcher-linux-x64

# Run the result
./app_dist/safe_launcher-linux-x64/safe_launcher
6 Likes

You don’t need to package the whole thing. Just “npm start”, ref: https://github.com/maidsafe/safe_launcher/blob/master/package.json#L34. This also watches for local source changes and automatically applies them.

@cretz If I understood him correctly, according to @Krishna_Kumar this was necessary in order to be able to join the live testnet. But I could be wrong. Anyway, the above works! :slight_smile:

2 Likes

@happybeing, one more method to connect to the live network using npm start

  1. Compile the safe_ffi and copy the ffi dependency to the launcher as you have detailed
  2. Copy the safe_launcher.crust.config to safe_launcher\node_modules\electron-prebuilt\dist

I hope this should also help in connecting to the live network using npm start.

Not tested on all platforms though. Just sharing :wink:

2 Likes

ooooof. just got to trying this this morning.

Went down a tooling rabbit hole.

On ESX El-Cap, i had npm i failing as a consequence of libtool coming from a Mamp install.

If you get a failing npm i which something akin to unkown option libtool --static, check which libtool. The MAMP install was my problem here (not homebrew, which did have it’s own unconnected problems. That was a fun 15 minute diversion).

I found the answer here: https://gist.github.com/DanHerbert/9520689#gistcomment-1396814

Which for me was sliiightly different due, probably, to MAMP versions:

Make a backup of MAMP libtool:
mv /Applications/MAMP/Library/bin/libtool /Applications/MAMP/Library/bin/libtool_bkp

And symlink to your actual system libtool:
ln -s /usr/bin/libtool /Applications/MAMP/Library/bin/libtool

This fixed it for me, so I could finally npm i in the project folders. OOOOF.

So now: To play :smiley:

1 Like

@happybeing Sublime Text 3 is pretty awesome.

If you get the [package control] (https://packagecontrol.io/installation) adding new features is crazy easy.
(ctrl-shift-p to bring up the control box, and you can type install and then search for packages / feature sets.

Another nice feature is setting up snippets (tools>snippets). My most used one for javascript is surely:

<snippet>
    <content><![CDATA[
console.log( ${1:"THIS IS HAPPENING"} )
]]></content>
    <!-- Optional: Set a tabTrigger to define how to trigger the snippet -->
   <tabTrigger>cl</tabTrigger>
    <!-- Optional: Set a scope to limit where the snippet will trigger -->
    <scope>source.javascript</scope>
</snippet>

so when i type cl and tab, I can easily log a string, or variable. (you can do many at once with something like: console.log( "This thing", aVariable, someThingElse ); And then check for the output in the console.

1 Like

Thanks @Krishna_Kumar!

Thanks @joshuef I’m glad you have it rolling!

I hope others will be inspired to have a go and we can all help each other.

I agree Sublime Text 3 is a much better editor than Atom, but I’m still not used to it so tend to flip between ST3 and Eclipse (and vim :blush:). I tried Atom because it has a Node Debugger plugin that seems very nice, which I almost got working with the launcher! :slight_smile:

Hey, I invented HTML Snippets :smile: Probably not the first, who knows, but I had them in my Agile HTML Editor in the 90’s. :smile:

1 Like

Should this be safe_launcher.crust.config or electron.crust.config? I haven’t succeeded in connecting my self-built safe_launcher to the real network yet.
But copying safe_launcher.crust.config seemed to have no result (it didn’t make any attempt at connection, just as without the file). On the other hand there was a virtually empty electron.crust.config in node_modules/electron-prebuilt/dist, which I overwrote, after which it at least gets to some different error :slight_smile:

thread '<unnamed>' panicked at 'Unable to start crust::Service FileHandler(JsonDecoderError(MissingFieldError("enable_tcp")))', /home/user/safe/routing/src/core.rs:269

(this must be a version conflict, I’ll actually try to build the right version of safe_ffi, currently 0.5.0, next)

This should be the file name. The convention followed by crust is, <binary_name>.crust.config. So it should be electron.cruct.config.

I hope the ffi was built without the mock-feature.

I will try this one quickly in few mins and post back here

ffi was built without the mock feature, but I’ve used git master of safe_ffi (along with master checkouts of everything else) instead of 0.5.0. So that probably has an API issue. Trying to build 0.5.0 independently fails for me:

$ git clone https://github.com/maidsafe/safe_ffi.git
$ cd safe_ffi
$ git checkout 0.5.0
$ cargo build --release
    Updating registry `https://github.com/rust-lang/crates.io-index`
no matching package named `mpid_messaging` found (required by `safe_core`)
location searched: registry https://github.com/rust-lang/crates.io-index
version required: ~0.2.0
versions found: 0.1.0, 0.0.4, 0.0.3, ...

I’m a newbie at rust, so I may be doing something obvious wrong.

1 Like

The safe_ffi master branch is not building at present @ustulation will be fixing it soon.

But I tried to test connecting the live network, i managed to connect to the network.

  1. safe-launcher > git checkout -b branch v4.0 1e821458a7047b923d80699396c131c12cca347d
  2. Copied the config file from release package, renamed it to electron.crust.config and placed it near the electron binary
  3. Copied the safe_ffi.dll (I use windows) from the release package to the app/ffi folder.

Finally ran, npm start and I was able to connect to the network.

Once the master branch of the safe_ffi is fixed, the master branch from safe_launcher should also work fine

I believe, there is some dependency mismatch. @ustulation is looking into this right now. Will update here, once the issue is resolved. Thanks for patiently trying it out.

0.5.0 had a dependency on version of safe_core which had a dependency on mpid_messaging. This messaging crate has been yanked out and deprecated as we have a new one - safe_network_common. So maybe versions older than 0.6.0 for safe_ffi are no longer useful ? Try with 0.6.0 - seems fine on my machine.