I am using the vscode-mock-debug git as the basis for my work.
Activation event is OnDebug, although same result
I implement provideDebugConfigurations in my DebugConfigurationProvider and its not getting called.
provideDebugConfigurations(folder: WorkspaceFolder | undefined, token?: CancellationToken): DebugConfiguration[] {
return [...my data in here];
}
the resolveDebugConfiguration (the original from mock-debug) is called, I can set a breakpoint. However the provideDebugConfigurations is never getting reached. build 1.36 of vsce. am I missing something obvious ?
this is the answer from the vscode team: https://github.com/microsoft/vscode/issues/78362
I have investigated this and it is expected behavior.
Namely, provideDebugConfigurations is only called then the debug configurations are needed to generate a launch.jsonfile. If you click on the configure command the provideDebugConfigurations will get nicely called.
However if you do not have a launch.json and you simply press Debug Start, vscode will try to start debugging without using debug configurations, but using one on the fly provided by the resolveDebugConfiguration call.
More about this can be found in our docs https://code.visualstudio.com/api/extension-guides/debugger-extension
Thus closing this as designed.
Related
I am writing a Go adapter extension for the Test Explorer extension for Visual Studio Code. My extension uses language services from Microsoft's Go extension:
const symbols = await vscode.commands.executeCommand('vscode.executeDocumentSymbolProvider', uri)
However, I have an issue. When I specify extensionDependencies and activationEvents correctly (in package.json), symbols don't initially load (the command returns undefined). If I set activationEvents to * or if I delay for long enough in my activate handler, symbols load. I thought about retrying until the command returns something, but "this file has no symbols" and "there is no symbol provider for this type of document" both return undefined.
Is there a way to delay until a symbol provider has been defined for a specific file extension/language? Waiting for the Go extension to be activated is not enough. I would use GoDocumentSymbolProvider directly, but the extension doesn't export anything.
It looks like it will be possible to add a delay time before your extension is activated. See https://github.com/microsoft/vscode/issues/98083 (Add support to eventually activate an extension on startup). And https://github.com/microsoft/vscode/issues/98990 (Delayed startup activation events).
Will be in v1.46. From v1.46 release notes onStartupFinished activation event:
We now have a new activation event, similar to the already existing *
activation event. The new onStartupFinished activation event should
be used when an extension wishes to be activated sometime soon after
VS Code startup, but not as part of the startup.
However, it is just a hard-coded delay, not based on other events but may still help your situation.
There is a new activation event which looks like e.g. onStartup:1000
or onStartup:5000. This means that the extension wants to be
activated 1000ms or 5000ms after startup. This is very similar to *
activation, but the extension indicates that it can wait a bit.
I'm unable to understand how the mock-debugger extension controls where the next step is.
For example what if I'd like to step 2 lines if I find the word "banana" in my text? Also, I'd like to do something, like "Step In", where I can walk word-by-word - is it possible?
I've seen the this._currentLine = ln; assign, which looks like it controls where the line is, but it's just a simple local variable. How could it ever control anything in the debugger? I can't find any other uses of the _currentLine varbiable where it passes to anything useful API (except for stack tracing, but I don't think it has any relation with the debugger line-control).
The stack trace is the only source for the debugger step visualization. When the debugger gets a notification to pause it requests the current stack trace. The TOS determines where the next execution point will be located. Hence the debug adapter is reponsible to determine this position precisely.
I'm some tests to trigger and validate a JS alert like this:
it 'triggers a modal' do
accept_alert('Hello world') do
visit '/'
click_button 'Button'
end
end
Which is failing on:
Capybara::ModalNotFound:
Unable to find modal dialog with Hello world
When running headlessly, I thought that the dialog wasn't triggered at all and it was an issue with my JS code but I noticed the test log listed:
* Listening on tcp://127.0.0.1:3001
Modal window has been opened, but you didn't wrap your code into (`accept_prompt` | `dismiss_prompt` | `accept_confirm` | `dismiss_confirm` | `accept_alert`), accepting by default
F
Running in full Chrome I noticed that the modal is being triggered and with the expected message. So now I'm not sure:
why my accept_alert isn't failing the test if the message is actually wrong (e.g. there are hidden characters included and the message is actually Hello world\t. or something)
how is an unwrapped modal since my accept block wraps the whole test body?
I might have a silly syntax error, but I think the above is right & is working on another test. To try and get to the bottom of it, I wanted to disable Capybara's "accepting by default".
Is there any way to:
Make any unexpected modal fail the test (instead of accept/dismiss)?
Log out the text of modals as they occur?
The accepting by default isn't being done by Capybara it's being done be the driver you're using (Cuprite I'm assuming based on the message being produced). If you wrap the action that causes the modal to appear (based on behavior exhibited I'm assuming the visit) rather than the whole test then it will raise an error if the error message isn't correct
since the accept_alert method is only expecting the modal once the block has finished expecting
accept_alert('Hello world') do
visit '/'
end
click_button 'Button'
The behavior of auto-accepting (with warning) unexpected alerts is due to its original design being based on the Poltergeist and I don't believe is configurable currently.
I am toying with the FluidEnter/FluidExit. So in a simple form, here is what I am trying to do:
I created in Main an empty population of agent called Terminal. For now, in Terminal, there is only a fluidEnter connected to a fluidExit (very simple)
enter image description here
Now, on startup, I want to fill this population and set up the proper connections (the terminals are ordered).
So, on startup, I call a function init(), whose body start with Terminal t = add_terminals(); (I have only one terminal for now, just toying with things)
In Main, obviously, I also have a fluidEnter and a fluidExit. I would like to connect the fluidExit of Main to the fluidEnter of the terminal t, and the fluidExit of the terminal t to the fluidEnter of Main, so code (still in init()) looks like
fluidExit.set_fluidEnter(t.fluidEnter);
t.fluidExit.set_fluidEnter(fluidEnter);
I get an exception so obviously, I am doing something wrong. Any idea?
I think the set_fluidEnter function is deprecated or just non-functional.
Instead, you should do:
fluidExit.connect(t.fluidEnter);
So just replace set_fluidEnter with connect... nothing else.
That should do the trick
I was going down the same path as you a couple of months ago. Yes... .connect() works great. It even works as a gate. If it is disconnected, then fluid stops at the exit. Once connected, fluid starts to flow again. It is very slick.
I am trying to use Invoke process to invoke an executable from my windows workflow in my TFS 2010 build.
But when I am looking at the log file it is not logging any error.
I did use WriteBuildMessage and WriteBuildwarning inside my invoke process activity.
I also set the filename,workingdirectory etc in activity.
Can someone please point out why it is not logging?
You can do something like this:
In this case you have to ensure that Message are set as follows:
With those parameters set as depicted, I catch what you seem to be after.
Furthermore, you can check in the Properties of your InvokeProcess: Set the Result into a string-variable and then set in a subsequent WriteBuildMessage this string-variable to be the Message. This way, you 'll additionally catch the return of your invoked process.
EDIT
Another common thing that you 've possibly overlooked is the BuildMessageImportance: if it is not set as High, messages do NOT appear under default Logging Verbosity (= Normal). See here for some background.
In your Invoke Process, you want to set the Result property to update a variable (returns an Int, so lets call it ExitCode), under your Invoke Process (but still in the Agent Scope) you can drop in an If, so you can set the condition of this to ExitCode <> 0 and do whatever you like on a failure (such as failing the build).
Also, as a note, if your WriteBuildMessage is not showing anything in your log, you need to set the Importance to Microsoft.TeamFoundation.Build.Client.BuildMessageImportance.High, anything lower and it wont show in the Normal logging level.