I am giving D a shot with the VS code extension code-d. Everything works fine, except that I can't switch configuration, arch type or build type. If I try to do any of these things, I receive the following output message in code-d & serve-d:
{"code":-32602,"data":null,"message":"`params` MUST be an object (named arguments) or array (positional arguments), other types are not allowed by spec"}
At this point, I only have a hello world project, as described in the code-d documentation. Am I missing something?
There is a workaround for this. You can use user tasks in vs code. Create user tasks in vs code for each of your build configuration. Then install this extension (https://github.com/actboy168/vscode-tasks). This will pick each of your task and display it in the task bar of vs code. So you only need a mouse click.
Related
When trying to inspect variables for a Flutter project in VSCode, it is often the case the inspector shows nothing of use. For instance, below we have a variable x of some type. There are no runtime errors but when setting a breakpoint, the inspector simply shows the following for the value of x.
<function errorString(error) {>
The meaning of this is elusory since there is no related output in the debugging console. The breakpoints are being set within calls to Futures returning functions but it's hit and miss as to why most, but not all, variables cannot be inspected.
What do these error strings mean?
How can the root cause be determined (think stack traces in VS Pro)?
Why do they only show in break points but don't seem to affect runtime output?
How can the actual resolved state of the variable be inspected?
This was a bug in the Dart VS Code extension that has now been resolved:
https://github.com/Dart-Code/Dart-Code/issues/3840
Now the proper error message should be shown instead of the implementation of a function.
Does anyone know if it's possible to write an extension in Visual Studio code that can write the values in the variables window to a file after each step while in debug mode. So, a step would happen, the variable would get written to a file, another step would happen, and the next set of variables would be written. Is there anything like this out there? Can it even be done?
Here's what I have so far:
1) I created an extension in VS code, and will write my functionality in the following provided method:
function activate(context) {
let disposable = vscode.commands.registerCommand('extension.helloWorld', function () {
// Display a message box to the user
vscode.window.showInformationMessage('Hello World!');
});
2) There are some variables offered here that could be relevant (such as debugger), but they throw errors when I use them.
To explain more clearly, what I would like to do is the following: create an extension in VS code that when used launches another instance of VS code (as does every extension), and within this new instance, load a user program, debug the program step by step, and write the variables at each step of the user program to a file. This main reason for even making the extension is the last step, as VS Code doesn't have any built in functionality to do anything like this that I know of. One issue is I am not sure the 'debugger' variable in the extension (or any variables) refer to the new instance, and if there is a way to do this.
If there is a better and smarter approach, I would love to hear it.
Thank you very much everyone in advance
I'm working with visual studio code tasks and can define arguments in a task successfully upfront as follows:
{"version":"0.1.0","command":"example","isShellCommand":true,"tasks":
[{"taskName":"example task","suppressTaskName":true,"args":["examplearg"]}]}
I would like to be able to type in the argument when running the task, as the argument needs to be user defined, is that possible? For example I would like to be able to Run Task from command pallete: example task --myCustomArg.
Not possible. Open an issue in their repo and see what they say.
There is, however, a way to pass the current file. See here.
Your last choice would be to create an extension. You should give it a try as well. 😊
I've seen several conflicting descriptions of how to do this around the google results, and haven't been able to get any of them to work.
My problem is basically this: where I call ExecutionEngine::getPointerToFunction (with an llvm::Function*), I'd like to instead get the pretty-printed x86 assembly that would be produced for this function.
Anybody?
[ETA: I'm using LLVM 3.3. The descriptions I've found seem to be for earlier versions of LLVM.]
It turns out that you can add an event listener to a JIT ExecutionEngine with ExecutionEngine::RegisterJITEventListener. If you provide an instance of that class, you can have your callback invoked when machine code is generated for you, and you'll be given a pointer to the machine code and its length. With this, you can call llvm::sys::disassembleBuffer to get a description of the machine code buffer.
However, the llvm::sys::disassembleBuffer function just defers to the udis library if LLVM was compiled with that support. Since my build of LLVM didn't have this flag set and I can't rebuild it, I'll just look into using the udis library directly:
https://github.com/vmt/udis86
I have a list of several thousand NUnit tests that I want to run (generated automatically by another tool). (This is a subset of all of the tests, and changes frequently)
I'd like to be able to run these via NUnit-Console.exe. Unfortunately the /run option only takes a direct list of files which in my case would not fit on a single command line. I'd like it to pickup the list from a filename.
I appreciate that I could use categories, but the list I want to run changes frequently and so I'd prefer not to have to start changing source code.
Does anyone know if there is a clean way to get NUnit to run my specified tests?
(I could break it down into a series of smaller calls to NUnit-console with a full command line, but that's not very elegant)
(If it's not possible, maybe I should add it as an NUnit feature request.)
Had a reply from Charlie Poole (from NUnit development team), that this is not currently possible but has been added as a feature request for NUnit 2.6
I see what you're saying, but like you say you can run a single fixture from the command line.
nunit-console /fixture:namespace.fixture tests.dll
How about generating all the tests in the same fixture? Or place them all in the same assembly?
nunit-console tests.dll
As mentioned in the nunitLink, we need to mention the scenario/test case name. It simple but it has bit of a trick in it. Directly mentioning the test case name will not serve the purpose and you will end up with the 0 testcases executed. We need to write the exact path for the same.
I don't know how it works for other languages but using c# I have found a solution. Whenever we create a feature file corresponding feature.cs file get's created in Visual Studio. Click on the featureFileName.feature.cs and look for namespace and keep it aside(Part 1)
namespace MMBank.Test.Features
Scroll a bit down you will get the class name. Note that as well and keep it aside(Part 2)
public partial class HistoricalTransactionFeature
Keep scrolling down, you will see the code which nunit understands for execution basically.
[NUnit.Framework.TestAttribute()]
[NUnit.Framework.DescriptionAttribute("TC_1_A B C D")]
[NUnit.Framework.CategoryAttribute("MM_Bank")]
Below the code you can see the function/method name which will most likely be TC_1_ABCD(certain parameters)
public virtual void TC_1_ABCD(string username, string password, string visit)
You will be having multiple such methods based on no. of scenarios you have in your feature file. Note the method(test case) which you want to execute and keep it aside(Part 3)
Now collate all the parts with dots. Finally you will land up with something like this,
MMBank.Test.Features.HistoricalTransactionFeature.TC_1_ABCD
This is it. Similarly you can create the test case names from multiple feature files and stack them up in text file. Every test case name should be in different line. For command you can browse through above nunit link for execution using command prompt.