I use flask-restx 0.5.1 to define my API.
When describing payload parameter with
#ns.expect(mymodel, description="my model parameter description")
I get the following
When I additionally use
#ns.param('payload', description="This is my payload description but without auto-generated example", example={"key": "value"})
I can get the following
As it is very convenient and nice to see the generated example as in the first picture, I wonder how can I get both, my payload description AND the example?
Thx
I found the solution:
You have to use
#ns.param('payload', 'some description goes here', _in='body)
The missing piece was the _in="body"
Related
How do i do a call order verification of a fake with argument validation in sinon.js?
It is the same fake which is called multiple times with different arguments...
something like below
let someFake = sinon.fake();
someFake(1);
someFake(2);
someFake(3);
sinon.assert.callOrder(someFake.calledWith(1), someFake.calledWith(2),
someFake.calledWith(3));
You are essentially using the wrong API for the job, so it's no wonder you are not getting the expected results :) If you look at the docs for callOrder you will see that the signature is using spy1, spy2, .., which indicates that it is meant to be used by more than one spy. A fake is implementation wise also a Spy, so all bits of the Spy API also applies to a Fake. From the docs:
The created fake Function, with or without behavior has the same API as a sinon.spy
A sidenode, that is a bit confusing, is that the docs often use the term "fake" to apply to any fake object or function, not functions created using the sinon.fake API specifically, although, that should not be an issue in this particular case.
With regards to your original question, the Spy API has got you covered since Sinon 1.0 here. You use getCall(n) to return the nth call. There are lots of interactive examples in the docs for this, but essentially you just do this:
// dumbed down version of https://runkit.com/fatso83/stackoverflow-66192966
const fake = sinon.fake();
fake(1);
fake(20);
fake(300);
sinon.assert.calledThrice(fake);
assertEquals(1, fake.getCall(0).args[0])
assertEquals(20, fake.secondCall.args[0])
assertEquals(300, fake.lastCall.args[0])
function assertEquals(arg1,arg2){
if(arg1 !== arg2) {
throw new Error(`Expected ${arg1} to equal ${arg2}`);
}
console.log(`${arg1} equal ${arg2}: OK`)
}
<script src="https://cdn.jsdelivr.net/npm/sinon#latest/pkg/sinon.js"></script>
Let's say I have two methods
"""
f(x::Integer)
Integer version of `f`.
"""
f(x::Integer) = println("I'm an integer!")
"""
f(x::Float64)
Float64 version of `f`.
"""
f(x::Float64) = println("I'm floating!")
and produce doc entries for those methods in my documentation using Documenter.jl's #autodocs or #docs.
How can I refer (with #ref) to one of the methods?
I'm searching for something like [integer version](#ref f(::Integer)) (which unfortunately does not work) rather than just [function f](#ref f) or [f](#ref).
Note that for generating the doc entries #docs has a similar feature. From the guide page:
[...] include the type in the signature with
```#docs
length(::T)
```
Thanks in advance.
x-ref: https://discourse.julialang.org/t/documenter-jl-ref-a-specific-method-of-a-function/8792
x-ref: https://github.com/JuliaDocs/Documenter.jl/issues/569#issuecomment-362760811
As pointed out by #mortenpi on Discourse and github:
You would normally refer to a function with [`f`](#ref), with the name
of the function being referred to between backticks in text part of
the link. You can then also refer to specific signatures, e.g. with
[`f(::Integer)`](#ref).
The #ref section in the docs should be updated to mention this
possibility.
Can someone point me out how to properly search using imaplib in python. The email server is Microsoft Exchange - seems to have problems but I would want a solution from the python/imaplib side.
https://github.com/barbushin/php-imap/issues/128
I so far use:
import imaplib
M = imaplib.IMAP4_SSL(host_name, port_name)
M.login(u, p)
M.select()
s_str = 'hello'
M.search(s_str)
And I get the following error:
>>> M.search(s_str)
('NO', [b'[BADCHARSET (US-ASCII)] The specified charset is not supported.'])
search takes two or more parameters, an encoding, and the search specifications. You can pass None as the encoding, to not specify one. hello is not a valid charset.
You also need to specify what you are searching: IMAP has a complex search language detailed in RFC3501§6.4.4; and imaplib does not provide a high level interface for it.
So, with both of those in mind, you need to do something like:
search(None, 'BODY', '"HELLO"')
or
search(None, 'FROM', '"HELLO"')
So, I'm creating a script to extend the functionality of devtools::create() and I'm noticing some slightly odd behavior when I double check things with utils::maintainer. Here's a MWE where I set the Authors#R section of the description file through the devtools.desc.author option:
options(devtools.desc.license = "AGPL-3")
options(devtools.desc.author = "'Joe Dirt <joe#durt.ee> [aut, cre]'")
descArgs <- list(Package = "testPkg",
Title = "testPkg",
Description = "some desc.")
options(devtools.desc = descArgs)
devtools::create(path = "testPkg", check = TRUE)
Now, if you go ahead and run devtools::install("testPkg", quiet=TRUE), and then maintainer("testPkg") you get
> maintainer("testPkg")
[1] "'Joe Dirt' <joe#durt.ee>"
So my question is: why is the maintainer's name quoted, here?
This seems to be an issue with how the Maintainer field is auto generated from Authors#R. See:http://cran.r-project.org/doc/manuals/r-release/R-exts.html
Both ‘Author’ and ‘Maintainer’ fields can be omitted if a suitable ‘Authors#R’ field is given. This field can be used to provide a refined and machine-readable description of the package “authors” (in particular specifying their precise roles), via suitable R code. The roles can include ‘"aut"’ (author) for full authors, ‘"cre"’ (creator) for the package maintainer, and ‘"ctb"’ (contributor) for other contributors, ‘"cph"’ (copyright holder), among others. See ?person for more information. Note that no role is assumed by default. Auto-generated package citation information takes advantage of this specification. The ‘Author’ and ‘Maintainer’ fields are auto-generated from it if needed when building5 or installing.
Therefore, you should use the person function to specify the author list as follows:
options(devtools.desc.author ="c(person('Joe','Dirt',email='joe#durt.ee',role=c('aut','cre')))")
I want to know the difference(s) between pcl::PCLPointCloud2 and pcl::PointCloud in PointCloud Library (PCL). There is a function to convert from one to another, but the documentation is very poor.
I would like to know, which one is newer?
p.s. (I am not talking about ROS)
PCL has replaced the "sensor_msgs::PointCloud2" type to "pcl::PCLPointCloud2".
PointCLoud2 is a ROS message type.
=> So you had to use the PCLPointCloud2 type in PCL when you want to have interactions with ROS.
When you subscribe or publish, you don't need to convert them. #include "pcl_ros/point_cloud.h" will do that for you (called serialization). For more detail, take a look here: http://wiki.ros.org/pcl/Overview#Subscribing_to_different_point_cloud_message_types. Look for the paragraph starting at "If you have a pcl::PointCloud object, you don't have to convert it to a message:"