In the image above, the left side is Firefox's console, and the right side is Chromium's. Most of the time I find Firefox's more easier to track down at first glance, but sometimes I have to use Chromium's console to find the problem easily (with one look).
But inside Node.js, I'm always stuck with the V8 version. Is there any way I can get errors like SpiderMonkey without linking debugger and Firefox or doing any hard work? I mean is there any flag on V8, any trick/settings I can do to get the actual undefined variable, instead of the property that was trying to be accessed?
Also I'm curios to know your personal opinion on the differences of the two on accessing properties of undefined variable, and which one is most of the time suitable for you. Please share.
Thanks.
No, there is no flag or trick to make V8 produce the error messages that SpiderMonkey would produce, or vice versa.
Also I'm curios to know your personal opinion
StackOverflow is not the right place to discuss questions of personal opinion.
If you want to file a feature request for different error messages, you can do so at crbug.com/v8/new -- that's the way to get the V8 team to consider your suggestion.
Related
So I've recently started using Typescript. Both for the back end (nodejs) and front end, and I'm started to feel an urge to chew on my own arm every time I have to add a new import.
Coming from the .NET world the last 15 years I've come to appreciate the more or less automatic type resolving. Especially with a background in C/C++, which whenever I return to, remind me of the #include hell that ever so often becomes the case. Given what I am now facing, I get a feeling of "those were the days".
I typically prefer to keep my code as one class -> one file (with some obv exceptions for smaller stuff). This results in a lot of files and even more imports. I recently discovered some tools that help out creating the imports but it is still really annoying.
I get it that the underlying JS needs these imports (in various ways depending on module system) But given how easy these tools resolves the imports. Would it not be possible for the compiler to simply generate them? In the rare case of ambiguity the compiler would simple give an error and the user needs to resolve it manually.
Typescript seems to be a great language otherwise but this is really close to a deal breaker for me. Or am I missing something? Can this be done in a better way?
Node.js displays standard exception messages in terminal, that are:
messy
hard to understand
pointing to lines in compiled js files.
making it hard to tell, where an error in question is located in sources.
Is there a package, that makes standard output more nicer and shows, which line made exception in sources.
I looking for plug and play solution, that will just work out the box.
Thanks.
pointing to lines in compiled js files.
The errors are pointing to lines of the code that is actually being executed. Node doesn't know if you wrote it yourself or not.
It seems that you're using a transpiler (which you didn't mention in the question) and that is not something that I necessarily recommend, nor it is a common use case in Node development. But when you do use a transpiler for whatever reason then you need to use Source Maps to have the errors point to the original source code and not the transpilation result, just like you do on the frontend. Search for Source Maps support in Node and Babel or whatever transpiler you're using.
Unfortunately you're unlikely to find exactly what you ask for, i.e. a plug and play solution, that will just work out the box, making errors less messy and easier to understand. Errors are usually complicated things with a lot of context and Node is already doing a pretty good job of providing that context. But you can always write your own handler to print better error messages having the context available in the Error object - See:
https://nodejs.org/api/errors.html
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error
In practice you should never rely on Node's printing the Error object directly. You should write your own meaningful and easy to understand error messages, preferably using a module like Winstonm, Bunyan, Log4js, etc. to handle and log the error messages.
Most popular: verror
The error classes it supports:
printf-style arguments for the message
chains of causes
properties to provide extra information about the error
creating your ownsubclasses that support all of these
518,775 downloads in the last day
3,387,126 downloads in the last week
13,950,439 downloads in the last month
I'm working on a website with Visual Studio Code.
Is there a way to save only the files being used by a project into a separate folder?
Basically what I'm looking for is a tool which would scan all the local resources linked by all html files (meaning linked images, videos, files), and then it would save them all in a separate folder.
The reason why I'm asking this is because at the moment I'm testing things out, meaning I'm using image A, then image B, C and so on so forth. These images live in subfolders, so now I ended up with some images which I'm actually using in the html pages and some which I'm not. The thing is, is not simple to check which images I'm using.
You'll find the same principle in 3d applications, such as 3ds Max for instance, where, once you're done with the project, you can use a Resource Collector tool to strip out all the unused assets and save only the ones used by the project.
I've looked for an extension or a solution to this without any luck, so I guess an extension does not exist yet, but I think it would be a nice tool.
I don't understand why someone downvoted my post.
Either what I'm asking is already possible, although like I said I searched and I didn't find anything, or who downvoted consider my request stupid.
Whatever the reason, I believe it would be more mature to give a proper answer, even if whoever downvoted did it for either one of the two possible reason above.
In fact:
The solution already exists: like I said, I didn't find it, so if someone knows the solution why not simply posting it here?
The solution doesn't not exist but someone thinks it's a stupid idea. Well, it is not and it would be polite and civilized to discuss it.
In the current era it became so easy to express opinions without actually doing anything, by simply pressing a button to say nothing valuable, as a "I like".
I never stop feeling amazed where the social media behavior it's taking us.
This question might be too detailed for this forum, but I could not find a mailing list for duktape. Maybe this question will be useful for others trying to get duktape running on more obscure hardware.
I am trying to get duktape to work on an old ColdFire CPU, using an OLD gcc compiler (2.95.3). The board has limited resources (flash/RAM) but I seem to have enough of both. I must live with the old compiler.
I believe the duk_config.h is calculating the right options regarding endianness, etc. I am using a number of the duktape options to reduce code and data size. I have successfully used the same configuration on 64 and 32 bit Ubuntu and it works fine.
The "properties string" that is formed and set in duk_hthread_create_builtin_objects() is:
"bb u pnRHSBOL p2 a8 generic linux gcc" which seems correct (not sure of the effect of the "generic" tag for architecture).
I am getting a failure when calling duk_create_heap(). I have isolated the problem to a what I believe is a JS compile error related to duk_initjs. If I undef DUK_USE_BUILTIN_INITJS, initialization works. The error is a syntax error (not sure where yet). By running "strings" on my executable, I can see that the javascript program source string is there. As a side issue, when this error occurs, the longjmp doesn't work (setjmp never called?) so my fatal handler gets called, but I don't care about for now.
I thought it might be my small C stack (as it appears the js compiler uses recursion) but making the stack much larger didn't help.
I am starting to dig into the JS compiler, but this must be an issue with the architecture or my environment. Any suggestions appreciated!
EDIT: I just now noticed a post of a similar issue, and there was a request to repeat with "-DDUK_OPT_DEBUG -DDUK_OPT_DPRINT -DDUK_OPT_ASSERTIONS -DDUK_OPT_SELF_TESTS" I will try to use these options (if possible, I am very close to a relocation limit on my executable).
There was a bug in 1.4.0 release (https://github.com/svaarala/duktape/pull/550) which caused duk_config.h to incorrectly end up with an unpacked value representation even when the architecture supported packed representation. This might be an issue in your case - try adding and explicit -DDUK_OPT_PACKED_TVAL (which forces Duktape to use packed representation) to see if it helps.
Looking at http://developer.plone.org on how to check for a permission the first two results are:
http://developer.plone.org/reference_manuals/external/plone.app.dexterity/advanced/permissions.html
http://docs.plone.org/4/en/develop/plone/security/permissions.html
The first one advocates for zope.security.checkPermission while the second prefers a AccessControl.getSecurityManager().checkPermission.
Looking at the setup.py of AccessControl I see that it depends on zope.security, so the later is more low-level so to say, but at the same time zope.security seems to get more attention nowadays while AccessControl seems to be more stable (regarding getting changes on it).
So, I'm wondering which is the safe and up-to-date way to check for permissions.
I personally always use the checkPermission from AccessControl, but I believe under the hood both zope.security and AccessControl will be calling the same code. I've looked for this code before and I think it's actually in the C portion of the roles/permissions logic.
I personally prefer using plone.api.
See plone.api.user docu
This way you don't have to care, about the low level api.
Even if it will change in the future, plone.api will fix it for you :-)