I want to use Queue Module, and I don;t know how to create queue for int. Only thing that I need is how to parametrize a functor.
Could you help me?
The standard Queue module is not a functor. Moreover, it provides imperative-style queues. In other words, the standard enqueue/dequeue operations mutate the state of the queue. Here's an example of how to use it:
$ ocaml
OCaml version 4.00.1
# let myq = Queue.create ();;
val myq : '_a Queue.t = <abstr>
# Queue.add 4 myq;;
- : unit = ()
# Queue.add 100 myq;;
- : unit = ()
# Queue.take myq;;
- : int = 4
# Queue.take myq;;
- : int = 100
#
Related
I have the below test_dss.py file which is used for pytest:
import dataikuapi
import pytest
def setup_list():
client = dataikuapi.DSSClient("{DSS_URL}", "{APY_KEY}")
client._session.verify = False
project = client.get_project("{DSS_PROJECT}")
# Check that there is at least one scenario TEST_XXXXX & that all test scenarios pass
scenarios = project.list_scenarios()
scenarios_filter = [obj for obj in scenarios if obj["name"].startswith("TEST")]
return scenarios_filter
def test_check_scenario_exist():
assert len(setup_list()) > 0, "You need at least one test scenario (name starts with 'TEST_')"
#pytest.mark.parametrize("scenario", setup_list())
def test_scenario_run(scenario, params):
client = dataikuapi.DSSClient(params['host'], params['api'])
client._session.verify = False
project = client.get_project(params['project'])
scenario_id = scenario["id"]
print("Executing scenario ", scenario["name"])
scenario_result = project.get_scenario(scenario_id).run_and_wait()
assert scenario_result.get_details()["scenarioRun"]["result"]["outcome"] == "SUCCESS", "test " + scenario[
"name"] + " failed"
My issue is with setup_list function, which able to get only hard coded values for {DSS_URL}, {APY_KEY}, {PROJECT}. I'm not able to use PARAMS or other method like in test_scenario_run
any idea how I can pass the PARAMS also to this function?
The parameters in the mark.parametrize marker are read at load time, where the information about the config parameters is not yet available. Therefore you have to parametrize the test at runtime, where you have access to the configuration.
This can be done in pytest_generate_tests (which can live in your test module):
#pytest.hookimpl
def pytest_generate_tests(metafunc):
if "scenario" in metafunc.fixturenames:
host = metafunc.config.getoption('--host')
api = metafuc.config.getoption('--api')
project = metafuc.config.getoption('--project')
metafunc.parametrize("scenario", setup_list(host, api, project))
This implies that your setup_list function takes these parameters:
def setup_list(host, api, project):
client = dataikuapi.DSSClient(host, api)
client._session.verify = False
project = client.get_project(project)
...
And your test just looks like this (without the parametrize marker, as the parametrization is now done in pytest_generate_tests):
def test_scenario_run(scenario, params):
scenario_id = scenario["id"]
...
The parametrization is now done at run-time, so it behaves the same as if you had placed a parametrize marker in the test.
And the other test that tests setup_list now has also to use the params fixture to get the needed arguments:
def test_check_scenario_exist(params):
assert len(setup_list(params["host"], params["api"], params["project"])) > 0,
"You need at least ..."
The following code (not mine) is able to run NotebookA and NotebookB concurrently. I need some help to figure out how to pass multiple arguments to the same notebooks.
I want to pass this list of arguments to each notebook:
args = {}
args["arg1"] = "some value"
args["arg2"] = "another value"
If I wanted to pass the arguments above to each of the running notebooks, what will I need to amend in the code below?
Here is the working code:
from multiprocessing.pool import ThreadPool
pool = ThreadPool(10)
inputs = [("NotebookA", "NotebookB") ]
run_in_parallel = lambda x: dbutils.notebook.run(x, 1800)
from concurrent.futures import ThreadPoolExecutor, wait
pool = ThreadPoolExecutor(3)
results = []
with ThreadPoolExecutor(3) as pool:
for x in inputs:
results.extend(pool.map(run_in_parallel, list(x)))
The dbutils.notebook.run accepts the 3rd argument as well, this is a map of parameters (see documentation for more details). So in your case, you'll need to change definition of the run_in_parallel to something like this:
run_in_parallel = lambda x: dbutils.notebook.run(x, 1800, args)
and the rest of the code should be the same.
If you'll want to pass different arguments to different notebooks, then you'll need to have a list of tuples, and pass this list to a map, like this:
data = [('notebook 1', {'arg1':'abc'}), ('notebook2', {'arg1': 'def', 'arg2': 'jkl'})]
...
run_in_parallel = lambda x: dbutils.notebook.run(x[0], 1800, x[1])
with ThreadPoolExecutor(3) as pool:
results.extend(pool.map(run_in_parallel, data))
Suppose I have 2 notebooks of which the first is the main and the second is for testing.
In the main, I have the following
dbutils.notebook.run("testing", timeoutSeconds = 60, arguments = Map("var" -> "1234"))
In testing:
%scala
println(s"Donut price = $var")
And in Main run the notebook. There is error:
You can pass arguments to DataImportNotebook and run different notebooks (DataCleaningNotebook or ErrorHandlingNotebook) based on the result from DataImportNotebook.
val status = dbutils.notebook.run("DataImportNotebook", timeoutSeconds
= 60, argumenrs = Map ("x" -> "1234"))
println("Status: " + status)
In scala, the variables are declared as follows:
The following are examples of value definitions:
var $price = 1234
println("Donut price:" + $price)
For more details, refer "Scala - How to declare variables" and "Databricks - Notebook workflows".
Hope this helps.
I don't know all Swift mechanics, and how it handles variables.
I always preferred to declare variables before entering a for or while loop, not matter the language, rather than declaring them inside the loop over and over.
But is it that bad to re-declare variables ? Would it affect performance with a very large iteration ? How does specifically Swift handle this behavior ?
example :
while i < 100 {
let a = someFunc()
i += 1
}
VS
let a: MyObj
while i < 100 {
a = someFunc()
i += 1
}
This would not impact performance, and version 1 is highly preferred. Even if it would impact performance, you would need to demonstrate that on your precise code before you would consider any other option but version 1. There are no universal performance answers when dealing with an optimizing compiler. Doing anything unusual "for performance" that you have not deeply explored with your code runs a high likelihood of making things worse. The normal cases are the most optimized cases.
(I know I'm overstating this. There are definitely ways to look at code and say "that's going to be horribly inefficient." And there are some quirky parts of Swift where things that look ok are in fact bad, most notably using + to combine strings, or using pre-Swift4 reduce to create an array. But in the cases that those matter, you're going to discover it really quickly because they're really bad when they matter.)
But we don't have to guess about any of this. We can just ask the compiler.
// inside.swift
import Foundation
func runme() {
var i = 0
while i < 100 {
let a = Int.random(in: 0...10)
print(a)
i += 1
}
}
// outside.swift
import Foundation
func runme() {
var i = 0
var a: Int
while i < 100 {
a = Int.random(in: 0...10)
print(a)
i += 1
}
}
First, note that I put these in a function. That's important. Putting them at the top level makes a a global in one case, and globals have special handling, including thread-safe initialization, which makes the "outside" case look more expensive and complicated than it would be in more normal usage. (It is very, very hard to correctly test micro-optimizations in such a way that you can draw general "this is faster" conclusions. There are so many factors.)
Second notice the print. We need to make sure to use a in a side-effecty way, or else the optimizer might remove it entirely. print is pretty good, even though it's quite complicated. You can also use the result to modify a global, but the compiler could definitely optimize that much more aggressively and might eliminate things we wanted to see. (You really really have to test this stuff on the actual case you care about.)
Now we can see what Swift is going to do with each of these using swiftc -O -emit-sil. That -O is critical. So many people try to do performance testing without turning on the optimizer, and those results are beyond meaningless.
So what's the SIL look like? (Swift Intermediate Language. This is the first big step towards turning your program into machine code. If two things generate the same SIL, they're going to generate the same machine code.)
The SIL is a little long (8000 lines), so I'm going to trim it a bit. My comments in <>. This is going to get a little tedious, because exploring this stuff is very nitpicky. If you want to skip it, the TL-DR is: there's no difference between these two pieces of code. Not "a small difference that won't matter." Literally (except for a hint to the debugger), no difference.
// runme()
sil hidden #$S4main5runmeyyF : $#convention(thin) () -> () {
bb0:
... <define a bunch of variables and function calls> ...
<compute the random number and put it in %29>
// %19 // user: %49
bb1(%19 : $Builtin.Int64): // Preds: bb5 bb0
%20 = alloc_stack $SystemRandomNumberGenerator // users: %23, %30, %21
store %2 to %20 : $*SystemRandomNumberGenerator // id: %21
br bb2 // id: %22
bb2: // Preds: bb3 bb1
%23 = apply %6<SystemRandomNumberGenerator>(%20, %5) : $#convention(method) <τ_0_0 where τ_0_0 : RandomNumberGenerator> (#inout τ_0_0, #thin UInt.Type) -> UInt // user: %24
%24 = struct_extract %23 : $UInt, #UInt._value // users: %28, %25
%25 = builtin "cmp_ult_Int64"(%24 : $Builtin.Int64, %4 : $Builtin.Int64) : $Builtin.Int1 // user: %26
cond_br %25, bb3, bb4 // id: %26
bb3: // Preds: bb2
br bb2 // id: %27
bb4: // Preds: bb2
%28 = builtin "urem_Int64"(%24 : $Builtin.Int64, %3 : $Builtin.Int64) : $Builtin.Int64 // user: %29
%29 = struct $Int (%28 : $Builtin.Int64) // users: %42, %31
dealloc_stack %20 : $*SystemRandomNumberGenerator // id: %30
< *** Note that %29 is called "a" *** >
debug_value %29 : $Int, let, name "a" // id: %31
... < The print call. This is a lot more code than you think it is...> ...
< Add one to i and check for overflow >
%49 = builtin "sadd_with_overflow_Int64"(%19 : $Builtin.Int64, %8 : $Builtin.Int64, %13 : $Builtin.Int1) : $(Builtin.Int64, Builtin.Int1) // users: %51, %50
%50 = tuple_extract %49 : $(Builtin.Int64, Builtin.Int1), 0 // users: %55, %53
%51 = tuple_extract %49 : $(Builtin.Int64, Builtin.Int1), 1 // user: %52
cond_fail %51 : $Builtin.Int1 // id: %52
< Loop if i < 100 >
%53 = builtin "cmp_slt_Int64"(%50 : $Builtin.Int64, %1 : $Builtin.Int64) : $Builtin.Int1 // user: %54
cond_br %53, bb5, bb6 // id: %54
bb5: // Preds: bb4
br bb1(%50 : $Builtin.Int64) // id: %55
bb6: // Preds: bb4
%56 = tuple () // user: %57
return %56 : $() // id: %57
} // end sil function '$S4main5runmeyyF'
The "outside" code is almost identical. What's different? Note where the *** in the code above marking the call to debug_value? That's missing in "outside" because a is defined as a function variable rather than a block variable.
Know what's missing in both of these? An alloc_stack call for "a". It's an integer; it can fit in a register. It's up to the lower level compiler whether it's stored in a register or the stack. The optimizer sees that "a" doesn't escape this region of the code, so it includes a hint for the debugger, but it doesn't actually bother to demand storage for it, not even on the stack. It can just take the return register of Random and move it to the parameter register for print. It's up to LLVM and its optimizer to decide all this.
The lesson from all this is that it literally doesn't matter for performance. In obscure cases where it might matter (such as when a is a global), version 1 would be more efficient, which I assume is the opposite of what you were expecting.
Swift handles this like most languages handle it. Local variables are declared on the stack, and popped off the stack when you exit the scope where they are defined. Pushing to and popping off of the stack is a very low-cost operation.
The LLVM compiler that Swift uses uses quite advanced code optimization, especially in release mode. In your trivial example the variables you're using the variables might well be optimized away anyway, since they aren't actually used for anything.
EDIT:
To summarize, there is no meaningful performance difference between the 2, and the first approach of putting the variable inside the loop is cleaner, as stated by rmaddy in his comment. Defining variables in the narrowest scope possible is a good policy. It shows your intent for the variable, and avoids unintended consequences.
I wish to do the following in Specman:
my_task() is {
var my_var : int;
my_var = 5;
message(LOW,appendf("%s=[%d]",my_var.to_name(),my_var));
};
Currently, I'm in search of the internal task to_name(). I do not want to create a struct for this. I wish to only use Specman internals.
I'm not sure how you'd do this unless you somehow have the collection of all the fields, which would give you the name of all the fields.
So, I'm going to branch predict and assume that you want all the fields of a given struct/unit:
extend sys {
A : list of uint;
B : int;
cee : string;
run() is also {
var rf_sys: rf_struct = rf_manager.get_exact_subtype_of_instance(sys);
for each (field) in rf_sys.get_declared_fields() {
print field;
print field.get_long_name(); // <-- Here's your "get_name()" function
};
};
};
On version 8.2, this yields:
Usage: . env.sh [-32bit|-64bit] [-v] [[VAR=value]...]
Welcome to Specman Elite(64) (09.20.482-d) - Linked on Wed Mar 2 13:32:19
2011
Protected by U.S. Patents 6,141,630 ;6,182,258; 6,219,809; 6,347,388;
6,487,704; 6,499,132; 6,502,232; 6,519,727; 6,530,054; 6,675,138; 6,684,359;
6,687,662; 6,907,599; 6,918,076; 6,920,583; Other Patents Pending.
1 notification was modified by command 'set notify -severity=WARNING
DEPR_START_TCM_ARG_BY_REF'
Checking license ... OK
Loading /nfs/pdx/home/rbroger1/tmp.e ...
read...parse...update...patch...h code...code...clean...GC(sys)...
Doing setup ...
Generating the test using seed 1...
Starting the test ...
Running the test ...
field = rf_field 'time', Specman's private modules
field.get_long_name() = "time"
field = rf_field 'logger', Specman's private modules
field.get_long_name() = "logger"
field = rf_field 'A', line 5 in #tmp
field.get_long_name() = "A"
field = rf_field 'B', line 6 in #tmp
field.get_long_name() = "B"
field = rf_field 'cee', line 7 in #tmp
field.get_long_name() = "cee"
No actual running requested.
Checking the test ...
Checking is complete - 0 DUT errors, 0 DUT warnings.
If that doesn't quite answer your question, look more into Specman's introspection or reflection interface in the documentation for your version of Specman. Warning, details are a bit scarce from Cadence. Also, see my answer to "Specman: how to retrieve values of var which is stored in another var".. Finally, in specview you can use the data browser to browse the rf_manger itself ( introspection at its best). Then you can find all the functions that Cadence doesn't tell you about in their documentation.
You can't get the string name of a variable. Although you can get the name of a field using get_name().
This makes some sense, because the variable is only known at the location it is declared. You can't even access the variable in a later extension of my_task(). So if you are already editing the code at the location where the variable was declared, just say "my_var" rather than my_var.to_name(). (Yes, typos and cut and paste errors can happen.)
I think this is what you are looking for:
define <dump'action> "dump <exp>" as {
out("<exp>","=[",<exp>,"]");
};
you can use this macro in the specman command line or inside functions, for example:
foo() is {
var a : int = 5;
dump a;
};
will give:
a=[5]