Errors thrown when loading node(pack)s are ignored

[savire]

Errors thrown when loading node(pack)s are ignored

[steve2507]

HI @savire ; the only potential issue I see with your config right now is that the paths in your config.json contain both backslashes and a forward slash at the end. I'm doubtful this is actually the issue, but if you could treat them all the same than would at least let us know for a fact :)

I do not have access to a windows machine at the moment. I will come back later today to try and reproduce this.

[savire]

Hi @steve2507,
Thank you for replying. It does not matter though as you've also said it. I've tried forward slash too but its still not working.

Is there a log file somewhere we can check to where xible read its nodes because I've only see flows folder listed when its started like below:

 xible {
  xible   node: '12.16.3',
  xible   v8: '7.8.279.23-node.35',
  xible   uv: '1.34.2',
  xible   zlib: '1.2.11',
  xible   brotli: '1.0.7',
  xible   ares: '1.16.0',
  xible   modules: '72',
  xible   nghttp2: '1.40.0',
  xible   napi: '5',
  xible   llhttp: '2.0.4',
  xible   http_parser: '2.9.3',
  xible   openssl: '1.1.1g',
  xible   cldr: '36.0',
  xible   icu: '65.1',
  xible   tz: '2019c',
  xible   unicode: '12.1'
  xible } +0ms
  xible initWeb +4ms
  xible:config loading "config.json" +0ms
  xible init +159ms
  xible startWeb +4ms
  xible:express starting on port: 9600 +0ms
  xible:express starting plain (http) +0ms
  xible:express listening on: :::9600 +4ms
  xible:websocket listening on port: 9600 +0ms
  xible:cliqueue Queue file created +0ms
  xible PID file created +102ms
  xible:flow init flows from "D:/New/VE/XIB1/flows" +0ms

[steve2507]

Logging the nodepack directories certainly would make sense, but at the moment it only logs if an error is encountered.

[savire]

Yeah I've tinkered a bit earlier with the local xible codes. Found that this part causing error on this setup:

 try {
        // Object.assign(nodePacks, this.getByPath(`${__dirname}/../../nodes`, true));
      } catch (err) {
        console.warn('Failed to include nodes directory', err);
      }

I've commented it out.

Also seems like the Node must be wrapped within a Nodepack before it can work. I kinda assume it can work alone from the Doc when reading it first time.

Also if there is error on the structure.json it just silently proceed without loading it and we don't know anything about it. I think for debug-level command line switch its nice to have options to list what has been loaded so far, especially if we want to develop Nodepack locally.

[steve2507]

The line you commented out is a directory used for development purposes of nodepacks. Starting xible directly from the xible installation directory using npm run debug will automatically restart xible on changes within that directory.
The warning message that's thrown if the ./nodes directory does not exist can simply be ignored.
But indeed, it is not pretty. I'll see if I can move that to a command line argument.

A single node in a nodepack (without subdirectories) should work. I have just tested that with solely a package.json & structure.json in a directory within my nodes.path. Could you specify your exact directory structure for me to reproduce?

Currently, a syntax error in a structure.json would be caught in getStructure(): https://github.com/SpectrumBroad/xible/blob/master/app/Node/index.js#L204, but it's subsequently ignored by the caller getStructureS()
I'm currently working on a new version with more logging for the nodepacks. Should be out within a day or two.

Thanks for the feedback!

[savire]

Hi mate,

Ah okay so that was for auto restart feature, did not notice it yet before.

Yes a single node within a nodepack is working as expected. It was just I assumed that we can just drop a node without a nodepack created beforehand when reading the documentation since I just kinda skip to the node part earlier.

Yes that will be a good updates mate for this awesome project. Thank you so much for your information. Really appreciates it 👍

I'm closing this issue now.

[steve2507]

v0.20.0 has been released addressing the logging improvements mentioned in this thread.
Thanks again @savire !