My coverage report runs fine, but I would like to configure the watermarks that is used to mark coverage green, yellow and red.
My coverage report currently look like this:
It seems RED is used when coverage is < 50 and GREEN is used when coverage is > 80 and else YELLOW is used.
Where can I configure these values, so I can use e.g. 40 and 60 instead?
My own research on this ended here: https://jestjs.io/docs/configuration#coveragereporters-arraystring--string-options
and here: https://github.com/istanbuljs/nyc/blob/master/README.md#installation--usage
It seems that something like this should be used:
{
"watermarks": {
"lines": [40, 70],
"functions": [40, 70],
"branches": [40, 70],
"statements": [40, 70]
}
}
But where should I put it? I have tried to put in a file called .nycrc and in package.json. It did not work.
I use Jest for testing ("jest --coverage") - in VSCode and I use NPM/NESTJS.
Related
I'm making a program that makes the cars running in the simulation pass on their colors to other cars, to achieve that I'm using the TraCi function 'getColor'. The problem is that every car that I ask the color returns (255,255,0,255) doesn't matter what the actual color is. However, using 'getColor' inside a condition for the "contamination" makes the program work, maybe out of sheer luck. Please help me understand how to fix it and how it works.
I'm on Ubuntu 18.04.3 LTS, SUMO 0.32.0 and using the traci library. I've tried modifying the program and running the simulation step by step, even running the same line in different code with the same idea in mind.
This is the program in which the "contamination" works although it gets the wrong colors:
def run():
step = 0
while traci.simulation.getMinExpectedNumber() > 0:
traci.simulationStep()
step += 1
if step > 2:
if distancia("veh1","veh0") < 5:
traci.vehicle.setColor("veh1",(255,0,0,255))
if distancia("veh0","veh2") < 5 :
traci.vehicle.setColor("veh2",(255,0,0,255))
if traci.vehicle.getColor("veh2") == (255,0,0,255):
if distancia("veh1","veh2") < 5 :
traci.vehicle.setColor("veh1",(255,0,0,255))
print(traci.vehicle.getColor("veh1"))
traci.close()
sys.stdout.flush()
I hoped when I selected the red car I would get (255,0,0,255), but I got (255,255,0,0). But it doesn't get any error messages, just shows the worng color.
It seems that the default color for traci is yellow, I'd to set every car to its own color from the python code to start doing what I wanted.
We noticed we got the error from SoftLayer API when trying to get categories from
product package 200 ( hourly bare metal server) preset Id=64 starting 10/18.
The following API query
https://<apiuser>:<apikey>#api.softlayer.com/rest/v3/SoftLayer_Product_Package/200/getActivePresets.json?objectMask=mask
[id,packageId,description,name,keyName,isActive,categories.id,categories.name, categories.categoryCode]
now returns presetId as 103, 97, 93,95,99,101,105,151,147,149, 143, 157
It used to return the following additional active presetIds:
64,66,68,70,74,76 , 78 before 10/17/2016.
I don't find these changes from SoftLayer release note
https://softlayer.github.io/release_notes/
Why are the previous active preset Ids 64,66,68,70,74,76 , 78 no longer available? Will they be added back ?
Thanks.
You are right, these presets are not longer available since 10/17/2016, because the DCs are no longer building the configurations and have moved to the Haswell and Broadwell configurations.
For Haswell:
Presets: 93, 95, 97, 99, 101, 103, 105
For Broadwell:
Presets: 147, 149, 151, 153, 157.
There appears to be a shutter speed bug with the Sony A7S and the Smart Remote Control app (version 4.10).
"0.6" seconds is listed by -getSupportedShutterSpeed, but when that speed is POST'ed with -setShutterSpeed, an HTTP error code of 500 is returned (without the speed being set).
Other shutter speeds appear to work.
I agree with you statement. Sony person must fix mulfunction.
I experience same phenomena in A7R2. I'm really annoyed by this "bug". My current environment is firmware v3.0, Remote Control App v4.10. This phenomena has kept from firmware v2.0 and Remote contorol App V4.0, as far as I tried.
I make one-line command in Linux to prove mulfunction. Results are below.
$ one_liners/setShutterSpeed.py 0.8 {"method": "setShutterSpeed",
"params": ["0.8"], "id": 1, "version": "1.0"} {"result":[0],"id":1}
$ one_liners/setShutterSpeed.py 0.6 {"method": "setShutterSpeed",
"params": ["0.6"], "id": 1, "version": "1.0"} API camera failed.
{"method": "setShutterSpeed", "params": ["0.6"], "id": 1, "version":
"1.0"}
$ one_liners/setShutterSpeed.py 0.5 {"method": "setShutterSpeed",
"params": ["0.5"], "id": 1, "version": "1.0"} {"result":[0],"id":1}
I just figured out what is happening.
For a shutter speed of 0.6 seconds, one must send the quoted string "0.6\"".
For other speeds like 0.5 seconds and 0.8 seconds, strings of either the form "0.8" or the quoted form with seconds unit, "0.8\"" both works.
Hello everyone.
Sorry for my noob question as I'm just a non-programmer trying to learn to program with Lua.
I'm so attracted with Lua since it's indeed very simple, either in size as well as in syntax.
And I decided to explore further experiment with this Brazilian born language, like playing with sound -- as I did in Python and Ruby.
So I found this ProteaAudio and tried to play the sample scripts came within package I downloaded from here.
The package comes with two sample scripts:
first named example.lua to play the ogg sample file (also comes within the package)
and another to play function generated sound named scale.lua
The first script runs just fine on my Win 7 and Ubuntu 12.04 x86 machine.
But the second script only runs on Windows and got an error when I tried to run it on Ubuntu, generating this message:
../lua52: scale.lua:13: bad argument #1 to 'soundLoop' (number expected, got nil)
stack traceback:
[C]: in function 'soundLoop'
scale.lua:13: in function 'playNote'
scale.lua:29: in main chunk
[C]: in ?
The full original source-code from scale.lua is:
-- function creating a sine wave sample:
function sampleSine(freq, duration, sampleRate)
local data = { }
for i = 1,duration*sampleRate do
data[i] = math.sin( (i*freq/sampleRate)*math.pi*2)
end
return proAudio.sampleFromMemory(data, sampleRate)
end
-- plays a sample shifted by a number of halftones for a definable period of time
function playNote(sample, pitch, duration, volumeL, volumeR, disparity)
local scale = 2^(pitch/12)
local sound = proAudio.soundLoop(sample, volumeL, volumeR, disparity, scale)
proAudio.sleep(duration)
proAudio.soundStop(sound)
end
-- create an audio device using default parameters and exit in case of errors
require("proAudioRt")
if not proAudio.create() then os.exit(1) end
-- generate a sample:
local sample = sampleSine(440, 0.5, 88200)
-- play scale (a major):
local duration = 0.5
for i,note in ipairs({ 0, 2, 4, 5, 7, 9, 11, 12 }) do
playNote(sample, note, duration)
end
-- cleanup
proAudio.destroy()
And since I got confused with this ProteaAudio Lua API, I really can't get why this error comes.
Please help.
This is actually just a guess, but...
To play a "major" scale upwards (8 notes, jumping: full full half, full full full half) the original code does:
local duration = 0.5
for i,note in ipairs({ 0, 2, 4, 5, 7, 9, 11, 12 }) do
playNote(sample, note, duration)
end
where the sample is a handle to a pre-generated sample created by proAudio.sampleFromMemory which is returned by function sampleSine, that passed it a calculated 'table' representing a 440hz sine-wave (concert-pitch frequency for note 'A4', the first above middle 'C').
Thus playing an 'A major scale' by changing (increasing) the 'pich' (frequency) of that sample (in 8 steps=notes). That pitch-calculation is done by function playNote.
Function playNote accepts the following arguments:
sample, pitch, duration, volumeL, volumeR, disparity,
but it currently does not receive the arguments:
volumeL, volumeR, disparity (which will then be nil).
So when function playNote tries to call:
proAudio.soundLoop(sample, volumeL, volumeR, disparity, scale),
then the call will end up like:
proAudio.soundLoop(sample, nil, nil, nil, scale),
where the sample is passed on and scale is the 'playback-pitch' of that sample, as just calculated (according to specified note) by function playNote.
Your error-message states: bad argument #1 to 'soundLoop' (number expected, got nil).
Hmm, that seems consistent with what is happening (assuming that 'bad argument #1' is the second argument, in this case volumeL).
So,
you might want to try specifying some values for volumeL, volumeR, disparity like:
local duration = 0.5
local volumeL = 1.0
local volumeR = 1.0
local disparity = 0.0
for i,note in ipairs({ 0, 2, 4, 5, 7, 9, 11, 12 }) do
playNote(sample, note, duration, volumeL, volumeR, disparity)
end
From the proteaAudio documentation one can read about soundLoop's arguments:
sample - A sample handle returned by a previous load() call
volumeL - (optional) Left volume
volumeR - (optional) Right volume
disparity - (optional) Time difference between left and right channel in seconds.
Use negative values to specify a delay for the left
channel, positive for the right.
pitch - (optional) Pitch factor for playback. 0.5 corresponds to one octave
below, 2.0 to one above the original sample.
If that should do the trick, then the arguments might not be so optional on Ubuntu.
Hope this helps!
I've inherited some Selenium Webdriver code (Ubuntu 11.10, Xvfb + Selenium 2.19.0 & Firefox 10.0.2, because that's the only combination I've been able to hit upon in the time available that actually installs.)
Note: I am not using the old Selenium 1.0 system, which most documentation seems to be focussed at.
My tests are running very slowly. Simple mouse movements are taking over half a second.
Looking at the (undocumented?!) /tmp/native_ff_events_log file, I find that each mouse operation is being divided up into smaller parts:
D14:14:37:070 cpp/webdriver-interactions/interactions_linux_mouse.cpp(307) ---------- starting mouseMoveTo: 0x7fbad37546a0---------
D14:14:37:070 cpp/webdriver-interactions/interactions_linux_mouse.cpp(328) From: (39, 169) to: (350, 86)
D14:14:37:070 cpp/webdriver-interactions/interactions_linux_mouse.cpp(329) Distance: 321 steps: 64
D14:14:37:070 cpp/webdriver-interactions/interactions_linux_mouse.cpp(339) Moving to: (39, 169)
D14:14:37:070 cpp/webdriver-interactions/interactions_linux_mouse.cpp(231) Type: motion time: 401697248
D14:14:37:080 cpp/webdriver-interactions/interactions_linux_mouse.cpp(339) Moving to: (43, 167)
D14:14:37:080 cpp/webdriver-interactions/interactions_linux_mouse.cpp(231) Type: motion time: 401697258
D14:14:37:090 cpp/webdriver-interactions/interactions_linux_mouse.cpp(339) Moving to: (48, 166)
D14:14:37:090 cpp/webdriver-interactions/interactions_linux_mouse.cpp(231) Type: motion time: 401697268
D14:14:37:100 cpp/webdriver-interactions/interactions_linux_mouse.cpp(339) Moving to: (53, 165)
D14:14:37:100 cpp/webdriver-interactions/interactions_linux_mouse.cpp(231) Type: motion time: 401697278
D14:14:37:110 cpp/webdriver-interactions/interactions_linux_mouse.cpp(339) Moving to: (58, 163)
It appears like there is some deliberate slowing down, similar to the legacy Selenium's setMouseSpeed(pixels), which breaks up drag-and-drop operations into 10 pixel submovements.
I'm not using drag-and-drop. Also, I believe this method is no longer available to me.
I do not believe these submovements are necessary, and removing them might speed the run considerably.
Is there a way to increase the size of the mouse steps in Selenium 2's Webdriver?
Oddthinking, looking at source code I found two values that make mouseMoveTo() so slowly:
const int stepSizeInPixels = 5;
http://code.google.com/p/selenium/source/browse/trunk/cpp/webdriver-interactions/interactions_linux_mouse.cpp?r=13310#278
const int timePerEvent = 10 /* ms */;
http://code.google.com/p/selenium/source/browse/trunk/cpp/webdriver-interactions/interactions_linux_mouse.cpp?r=13310#270
Unfortunately, there is no way to change this values on runtime level, because are hardcoded.
When mouse needs to move from Point A to Point B, it does using a 5 pixel step with 10ms interval. One step from my testcase was taking about 1.2 seconds to do a simple click()
I recompiled the firefox extension changing stepSizeInPixels to 50 and timePerEvent to 5ms. Now my testcase is taking 18 seconds, 8 seconds less that original extension.