How do you pass options to stack haddock from stack.yaml? I cannot find any clue to correct syntax neither in documentation nor in stack source code.
Documentation describes the following:
build:
haddock-arguments: ""
Naive haddock-arguments: "--odir=./docs" fails with type error:
…failed to parse field 'haddock-arguments': expected HaddockOptsMonoid, encountered String
I figured out that it expects it to be like:
build:
haddock-arguments:
odir: "./docs"
However it fails with error Unrecognized field in HaddockOptsMonoid: odir.
What is correct syntax of passing arguments from haddock manual to stack via stack.yaml? In my specific case, I want specify custom output directory.
After looking at the source I figured out that the syntax is
build:
haddock-arguments:
haddock-args:
- "--odir=./docs"
In a sample project this has the following result (notice the location of the docs directory deep down in .stack-work):
$ ls .stack-work/install/x86_64-linux/lts-6.3/7.10.3/doc/docs/ | cat
doc-index.html
frames.html
haddock-util.js
hslogo-16.png
index-frames.html
index.html
minus.gif
ocean.css
plus.gif
synopsis.png
The links in index.html are broken, so I'm slightly pessimistic that you can achieve what you want by passing arguments to haddock in this way.
Related
I want to sort the search command result by its date (disclosure_date) so I can see the latest exploits. However for some reason sorting by the command line option "-s" with the date property doesn't work, while for example "rank" does.
While this outputs a normal result (around 1300 lines of modules)
msf6 > search platform:windows type:exploit -s rank
This outputs the following error.
msf6 > search platform:windows type:exploit -s disclosure_date
[-] Invalid argument(s)
Usage: search [<options>] [<keywords>:<value>]
Prepending a value with '-' will exclude any matching results.
If no options or keywords are provided, cached results are displayed.
Versions:
msf6 > version
Framework: 6.0.55-dev
Console : 6.0.55-dev
I thought it may be solved by upgrading the version, so I cloned the repo and manually built from the Dockerfile to a docker image, and tested on the latest version as follows, but it still keeps showing the issue.
> version
Framework: 6.1.37-dev
Console : 6.1.37-dev
What can I do? Thanks.
We use a linter (for Golang) that run through a Github Actions workflow every time we open or update a Pull Request on our repository.
It recently started to return the following error:
File is not `gofmt`-ed with `-s` (gofmt)
After what happened in this other PR to the file pkg/api/api/go.
(EDIT: link added to evaluate and eventually reproduce the error)
Evidences:
I would like to understand what was the source of this error, as well as how to resolve it?
Source of the error
It seems this error can be returned when the file is not properly formatted according to Go rules.
For example: If you accidentally used tab indentation rather than spaces.
EDIT: blackgreen's answer gives more accurate details about the source of the error
How to resolve it
You can use the following Go command:
gofmt -s -w <path_to_file>.go
... then commit the code.
Note that in my case: gofmt -w pkg/api/api.go was enough to resolve the problem (without the -s flag, which I found strange as the error specifically asked for the -s).
Source 1 + Source 2
The -s flag in gofmt has nothing to do with formatting. It's about simplifying the code:
Try to simplify code (after applying the rewrite rule, if any).
The warning you see comes from the linter golangci-lint. Since you claim to have fixed the error by running gofmt -w, the presence of the hint "with -s" may be due to this bug: https://github.com/golangci/golangci-lint/issues/513.
The linked issue was fixed in 2019 and released with v1.17.0. You might want to check if your pipeline is using an older version.
Assuming that your file pkg/api/api.go triggered the warning just because it was not formatted, gofmt -w solves the issue because -w overwrites the file:
If a file's formatting is different from gofmt's, overwrite it with gofmt's version.
My knowledge of Make is small. I have been told that everything you put after make (that does not contain "-") is a target.
Well a building process I have is failing.
First there is a line
make path/to/configuration_file
configuration_file is not a target. It is a autogenerated configuration file buried inside the directory structure ("path/to") that is of the form
#
# Boot Configuration
#
#
# DRAM Component
#
CONFIG_DRAM_TYPE_LPDDR4=y
# CONFIG_DRAM_TYPE_DDR4 is not set
CONFIG_DDR_SIZE=0x80000000
#
# Boot Device
#
# CONFIG_ENABLE_EMMC_BOOT is not set
# CONFIG_ENABLE_NAND_BOOT is not set
CONFIG_ENABLE_SPINAND_BOOT=y
# CONFIG_ENABLE_SPINOR_BOOT is not set
CONFIG_EMMC_ACCESS_8BIT=y
# CONFIG_EMMC_ACCESS_4BIT is not set
# CONFIG_EMMC_ACCESS_1BIT is not set
so I cannot understand how this is a target. For reference, when I run make there is a Makefile but this Makefile does not reference this file.
Still this line is going well.
The path where it fails says
make diags
and I have verified there is no "diags" target.
I will print here the error file that can give us more info of what is happening
GEN cortex_a/output/Makefile
Init diag test "orc_scheduler" ...
remoteconfig: Failed to generate configure in cortex_a/soc/visio/tests/orc_scheduler!
Makefile:11 recipe for target 'orc_scheduler-init' failed
make[10]: *** [orc_scheduler-init] Error 25
At least what I would like to know is how to interpret this error message. I don't know what the "11" or the "10" or the "25" refers to.
make is fundamentally a tool for automatically running commands in the right order so you don't have to type them in yourself. So all the commands make runs are commands that you could just type into your shell prompt. And all the errors that those commands generate are the same ones that you would see if you typed the command yourself. So, looking at make to try to understand those errors is looking in the wrong place: you have to look at the documentation for whatever command was invoked.
A "target" is just a file that make knows how to build. The fact that when you typed make <somefile> is didn't give you an error that it doesn't know how to build <somefile>, means that <somefile> is a target as far as your makefiles are concerned.
The error message Makefile:11: simply refers to the filename Makefile, line 11, which is where the command that make ran, that failed, can be found. But this likely won't help you solve the problem of why the command failed (unless the problem is you invoked it with the wrong arguments and you need to adjust the makefile to specify different arguments).
The command that failed generated the message:
remoteconfig: Failed to generate configure in cortex_a/soc/visio/tests/orc_scheduler!
I don't know what that means, but it's not related to make. You'll need to find out what this remoteconfig command is, what it does, and why it failed. It's unfortunate that it doesn't show any better error message as to why it failed to "generate configure", but again there's nothing make can do about that.
If you want to learn more about make you can look at the GNU make manual (note, GNU make is only one implementation of make; there are others and they are fundamentally the same but different in details).
Using ModelSim and VUnit I try to compile some UVVM, but this gives some warnings like:
** Warning: C:\work\Qtec\SVN_sim\Design\uvvm\uvvm_util\src\methods_pkg.vhd(1159): (vcom-1346) Default expression of interface object is not globally static.
So I would like to suppress these warnings, so I tried updating the VUnit "run.py" file with add_compile_option based on VUnit Python Interface:
uvvm_util = prj.add_library('uvvm_util')
uvvm_util.add_source_files(join(root, '../../uvvm/uvvm_util/src/*.vhd'))
uvvm_util.add_compile_option('modelsim.vcom_flags', ['-suppress 1346'])
But when compiling, I then get the error:
Compiling ....\uvvm\uvvm_util\src\types_pkg.vhd into uvvm_util ...
** Error (suppressible): (vcom-1902) Option "-suppress 1346" is either unknown, requires an argument, or was given with a bad argument.
You could edit the suppress entry in the modelsim.ini file. source
It could be a python/TCL error with spaces. See this link.
So the space between -suppress and 1346 is not properly forwarded.
The VUnit ui.py shows
modelsim.vcom_flags
Extra arguments passed to ModelSim vcom command.
Must be a list of strings.
I cannot test it, but this case the line should possibly be:
uvvm_util.add_compile_option('modelsim.vcom_flags', ['-suppress', '1346'])
edit: after some reading... To me the difference between add_compile_option and set_compile_option is not clear. Maybe you could try the other?
When running multiple features with the Ruby gem Parallel_Tests in cucumber using this command:
parallel_cucumber features/
with a cucumber.yml file under my project root>config folder, which looks like:
default: --format html --out report<%= ENV['TEST_ENV_NUMBER'] %>.html
I receive the following error message:
cucumber.yml was found, but could not be parsed. Please refer to cucumber's documentation on correct profile usage.
I have looked into this and some others have thought it was due to a rerun.txt file, but i have not created this file and a project file search returns nothing. I am currently at a loss of what is causing cucumber to fail reading in the yaml file. Any help would be great.
As described by another post, I went into lib/
cucumber/cli/profile_loader.rb and added a STDERR output like so:
begin
#cucumber_yml = YAML::load(#cucumber_erb)
rescue StandardError => e
STDERR.puts #cucumber_erb
raise(YmlLoadError,"cucumber.yml was found, but could not be parsed. Please refer to cucumber's documentation on correct profile usage.\n")
end
Here is the result:
#parallel_reports: --format html --out reports/cukes_.html
cucumber.yml was found, but could not be parsed. Please refer to cucumber's documentation on correct profile usage.
#
default: --format htm#l
-
oduetf aruelpto:r t-2-.fhotrmmla #hptamrla l-l-eolu_tr erpeoprotrst:4 .-h-tfmolr a#tp ahrtamlll e-l-_oruetp orretpso:r t-s-/fcourkmeast_ .hhttmmll - ouctu cruempboerrt.sy/mclu kweass_ .fhotumnld, buctu ccuomubledr .nyomtl bwea sp afrosuendd., Pblueta sceo urledf enro tt ob ec upcaurmsbeedr.' sP ldeoacsuem ernetfaetri otno ocnu ccuomrbreerc'ts pdroocfuimleen tu astaigoen.
n correct profile usage.
I stumbled upon this problem and only found solutions that suggested removing rerun.txt. That was not an option for me because I rely on that file to rerun failing scenarios.
For some reason Cucumber outputs failing scenarios separated by \n in rerun.txt which is not accepted by the default command found in cucumber.yml.
My solution was to change the first line of cucumber.yml to substitute \n with a space:
rerun = File.file?('rerun.txt') ? IO.read('rerun.txt').gsub(/\n/, ' ') : ""
I had the same issue with the tests of Rails-Cucumber itself. In my case, just running this line fixed the problem:
rm .cucumber.rerun
Caution, sometimes the rerun file can have a different name.
There is a suggestion to use gem update –system
For me, the error
cucumber.yml was found, but could not be parsed with ERB
meant that I was running my tests from RubyMine, and had set my Features folder not to the root of my project, but to a subfolder in the project called features.
When I changed this to the root of my project, it worked out fine!