Is there a way to invoke bazel help such that it outputs a machine readable format. I would like to parse all the flags that are available in Bazel and make them automatically available in ibazel so that I don't have to manually sync them every time a new bazel release comes out with different flags.
There used to be a --helpxml argument that printed things out as XML, but it seems the command line argument parser has changed and you can no longer use that. I presume there is still some way to get this, since the docs are being generated with up to date command line info. Unfortunately the "edit this page" button on the docs site 404s and I can't figure out its origin.
The docs for the flags are generated via this genrule, which essentially runs bazel help everything-as-html, the source of which is here.
There are a few other options listed in that case statement, one of which being flags-as-proto which emits the flags as a base64 encoded version of the BazelFlagsProto.
Potentially ibazel could read this in, load in the proto and pull out the data from there.
Related
i have an app that can show many popups in various scenarios, and i would like to verify their text using XCUITest. but would like to be able to do that with no effort for multiple text configurations. for multiple languages for instance.
Is there a way to pass arguments through the .xctestrun file or through the "xcodebuild test-without-building" command? some way to pass the dictionary, or a file that i can parse at the beginning of the XCTestCase to know the correct text values to predict? preferably without the need to rebuild the project.
Found the answer.
The test host (and your XCTestCases) can view its arguments same as the test target, using NSProcessInfo.processInfo.environment and NSProcessInfo.processInfo.arguments.
Using the scheme for "Test" in XCode, you can add arguments and environment variables that the test host itself can read. The test host can read these by using the process info as mentioned above.
Another way to do this would be by editing the xctestrun file for your test. In it, you can add the key CommandLineArguments as an array of strings for the process info arguments, or add EnvironmentVariables as a dictionary from key to string value.
An easy way to go about adding the arguments/variables to the xctestrun file manually would be to first add them to the Test scheme in XCode, see the changes to the xctestrun file, and modify them accordingly.
other xctestrun variables are described in https://www.manpagez.com/man/5/xcodebuild.xctestrun/
I am a new ClojureScript user and I'm writing an application using Re-frame. When I get an error message (from ClojureScript), in most cases, I get a call stack ending in JavaScript code from a library. That is expected, but I don't get a function from my own code in the stack! Sometimes, I don't get any ClojureScript function calls at all, just JavaScript's. Is there a way to see the top of the stack in these error messages? Or to see the last function from my code/namespace in the stack?
That could be a huge help to me. Even small mistakes (such as, swapping operator's positions in a map call) are very hard to track. I should be doing something wrong.
It is said that ClojureScript error messages are an acquired taste. Because of the way the compiler works error messages can be cryptic.
What can help make ClojureScript error messages more readable is installing cljs-devtools or the fork Dirac. This has among other things:
The :hints feature.
The :hints feature is an attempt to augment uncaught exceptions and error object to include a bit of additional knowledge related to such errors. It tries to fetch the original source file, extract relevant part to show you more context and mark the javascript error there. This is expected to work only with :optimizations none compiler mode and it is disabled by default because it relies on monkey patching.
Better display of ClojureScript function names.
Example of nicer stack trace (from Dirac, but cljs-webtools already improves it a lot)
Installation
Enable custom formatters
Open DevTools with CMD-ALT-J
Go to Settings with F1 or by pressing the three dots
Check "Enable custom formatters" under Console
cljs-webtools
(See Installation):
Add configuration to the compiler in project.clj
{:builds
[{:id "dev"
:source-paths ["src/cljs"]
:figwheel {:on-jsload "blabla.core/reload"}
:compiler {(...)
:preloads [devtools.preload]
:external-config {:devtools/config {:features-to-install :all}}}}
Dirac
Install the Dirac Chrome extension.
Run Chrome with remote debugging enabled.
/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary \
--remote-debugging-port=9222 \
--no-first-run \
--user-data-dir=$A_PATH_TO_YOUR_USER_PROFILE_DIRECTORY
Add binaryage/dirac to dependencies in your project.clj
:dependencies [[binaryage/dirac "RELEASE"]]
(or use another one of the installation instructions).
If you use the re-frame Leiningen template the cljs-devtools are included by default
I am busy with configuring our new TFS 2015 server (on premises) and trying to get the new vnext builds to work properly.
What I now have are some extra powershell scripts that increase the version number of my assemblies.
It also changes the buildnumber in TFS by calling the API method (see tfs rest api). My json body only sends the new build number (eg. {"buildNumber": "1.0.1.1234"}) and this works fine.
Now I have added some major, minor and patch version variables in the build definition for the version. Once the build is done this should be updated and so I thought to do the same kind of thing and just send an update API call to the corresponding builddefinition endpoint. The documentation says the revision number is mandatory so I have added that. For the rest I only added the changed variables.
The api call works, but the nasty thing is that it will update the whole definition and clear out all the other settings which I did not provide in the json body. I also tried first getting the defintion through the API, changing the json values for the variables and send that back but that didnt work correct also.
So does anybody know a good solution for this?
As a workaround what I did for now is adding a dummy build definition (eg. "_ProjectVersion") totally empty except for the variables and my build task now uses that build definition to get the latest version numbers and update them. So the api call still empties that whole build definition but since it only contains my variables I dont mind.
I am also doing this in powershell since all scripting should be automated and done in powershell.
The problem I have is that the API call to get the json of an existing BuildDefinition returns invalid json when managed in powershell.
For example the "#{multipliers=[]; will fail with 'must have at least one value' even though a 'json validator' may report as Valid. The correct json is {"multipliers": "[]",
I am attempting to use CMake to convert a generic wrapper into a specific one, via token replacement. I hope that all the user would have to do is input a specific set of strings, have CMake do configure_file, and the wrapper would read in the values and work as intended.
I am aware of the possibility to use set to set the token that needs to be replaced:
set(FAV_FOOD "Sushi" CACHE STRING "What is your favorite food?")
As well as the option to have the user select from a set of answers like so:
set(MY_SELECTION "Option A" CACHE STRING "Help message for this variable")
set_property(
CACHE MY_SELECTION
PROPERTY STRINGS
"Option A" "Option B" "Option C"
)
The problem with this is that I can't enumerate all valid answers. Is there any way for CMake to have a GUI pop up and allow the user to answer with any string? I could just have the user fill out these values in a file before calling make, but I'd like to avoid the users doing anything by hand in the files, and I want to take advance of the CMake cache and avoid assuming that the user has already filled out the variables in a file.
Any advice would be most helpful. Thanks.
Your first example is the standard way to provide user-specified options to CMake, typically including some suitable default value just as you have demonstrated.
You could omit the default value (pass the empty string) and then check to see if the value has been specified so an error will be generated when the user tries to configure.
In order to provide these values automatically the user can specific them on the command line using -D= syntax:
cmake -DSOME_VAR=some_val <path_to_CMakeLists.txt>
I typically use cmake/ccmake, and I assume you are using windows cmake-gui, which is very similar to ccmake. I know of no method to pop up some additional windows using cmake-gui. However, it does appear possible to invoke cmake-gui with the aforementioned options, as described here. Using this method you could provide a .bat file the user could edit in order to enter the settings that you wish them to specify.
In my opinion, as long as you're already having them run the cmake-gui, then simply utilizing your first proposed solution and letting them change the values in the gui "the old fashioned way" is really the most appropriate option.
This doesn't seem like a situation that is unique to me, but I haven't been able to find an answer anywhere.
I am attempting to build Jmeter scripts that can be executed both in the GUI and command line. The command line is going to need values to pass into the test cases, but the same test cases need to be executed via the GUI as well. I initially had separate scripts for GUI and command line, but it seemed redundant to have the same test cases duplicated with just a couple parameters changed.
For example, the GUI test case has the Web Server name set to:
<!-- ${ENV} set in User Defined Variables -->
<stringProp name="HTTPSampler.domain">${ENV}</stringProp>
The command line test case uses the following for parameters:
<!-- Define via command line w/ -JCMDDEV -->
<stringProp name="HTTPSampler.domain">${__P(CMDENV)}</stringProp>
Both work for their served purpose, but I want to combine the tests to be easier maintained and to have the ability to run them via GUI or command line.
I got passed one hurdle, which was combining the GUI Variables to be used as well as Properties for the command line by setting the User Defined Variable ${ENV} as the following:
Name Value
----- --------
ENV ${__P(ENV,dev.address.com)}
I am now able to run the same test case via GUI and command line (defining a new environment with -JENV)
I'm not sure if I'm overthinking this, but I want to be able to add a variable to the property default in order to avoid typos, etc while handing it off to others. I tried a few variations that didn't seem to work:
Name Value
----- --------
ENV ${__P(ENV,${__V(DEV)})}
DEV dev.address.com
This gave me the following Request:
POST http://DEV/servlet
Instead of:
POST http://dev.address.com/servlet
I also tried using:
${__P(ENV,${DEV})}
${__property(ENV,,${__V(DEV)})}
${__property(ENV,,${DEV})}
I was looking into Jmeter nested variables, but it didn't provide any working solutions.
So to my main question, am I able to use variables as the property defaults. If so, how would I achieve that?
I found a way around this. It's not exactly how I wanted it, but it could work for right now.
I really wanted to keep everything in one place where people had to make edits, but I was able to get the User Defined Variables to work by adding the ${__P(ENV,${DEV})} to the HTTP Request Defaults Web Server Name instead of pre-defining it as a variable.
Now there are two Config Elements that potentially need to be edited with GUI execution, but I think it should work out better in the long run.
Yes, seems the author is right - looks like nested variable can't be evaluated in JMeter from the same variables scope.
I've created a different "User Defined Variables" set, added there "defaultValue" - and after that this option works:
${__P(myProperty, ${defaultValue})}