I'm diagnosing a custom Unit Tests (Coded UI) running library. The library is performing tests and preparing reports at the end, pdfs. My library's namespaces are not listed in a snapshot - only Framework ones. See attached image.
snapshot view
Looks like you environment starts several processes, you got a memory snapshot of vstest.executionengine.x86.exe process but your library is loaded into another one.
On the "Profiling" analysis step (where the name of the process is placed) you can choose the process to analyse. Select this step, combobox with the list of processes will appear. Also there is a notification mark on the status bar (bottom-right corner) which notifies you about new process starting and helps to switch to it.
Related
I've got an electron app with vite/xstate/react. In development I'm seeing just a single xstate.init event emitted when starting up the app. But in production builds, I see two xstate.init events (there should only be one, triggered by xstate itself upon initialising):
I'm logging the event out (renderer process, so it shows up in dev tools). It comes from the same file/chunk, but for some reason, dev tools show two different paths to the same file (file:///Users/... vs /Users/...). This is causing some bad bugs where things get ran twice in some cases. I'm trying to narrow down the issue here. Is this some sort of issue with electron and the build files?
I'm new to Appian, and have created an RPA process by importing a .side Selenium file. This has created a new section in the workflow.
I've tried running this but whenever I attempt to test it, or to trigger it from a process flow it remains queued forever.
Will the sections exectute automatically one after the other, or do I need to add some command to make the process move from one section to the next?
Debug in Appian RPA
Appian RPA includes a debugging tool to walk you through the workflow action-by-action and isolate where issues might arise. To use the tool, you'll select Debugging? when you manually execute the robotic process in the Appian RPA console.
Go to the Robotic processes tab.
Find the robotic process you want to debug in the list.
Click the Execute icon rpa-execute-icon.png in the Actions column. Alternatively, you can find the Execute icon at the top of the robotic process configuration page.
In the Execution options, check the Debugging? checkbox.
Click the Execute icon rpa-execute-icon.png once more to start the execution.
https://docs.appian.com/suite/help/21.4/rpa-7.12/create/troubleshoot.html
Per this doc, the analysis and execution phases handle building out the dependency tree (among other things) and going and doing the work if needed, respectively. If that's true, I'm curious why the total number of targets keeps increasing as the build progresses (i.e., when I start a large build, bazel may report that it's built 5 out of 100 targets, but later will say it's built 20 out of 300 targets, and so forth, with the denominator increasing for a while until it levels off).
I've heard the loading and analysis phases can be intermixed. My likely incomplete or incorrect understanding is that when bazel parses a BUILD file, analysis is invoked to determine what dependencies are needed for the requested targets on the command line, and then I guess this is somehow communicated back to the loader to pull in any other BUILD files referenced by these dependencies, which could cause the loader to go out and fetch a remote repo if the dependency (and thus BUILD file) is not in the local repo.
However, my understanding was also that while dynamic build-out of the dependency graph was a potential future direction for bazel, that currently, execution does not intermix with analysis, and thus when execution begins, the full dependency tree should be available to bazel (and thus the total number of targets known)? Does bazel have the full tree, but just not want to traverse the tree to get a count in case it's big, or is something else going on here?
Note: I found a brief mention of this phenomenon here, but without an explanation as to why it happens.
The number you're seeing in the progress bar refers to actions (command-lines..ish) and not targets (e.g. //my:target). I wrote a blog post about the action graph, and here's the relevant description about it:
The action graph contains a different set of information: file-level
dependencies, full command lines, and other information Bazel needs to
execute the build. If you are familiar with Bazel’s build phases, the
action graph is the output of the loading and analysis phase and used
during the execution phase.
However, Bazel does not necessarily execute every action in the graph.
It only executes if it has to, that is, the action graph is the super
set of what is actually executed.
As to why the denominator is ever-increasing, it's because the actions-to-execute discovery within the action graph is lazy. Here's a better explanation from the Bazel TL, Ulf Adams:
The problem is that Skyframe does not eagerly walk the action graph,
but it does it lazily. The reason for that is performance, since the
action graph can be rather large and this was previously a blocking
operation (where Bazel would just hang for some time). The downside is
that all threads that walk the action graph block on actions that they
execute, which delays discovery of remaining actions. That's why the
number keeps going up during the build.
Source: https://github.com/bazelbuild/bazel/issues/3582#issuecomment-329405311
All,
I have a Jenkins server setup which automatically runs Fortify and uploads it to SSC. Unfortunately, SSC seems to have stopped updating.
I can see the artifact in the artifacts table and I have to manually approve it, as always, due to a "missing external metadata" issue. However, when I go to "audit issues", the issue count isn't update. If I download the project file, the appropriate number of issues is shown in the desktop application.
Does anyone have ideas?
What version of SSC are you using?
Are you giving SSC enough time to update its metrics. There are certain actions that require SSC to recalculate metrics. Normally the recalculations are done at midnight. There is an indicator that an update needs to be done (and can be triggered manually).
In the HTML SSC interface (introduced in 4.40) you will see two yellow arrows in a circle (thing of a refresh icon). That is letting you know recalculations need to be done. This is also a button that can be pressed to kick it off now.
In the older flash UI, when looking at the details page of a project version, there can be a Refresh button, if this is visible it means a recalculation needs to be done, either at the scheduled time or can be triggered manually.
Side Note
To get around the "missing external metadata" issue, you need to update the rulepacks on the SSC Server. You can do this in the Rulepacks section of the Admin area.
Is is possible to have right-mouse-click entries only appear when my application is running? What I am thinking is that I want people to be able to right-click a file in windows explorer and be able to select an entry "Email this file to technical support", but I need my app to be running in order to do that, so I want the entry to disappear when my app isn't running.
I guess the second part of my question is how to implement that function - i.e. how can I get a right-click menu entry click from Windows Explorer recognised and acted on my my app if the app is already running, or will I have to have a minion app that just passes a message to the main app?
A shell context-menu extension can decide whether to create any menu items easily enough. Change your handling of the IContextMenu.QueryContextMenu method accordingly. (Delphi comes with a sample project for context-menu extensions. Start from there if you don't already have one.)
Another option is to keep the menu item visible all the time. If your application isn't running, then have the menu extension start your program first. Why should the user have to worry about what order to do things?