I'm trying to implement Svelte in some parts of my web but I can't debug it with chrome devtools.
I generate sourcemaps to see the source svelte component and it let me add breakpoints but when going next step, the debugger breaks and it jumps lines.
In the example the debugger is stopped in the first line of the click handler and it works perfect: can see variable value etc.
But, when clicking the "Next step" button to go to the else statement the debugger breaks.
As you can see, the debugger is stopped in the ], but it should be stopped in the line 9. That occurs also if you put another breakopoint in that line.
I know I can use #debug in template and console.log's in javascript but debugger is more powerful.
Hope this will help you
I'm not seeing any error for debugger.
As the value of name is availableNames[0] so its 'Christian'.
As you can see, the debugger is stopped in the ], but it should be stopped in the line 9
Debugger shouldn't stop at the line 9 cause condition is met with line 6, so it will go inside that if block.
I did a try locally. I see a normal behaviour as expected in your comment. Maybe you have an issue with the browser it self, not svelte
First click
Second click
Finally I think is a bad sourcemap generator. I've tried a new project cloning this repo https://github.com/sveltejs/template and it works as expected. Maybe Vite is generating wrong sourcemaps for Svelte components.
Related
I recently installed Pycharm on a fresh PC. Unfortunately something seems to be off with the installation. When I try to enter the debug console this isn't loading. E.g. for a very simple test case
def test_stable():
1 == 1
2 == 2 # breakpoint in this line
when I add a breakpoint in the last line, it is stopping the execution correctly, but I can't enter the console (i.e. the little wheels keep spinning):
What is wrong with my installation here? Is this a known issue?
Edit:
When clicking the "Show Python Prompt" button a console opens, but the console is not working, there is no output from it:
As I said above I believe this is connected to the strange behavior in the Debug Console tab.
Edit 2:
As recommended by #bad_coder I changed the test to
class Test:
def test_trivial(self):
test = 5
assert 1 == 1 # breakpoint on this line
I still can't use the debug console. I also just started up my old system and can now confirm that there when clicking on console I am directly getting to the console and not the situation of my first image (with the animated spinning wheels).
The button you're looking for is the Python-with-a-prompt button, which switches between the console and test progress.
If someone stumbles across the same issue, I believe the problem here was basically just that the Pycharm version was rather old. After downloading the current version everything works fine.
I am new to Laravel. When I am in debug mode I get the following errors every time every page loads:
The payload is invalid
After pressing two times on Continue I get the error
The MAC is invalid
The error messages are located inside the encrypter.php file. After pressing "Continue" again, I can proceed with debugging with breakpoints and so on, and everything works fine. The $payload-variable is null.
The project is still very basic. Only some things like CRUD like explained on tutorials.
What is payload? And am I missing some kind of configuration? How to get rid of these error messages?
The answer is found in this post:
Can't using Visual Code to debug in Laravel project
I also:
closed VS Code Editor
cleared all history in my browser, including cookies and cache
ran the commands as mentioned in the post inside the windows cmd window (so not the integrated terminal inside VS Code Editor)
I am working in an ember application. The version is "ember-cli": "1.13.13".
For a very strange reason, debugger doesn't work in Chrome. (I also tried Safari, and Firefox developer's edition. Same thing.)
Specifically, the problem is I put a debugger statement in a function. Ember app loads and hits the function and the debugger statement in the function. What happens in the Developer Tools -> Sources tab is that it doesn't show me the function that the debugger is in.
Instead it keeps highlighting the last line of app-boot.js file. The breakpoint, or the line that it's paused on, is not showing up at all. (see screenshot attached)
Furthermore when I step into the function call using the down arrow, it remains at app-boot.js, so I have no idea whether it did step into the function or not.
This has been plaguing me for a while now.
I've resolved many times similar error on OSX + Chrome by using Empty Cache and Hard Reload - after that code in Sources tab was updated and I could correctly see actual source code.
Make sure you didn't blackbox scripts of your application.
Alternatively you could try to reinstall npm packages, bower packages - it might be issue with creating source maps in Ember CLI.
If nothing helps please investigate your JavaScript and associated map files and check if something might be missing, or maps don't update. You could possibly try turning them on and off in Ember CLI.
See Source Maps section in Ember CLI guides how to enable/disable them.
I don't know what has changed on my setup, but it used to be that when my (Swift) code crashed, the debugger would show the offending line of source code.
Now no matter what the problem is, the debugger only highlights the line in AppDelegate.swift where UIApplicationMain is defined.
I can tell by putting in print statements more or less where in the code the problem arose, however... what's the point of having a debugger if it never conveys any information and I just have to do everything "old school" with print statements -- especially if there are asynchronous processes going on in which the print statement isn't necessary a reliable indicator of where the crash occured?
I've seen threads from years ago that talk about going into "Preferences -> Behaviors" and modifying what gets shown when the code exits unexpectedly. But (a) I never needed this in the past, and more importantly (b) this seems to have no effect, i.e. the debugger is still just quitting on main.
Is there a good way to get the old, specific, debugging behavior back?
I'm currently running Xcode 7.0, but this behavior occurs with 7-GM Seed, and even now when I go back to try 7 beta 5 and beta 6, which used to work.
Go to the Debug Navigator (cmd-7), click the plus button in the bottom and select Add Exception Breakpoint. This will break at the actual line where the problem happened.
In the exception breakpoints detail editor create debugger command action and in the text box enter po $arg1. This will show the error message in the debug console.
The previous answer was on the right track, but this answer is more relevant today:
On Xcode 9.2 with Swift 4, do this:
Use Command-8 to bring up the Debug Navigator.
Click the + in the lower left
Select Swift Error Breakpoint
That's it! :)
I'm currently (trying) to develop an app with Worklight Studio 5.0.6 and Dojo (Mobile) 1.8.3. I have a really hard time to to find a proper method for debugging. After waiting 5-10 minutes for the build an deploy-process on the server, an error usually looks like this in the Chrome debugger:
How am I supposed to track down this error in MY source? The whole stack trace consists entirely of Dojo code which generates an absolutely useless error message after 20 abstraction layers.
Seriously, how do you guys handle this in real life? What methods do you use for debugging Dojo-driven apps in the browser?
spyro
For dojo.parse errors, I find it useful to pause the Chrome debugger on all exceptions (the purple icon on your screenshot, should be blue). You usally get more details about the cause of the error, the name of the DOM node being parsed, etc. in the first exception being raised.
Rémi.
Debugging dojo based application should be the same as debugging any javascript application.
Usually I will follow these steps:
add console.log() somewhere in code: this is fast and most of time this is enough.
set breakpoint in debugger: if step 1 is not enough, you can base on error information to set breakpoint before error line, then step in or step out.
comment out recently changes: for some error which is hard to find the error line, for example, parse error in your case, the good way is comment out your recently changes one by one till back to your last working version. Or, return to your last working version, then add code back one by one.
Create a simple application to reproduce the error : if your application is very complicate and it is hard for you to follow above methods, you can try to create a new application which mimics your current application but with simple logics and try to reproduce the error.
Based on experience : Some errors, for example, extra ',' in the end of array which works at chrome and firefox, will report a nonsense error information at IE. Debug these kinds of errors is very difficult, you can base on your experience or do a google search.
Did you provide isDebug: true in your dojoConfig? Also, try to see if the same occurs in other browsers.
Update: I recently discovered that there are issues with Google Chrome and Dojo debugging and I think it has to do with the asynchronous loading of files. As you can see in the provided screenshot of #spyro, the ReferenceError object is blank (which you can notice because of the empty brackets {}). If you want to solve that, reopen the console of Google Chrome, (for example by tapping F12 twice). After reopening the ReferenceError should not be empty anymore and now you can expand that object by using the arrow next to it and get a more detailed message about what failed.
Usually what I do in situations like that is to place a breakpoint inside the error callback (line 3398 in your case) and then look into the error variable ("e").
I am not sure how familiar you are with the Web Inspector, but once you hit the breakpoint open the Web Inspector 'console' and check for the error properties "e.message" and "e.stack" (just type in "e.message " in the console).
Also, during development it is better to avoid Dojo optimization / minification, which greatly improve your debug-ability.
Bottom line is to try to place the breakpoint before the error is thrown.