Unable to set breakpoints inside node_modules (WebStorm) - webstorm

I use Webstorm to debug my applications. Setting breakpoints works great and my breakpoints will be hit by the debugger. If I set a breakpoint inside a script that is inside node_modules, then it doesn't work anymore. It should have something to do with WebStorm, because Node Inspector works fine with the same code.
It seems to be generic for all packages, but I have created a sample application that only uses the BlueBird package. Debug the following program inside WebStorm (make sure you run npm install bluebird before).
Promise = require('bluebird');
var promise = new Promise(function(resolve, reject) {
console.log("Waiting 5 seconds...");
setTimeout(function(){
console.log("Resolving...");
resolve();
}, 5000);
});
promise.then(function(){
console.log("Resolved.");
});
This bogus program works fine. When I step into the promise.then part of the code I hit line 111 of promise.js (function Promise.prototype.then of the BlueBird package). When I set a breakpoint on that line and rerun the code, then it doesn't stop there. Breakpoints in my own code do work fine.

looks similar to WEB-18160, it's fixed in 11.0.2 that is coming soon

Related

Completely disable auto run of Jest test runner in Visual Studio Code editor

I have some sets of Jest test cases that run Puppeteer browser tests.
I have tried these test runners
Jest (vscode-jest)
Jest Test Explorer (Jest Test Explorer for Visual Studio Code)
Jest Runner (vscode-jest-runner)
To me, I like Jest Test Explorer the most but it always auto-start running test cases.
As you can imagine, a lot of Chrome browser instances get launched when I open a project with VS Code.
I found some configurations but they cannot prevent auto-run test cases.
"testExplorer.onStart": "reset", or set to null
"testExplorer.onReload": "reset", or set to null
FYI, an example UI of Jest Test Explorer
Jest (vscode-jest) is a good runner but I can't stop auto-run with these settings as well.
"jest.runAllTestsFirst": false,
"jest.autoEnable": false,
"jest.showCoverageOnLoad": false
Therefore, right now Jest Runner (vscode-jest-runner) is the only runner that does not auto-start unit tests.
In addition, if you have any other test runners to suggest, please let me know.
Thank you so much.
For orta.vscode-jest extension, I added the configuration below in settings.json. You can open settings.json by doing Command + Shift + P (Ctrl + Shift + P on Windows), typing settings JSON and selecting Preferences: Open Settings (JSON).
"jest.autoRun": {
"onStartup": []
}
Or you can simply add:
"jest.autoRun": {}
If you want to run all tests on startup, add all-tests to the onStartup array:
"jest.autoRun": {
"onStartup": ["all-tests"]
}
I just set this simple option into the VS Code's settings.json:
"jest.autoRun": "false"
I made it work by only setting the setting "jest.autoEnable": false, on my settings.json and restarting VSCode. At least, it is working until now and it hasn't broken yet: Disable starting Jest automatically
To open your settings.json:
Press Ctrl+Shift+P
Then type Preferences: Open Settings (JSON)
At the time of writing (Dec 22) the new way to do this (as per https://github.com/jest-community/vscode-jest/blob/master/README.md#how-to-trigger-the-test-run) is to have the following in the VS Code settings.json. Note I had previously tried the other answers but none worked.
"jest.autoRun": { "watch": false }
Go to vscode setting.json
You can either add
"jest.autoRun": "off"
or
"jest.autoRun": false
both are valid options.
You can checkout the official recommended settings here.
https://github.com/jest-community/vscode-jest/blob/master/README.md#how-to-trigger-the-test-run
"jest.autoEnable": false
is deprecated.
What it worked for me was:
File -> preferences -> settings. Then under the panel user (in workspace is as well but I am not sure if you need to modify it there as well), go to extensions -> jest.
There you will have a section jest: auto run and you will find a link "edit in settings.json" and modify what is there for this
"jest.autoRun": {
"watch": false
}
There's some great updated docs here
Migration rule from settings prior to v4:
if "jest.autoEnabled" = false => manual mode: "jest.autoRun": "off"
if "jest.runAllTestsFirst" = false => "jest.autoRun": {"watch": true }
if no customization of the 2 settings and no "jest.autoRun" found =>
First open the jest extension settings.json in the vs code. In the json script add "jest.autoRun": "off" to disable test autorun. Below, I add other options as well.
Source: Documentation
fully manual
there will be no automatic test run, users will trigger test run by either command or context-menu.
Example: "jest.autoRun": "off"
automatically run tests when test file changed
the extension will trigger test run for the given test file upon save.
Example: "jest.autoRun": {"watch": false, "onSave": "test-file"}
automatically run tests when either test or source file changed:
the extension will trigger test run for the given test or source file upon save.
Example: "jest.autoRun": {"watch": false, "onSave": "test-src-file"}

VS Code does not recognize unit tests in Flutter

Visual Studio Code does not recognize unit tests grouped in group(...). But it recognizes unit tests which are not grouped. I mean they are standalone test(...). I want to use group, because I need setUp().
There is Run | Debug link above group. When I click Debug or Run the Debug console shows No tests match regular expression "^LocalRepository$".
The tests are running correctly with flutter test command.
Dart SDK: >=2.1.0 <3.0.0
Flutter channel: master
Edit: I found workaround - I just don't use group callback. But I can't run all tests by clicking Run above group.
Make sure you name you test file ending with _test.dart and you will see the run | debug options
I have a Flutter project with two separate test files, both ending in "..._test.dart".
Using the following two test scenarios, one of the files passes, while the second doesn't load and that test fails.
Using launch.json configuration:
{
"name": "Dart: Run all Tests",
"request": "launch",
"type": "dart",
"program": "./test/"
}
Using the VS Code menu item Debug > Start Debugging (F5), which I suspicion just uses the above launch.json configuration, yields the same result.
However, using the VS Code menu item Debug > Start Without Debugging (Ctrl+F5), or "flutter test" from the command line, both tests pass.
I suspect this is an internal configuration issue with the VS Code Dart/Flutter extension, as opposed to a problem with Dart/Flutter code structure.
Are your tests/groups spread across multiple files? There are some limitations to the integration between the VS Code extension and the test package that you may be hitting.
There was a fix in v2.23 (released a few days before your question) that should have improved this a little (removing those Run/Debug links in some places they wont' work) but if you're already on that version then maybe it didn't cover your case.
If you can post a small repro on GitHub I'd definitely like to see if I can improve this. Thanks!
Ensure the test has a name different from ''
Change
test('', () {
...
});
to
test('xxx', () {
...
});

rubymotion Cannot find executable for CFBundle

I just installed RubyMotion on my iMac.
I created my first app - Hello
This is the code:
class AppDelegate
def application(application, didFinishLaunchingWithOptions:launchOptions)
#window = UIWindow.alloc.initWithFrame(UIScreen.mainScreen.bounds)
#window.rootViewController = HelloViewController.alloc.init
#window.rootViewController.wantsFullScreenLayout = true
#window.makeKeyAndVisible
true
end
end
I run $ Rake and the IOS Simulator start up. And I get this error:
2014-04-25 18:58:03.157 Hello[10488:70b] Cannot find executable for CFBundle 0x8d8a130 </Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.1.sdk/System/Library/AccessibilityBundles/CertUIFramework.axbundle> (not loaded)
I tried this from another question:
Temporary workaround: click iOS Simulator > Reset Content and Settings... and run again.
But, that didn't fix it.
Thanks for the help!
It's a relatively harmless (I believe) bug in the iOS 7 SDK.
https://devforums.apple.com/message/940094#940094
I had the same issue and found your post when searching for a solution. My application appeared to be running fine but I was still getting this message I was able to eliminate the message on my machine, here is what I had to do;
Stop all execution on the simulator.
Go to the simulator's home screen using shift-command-h.
Delete the app from the simulator device by holding a click on my program until the delete icon appeared, then click the X to delete.
In the iOS Simulator select Reset Content and Settings.
Clean the project in Xcode, shift-command-k.
Build it and run it.
Note, I was doing steps 4 & 5 but that wasn't working. It wasn't until I added step 3 (as crazy as it sounds) that it cleared my message.
Hope this works for you!
--Dave
Perhaps deleting the app, resetting, and restarting the iOS simulator would work.

Firebreath plugin on windows fails to load in chrome

I am busy converting by existing firebreath plugin here to use gpgme instead of making calls via the OS and the gpg binary.
I have managed to get the code to compile in windows using VS 2010 on a x32 system but after loading the plugin into chrome I can not access the npapi code at all. Even simple version calls fails.
When loading the plugin I get no visible errors but when using sawbuck log viewer for chrome I get the erorr messages below.
.\renderer\webplugin_delegate_proxy.cc 347 PluginMsg_Init returned false
..\plugins\npapi\webplugin_impl.cc 271 Couldn't initialize plug-in
I have tried to use my code with both firebreath 1.4 and 1.6 and neither versions work. After some simple debugging it seems that using any code provided by gpgme (whether its called or not) causes the plugin to break.
I came to this conclusion by doing the following.
Created a new project with firebreath (versions 1.4 and 1.6)
Add the gpgme.h headers to gmailGPGAPI.cpp and changed nothing else aside from adding the required reference paths to the project.
Build the project to create the dll (this generates the dll fine).
Replace the existing ddl in my project with the dll in step 2 and test it with the following piece of code
plugin = document.createElement('object'); plugin.id = 'plugin';
plugin.type = 'application/x-gmailtest';
document.body.appendChild(plugin);
console.log("my plugin returned: "+ plugin.valid);
console.log("my plugin returned: " + plugin.version);
This returns valid = true and the version returns what ever i set it to.
I then modified gmailGPGAPI.cpp to now return the gpg version by calling gpgme_check_version(NULL) in the version method. I used that method because its probably the simplest returning function that I could test with.
Build the plugin and copy dll to chrome extension as in step 3-4. The plugin builds fine again as expected.
Load the plugin and try to execute the code in step 4 at which point it now just returns undefined for any property or method i try to access on the plugin. No errors are printed to the console or anywhere else in chrome except for the error logged to sawbuck.
I have got no idea where to look or what to try since I cant seem to get an actionable error to work against. I have also reduced by test code to the point where its just a new project with a one line change to make it easier to find the problem.
I should note the code in the repo builds fine in linux/OSX and loads into chrome correctly so I know at some level my code does work.
Two possible paths:
You may have a DLL dependency that isn't available which keeps the plugin from loading; if you run regsvr32 on it in the state where it doesn't work on chrome, does it work?
Your plugin may be loading and then crashing. Start chrome with --plugin-startup-dialog and then when it pops up a dialog warning you that a plugin is about to be loaded attach to that process and see if the process crashes. At this point you can also set breakpoints to try to figure out how far it gets.
Double check your metadata in PluginConfig.cmake as well; sometimes unusual characters in some fields can cause issues like this.

how to replace the uninstallation part of an MSI

I've build a msi installer using a VS2010 setup project.
Now the project does not deinstall because of a "1001 Exception: Invalid format for argument machineName" (see below) inside a custom action.
I am unsucessful at uninstalling the application using the remove from the system control or msiexec /uninstall.
Is there a way to force uninstallation?
Details:
As part of a custom action I register a custom event source which my app uses for event loging into the windows log:
public override void Install(IDictionary stateSaver) {
base.Install(stateSaver);
EventLog.CreateEventSource("VeodinRecorder","Application");
}
inside of the "Uninstall" I try to remove this Eventsource with
if (!EventLog.SourceExists("VeodinRecorder"))
EventLog.Delete("VeodinRecorder"); `
The EventLog.Delete also takes machinename as second argument
So I tried to overwrite the msi used for uninstallation with msiexec /fv and changed the uninstall action:
EventLog.Delete("VeodinRecorder",".");
EventLog.Delete("VeodinRecorder","Application");
I even left the whole "uninstall action" blank.
But nothing seemed to work.
Any Hints?
The full log:
Error 1001. Error 1001. An exception occurred while uninstalling. This exception will be ignored and the uninstall will continue. However, the application might not be fully uninstalled after the uninstall is complete. --> Invalid format for argument machineName.
MSI (s) (60!68) [22:49:00:101]:
DEBUG: Error 2769: Custom Action _3C1D0358_8969_4B01_B8FA_B6B43F4E9E4C.uninstall did not close 1 MSIHANDLEs.
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: _3C1D0358_8969_4B01_B8FA_B6B43F4E9E4C.uninstall, 1,
CustomAction _3C1D0358_8969_4B01_B8FA_B6B43F4E9E4C.uninstall returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 22:49:00: InstallExecute. Return value 3.
Action ended 22:49:00: INSTALL. Return value 3.
It seems that the CustomAction.dll was not updated when I update the installation with msiexec /fv.
I now manually placed the newly build CustomAction.dll (with an empty uninstall override) into the installation folder and was able to uninstall.
Update: (Credits to #pcans) use ORCA to edit the currently installed msi and manually disable the uninstall custom action.
Just for reference I want to add that you can also patch the installed product with a minor upgrade to remove any faulty actions in the uninstall sequence before it gets called. This works because a minor upgrade is a reinstall of the same product, and not an uninstall and a reinstall of a new version (which is a major upgrade). You hence replace the uninstall sequence with a correct one before the erronous one gets run.
Creating the patch is quite complicated though, even with professional tools such as Wise or Installshield, but in certain cases this is the only fix that works to get the package properly uninstalled. A package "in the wild" in a company should be fixed this way.
Finally you can use msizap.exe from Microsoft to unregister a whole faulty package from the Windows Installer database, but this is not good since changes to the system are not rolled back at all and lots of junk is left everywhere. The tool itself also seems a bit shaky at times, sometimes creating new errors that are really difficult to fix. Preferably use it for debugging only.
One further note in this already long reply: a special case is when you run a custom action only during the uninstall sequence, and it then returns a faulty return code - sometimes even if it performed its operations ok. These actions can trigger a very annonying "uninstall only rollback situation". Effectively your uninstall is rolled back when it hits the custom action that was never run during install. This will rollback the uninstall and hence work as an installation - your product is left on the machine. Quite strange.
The bottom line: skip return codes for custom actions that are run during uninstall, use other verification mechanisms to ensure the action succeeded.