Closed stefan-leye closed 6 years ago
I’m running into this as well.
xregexp should behave as expected again.
I'm looking into moving to 'scoped npm modules' so that I can get rid of the github#master references and still have a fast turn-around while developing.
I just ran
npm install https://github.com/GerHobbelt/jison/archive/0.4.18-186.tar.gz
node_modules/jison-gho/lib/cli.js node_modules/jison-gho/examples/ansic.jison
on macOS 10.12.6 and still get
module.js:491
throw err;
^
Error: Cannot find module 'xregexp'
at Function.Module._resolveFilename (module.js:489:15)
at Function.Module._load (module.js:439:25)
at Module.require (module.js:517:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (/…/node_modules/jison-gho/lib/util/regexp-lexer.js:7:15)
at Module._compile (module.js:573:30)
at Object.Module._extensions..js (module.js:584:10)
at Module.load (module.js:507:32)
at tryModuleLoad (module.js:470:12)
at Function.Module._load (module.js:462:3)
WARNING: work is underway to solve this, but be reminded that build 0.6.0-187 still hasn't been round-trip tested, so expect another release after that one before this can be said to be 'solved'.
For those curious folks: 'round trip testing' means running this sequence with zero failures:
make superclean make prep make
which will clean the NPM node_modules/ stores, re-install the npm packages and then run all the builds and tests.
Okay, I think I've got it nailed now. Sorry for the trouble y'all had. Release 0.6.0-188 should not exhibit this problem anymore.
Notes on that release: a few things have changed, though nothing major unless:
%parse-params
in your grammar files: from 0.6.0-xxx forward all %parse-params
end up in the yy
shared context object, saving us quite a bit of parameter passing call overhead in both parser and lexer, orparseError()
API this
reference to point at the yy
context: that is not true any more: this
will reference the current parser or lexer instance (to be precise: the instance that invoked this particular parseError()
); yy
is available inside parseError()
via the hash
parameter already.@stefan-leye : I saw you forked the repo; can you help me and confirm / deny that this issue is fixed in this release? Do you observe other behaviour which might bother you? (e.g. #12)
Thanks!
fixed in latest release 0.6.0-191; jison dependencies now use scoped packages where necessary (https://docs.npmjs.com/misc/scope) plus npm's package-lock.json
should really fix this issue as it stores the unique hash for every dependency as it has been installed on the machine which produces the release(s).
@stefan-leye: ping? Can we confirm this fixed with -191 or later?
(FYI: I've switched to using scoped packages for the submodules so this type of problem should be gone or at least severely mitigated in the future.)
@GerHobbelt ah sorry, for not replying. I switched to an older version of jison, that works for our project. To avoid breaking thinks we update our dependencies on the start of a development cycle, only. So I cannot check the problem until the next development cycle starts (propably in November). Feel free to close the ticket, if you don't want to wait..
Thanks for the info, I'll keep it open then until you get an opportunity to verify.
(Off-topic: I hope to have some more work done on jison by November -- fingers crossed :wink: -- so it would be great to hear about your experience then. (the main issue now is documentation; others using this helps as a strong motivator to give that one a fresh shove in the gluteus maximus)
@GerHobbelt finally tried it out. Everthing works fine :)
Superb! 👍
I'm going to close this issue; if anything pops up, please create a new one and reference this one (or re-open this issue).
Enjoy!
Since yesterday I get the error message: "Cannot find module 'xregexp'", when using the parser generator. A bit of investigation showed that the xregexp dependency points to the master of a forked xregexp lib, that has been changed in the last hours.
I think we have two issues here: