The scenario is easy - I create PDFs with wkhhtmltopdf, and sometimes I struggle with things like
window.performance
not supported by this version.
So scripts are not fully executed.
Until now my way to find errors like that, was to use the very old Windows Safari browser, that helped me finding these errors.
But now I have a script error with the old wkhtmtlopdf, that does not even show in windows Safari.
I found it (or not really) with heavy and nasty script changing (comment out the half), but I would like to know if there is a way to get the correct error with wkhtmtlopdf while parsing.
Run wkhhtmltopdf with the command line using --debug-javascript argument.
Related
I'm starting to work on a small firefox plugin, it's a basic js script, no problem on this side.
I've made a few successfull tests, and had a a few satisfying results. But starting yesterday, i'm unable to laod any temporary addons in firefox.
Everytime i try to start one (even a simple console.log("hello world")), i get the error message in the console:
Error: Can't find profile directory. XULStore.jsm:66:15
It work perfectly 2 days ago, the problem appeared yesterday, and, as far as i know, i didn't made any firefox upgrade.
I've made a few reseach, a found two usefull links, one on discourse.mozilla of someone that has the exact same problem ... but no answer, and another one on bugzilla saying this bug won't be fixed because it should last long ... https://bugzilla.mozilla.org/show_bug.cgi?id=1548017
I'm askign here because i can't find any solution to my problem, and right now, it's been 24h since i'm stuck in my development progress. I'm open to any suggestion that might work.
I've checked my profiles directory and files, they're existing and ok... and that's basically everything. I'm not familiiar with the tools available for firefox so, i might have forgotten to check basic things that might help.
P.S: i'm not using selenium at any time (i've seen a few requests here about a similar issue with selenium, but i'm writing vanilla JS here, so, i think it's not the same issue)
Various things are different in 1.0.136, e.g. running code with ctrl-enter has all sorts of strange behavior in an RMarkdown document, running code that has a syntax error somehow leads to all of the code being run in a block above (below?) the wrong code, etc. Sorry for not posting an MWE, but at the moment I just want to know if anyone is aware of these new "features" and if so how they can be turned off or better yet how I can just downgrade to the previous version of RStudio (which I can't currently find on the website).
Yes they changed some default settings that were present in the old interface.
Change the setting in markdown next to the knit button, from:
Chunk Output Inline -> Chunk Output in Console
Pictured here.
You can probably mess with the the Global Setting->Rmarkdowns under Tools to get it back the way it was before, but this was the fastest way for me.
I am trying to minify all js files (start with controllers and app.js). As we know that regular minifier (uglify etc) won't work directly on angularjs files because of module declaration conventions.
So I tried using ngmin for that.
Concatenated all files and then tried using ngmin - but get this error ...
C:\Users\Rahul\AppData\Roaming\npm\node_modules\ngmin\node_modules\esprima\espri
ma.js:3872
throw e;
^
Error: Line 1007: Unexpected token *
at throwError (C:\Users\Rahul\AppData\Roaming\npm\node_modules\ngmin\node_mo
dules\esprima\esprima.js:1156:21)
at throwUnexpected (C:\Users\Rahul\AppData\Roaming\npm\node_modules\ngmin\no
de_modules\esprima\esprima.js:1213:9)
at parsePrimaryExpression (C:\Users\Rahul\AppData\Roaming\npm\node_modules\n
gmin\node_modules\esprima\esprima.js:1567:16)
at parseLeftHandSideExpressionAllowCall (C:\Users\Rahul\AppData\Roaming\npm\
node_modules\ngmin\node_modules\esprima\esprima.js:1644:61)
at parsePostfixExpression (C:\Users\Rahul\AppData\Roaming\npm\node_modules\n
gmin\node_modules\esprima\esprima.js:1703:20)
at parseUnaryExpression (C:\Users\Rahul\AppData\Roaming\npm\node_modules\ngm
in\node_modules\esprima\esprima.js:1784:16)
at parseMultiplicativeExpression (C:\Users\Rahul\AppData\Roaming\npm\node_mo
dules\ngmin\node_modules\esprima\esprima.js:1790:20)
at parseAdditiveExpression (C:\Users\Rahul\AppData\Roaming\npm\node_modules\
ngmin\node_modules\esprima\esprima.js:1807:20)
at parseShiftExpression (C:\Users\Rahul\AppData\Roaming\npm\node_modules\ngm
in\node_modules\esprima\esprima.js:1824:20)
at parseRelationalExpression (C:\Users\Rahul\AppData\Roaming\npm\node_module
s\ngmin\node_modules\esprima\esprima.js:1845:16)
I believe the issue is related to running ngmin in windows environment. I shall try it again with Mac - but trying to gauge if anybody faced this issue and able to find any work-around ?
Thanks in advance ...
It looks like this might be related to concatenating. It's most likely not a Windows issue (I've run ngmin on Windows just fine). There's an open issue for this: https://github.com/btford/grunt-ngmin/issues/12.
I know the recommendation is to run it once on a concatenated file, but you might want to try running ngmin prior to concatenation and see what happens. If that ends up fine, try to concatenate afterwards.
I want to step into extension development for Gnome Shell, but I can't seem to understand how I do a few tasks in Looking Glass lg to actually debug my stuff.
When I type global.log("hi"); into LG, it throws me back r(...) = undefined. Why?
When I want to debug an extensions that doesn't load, how do I do that?
It would be nice to see why an extension can't be loaded.
I tried Main.ExtensionSystem.loadExtension() but it returns undefined no matter if I give it the extension's name string or the extension's object.
Where do I find documentation for classes, objects and member methods?
(The LG inspector does not seem to be able to inspect functions.)
If I had these resources I could at least start to work on updating some extensions for newer Gnome versions. I would not ask these simple questions if they would be nicely explained somewhere but getting all the info seems really tough (I've googled for hours).
1: LookingGlass is basically a GJS console. It allows you to execute and test lines of GJS, grab and manipulate objects and use r(...) to use results in following commands.
The reason you get r(...) = undefined is because log(String); does not return anything, thus the result is undefined.
2: Either log throughout init() and enable(), then check where it breaks and try to pinpoint the breaking line using log or commenting out lines of code (although the culprit is probably defined in the general logging, described in the section at the bottom).
3: There is no official documentation. They have some outdated tutorials for GNOME Shell 3.4 with a small difference explanation to 3.6, a few pages on the C(++) ends of the libraries you use (most of the functions, variables and constants use the same names though), but for any real info you'd need experience, digging through other GNOME and shell extension code or some unofficial sources. Unofficial sources aren't always up to date, however.
Up to date generated docs at RooJS, although at least events are off as they are separated with - (minus) rather than _ (underscore).
Old, but mostly useful documentation, MathematicalCoffee has more useful things, like in depth explained code that is quite a solid learning source.
Generated docs, almost everything is there, very extensive, but sometimes the site drops offline for a few days. You could try to clone the git repo to run it locally, but the readme.md is a verbatim copy of what they forked...
More recent reference made by a user, although this is quite extensive, it's not of much use if you're on an older version of GNOME Shell, as deprecated and old is more likely to work than next gen stuff.
I recommend checking the official extensions website and go through whatever interesting extensions' source code you can get, as that is your best bet to learn anything.
Generally Debugging gnome can be done in several ways.
- use the log() function and follow journalctl in a commandline, check either GNOME or JS, use journalctl -f | grep -i js (or use grep -i gnome). You will see some warnings no matter what, but most mention what extension they're from. This is nice and works on all distros implementing systemd
- Or log a specific process that is a part of GNOME like journalctl /usr/bin/gnome-session -f -o cat, just beware that some distros and versions log to different files and old GNOME versions often log to whatever your display manager logs to.
- use the official (albeit tricky) manner of logging: GNOME on debugging.
I personally couldn't get this to work.
When working on a large Firefox plugin, I sometimes accidentally make a syntax error not caught by my editor. When this happens, then calling
Components.utils.import("resource://modules/Foo.js")
will simply fail to import or return anything, without any kind of helpful hint as to where in the file to look for the syntax error. Is there any way I can get Firefox to give me some kind of clue when my imports fail?
EDIT: I fixed my own problem, which turned out to be that I was using code which had a global reference to the navigator object. What made this especially annoying was that the code would work when loaded in the browser (as Wladimir suggested below), but would still fail when importing in my extension.
Eventually I resorted to a sort of manual binary search: I'd delete half of the file and then see whether the import still failed. If so, then I'd delete half of what remained and repeat. As soon as it didn't fail, I had a more precise notion of where the problem was, which allowed me to either continue the binary search or scan the smaller area manually looking for the problem.
This is extremely time-consuming and I'd still appreciate any suggestions about how to speed up this debugging process.
The issue here is most likely the one described on https://developer.mozilla.org/en/Exception_logging_in_JavaScript and setting dom.report_all_js_exceptions preference to true should work. I must admit that I haven't tried that however because setting this preference makes the error console very noisy. Instead I use an ugly hack and load the module as a script in a local HTML file - this is enough to show me syntax errors and fortunately isn't something I need to do all too often (it is only an issue with syntax errors, runtime errors are reported as usually).