How to use `--define`d variable in `bazel` rule? - bazel

I would like to do something like:
DEFAULT_CLUSTER_ALIASES = {
"local": "$(DEFAULT_LOCAL_CLUSTER)",
}
def helm_action(**kwargs):
if not "$(DEFAULT_LOCAL_CLUSTER)":
DEFAULT_LOCAL_CLUSTER = "docker-desktop"
_helm_action(
cluster_aliases = DEFAULT_CLUSTER_ALIASES,
**kwargs
)
IOW, if DEFAULT_LOCAL_CLUSTER is not defined, DEFAULT_CLUSTER_ALIASES will be dict("local": "docker-desktop").
and if --define=DEFAULT_LOCAL_CLUSTER=minikube, DEFAULT_CLUSTER_ALIASES will be dict("local": "minikube").
So far, I haven't been able to get the Make variable to be evaluated and DEFAULT_CLUSTER_ALIASES is dict("local": "$(DEFAULT_LOCAL_CLUSTER)").
What's needed so the Make variable is evaluated?

"make variables" are only evaluated in the context of rule attributes that support make variable substitution. See https://bazel.build/reference/be/make-variables#use
If helm_action is a macro, or is used from a macro, then this won't work because macros don't have access to configuration information (e.g. values from flags). If helm_action is used from a rule implementation, then you can access values set using --define from ctx.var: https://bazel.build/rules/lib/ctx#var
Another way to do this is to use Starlark flags: https://bazel.build/rules/config#user-defined-build-settings Though again, it depends on if you're writing a macro or a rule.

Related

Is using `std::shared_ptr` for in/out variables reasonable?

I need some advise regarding usage of std::shared_ptr for In/Out parameters. Is having something like
std::shared_ptr<Big> expensive_process(std::shared_ptr<Big> foo)
{
// process foo
...
return foo;
}
considered bad practice (as opposed to the usual way of void expensive_process(Big& foo))?. This signature works uniformly (if adopted everywhere) when foo is either a local variable or a temporary, e.g. expensive_process(another_process(foo)) or expensive_process(foo->clone()).
Rationale
I am currently using the following signature when processing data in-place:
void process(Big& foo);
Changing the signature to shared_ptr<Big> process(shared_ptr<Big> foo) has two main benefits:
It allows chaining, i.e. foo = f1(f2(foo)) is valid if f1 and f2 both have the same signature.
Secondly, it allows working with local and temporary variables uniformly, i.e. foo = f1(foo) and another_foo = f1(foo->clone()) both work.
Neither of these two are possible with the original signature.

How to conditionally init a const variable?

I am trying to init a const variable differently based on another const string.
Code is not inside a class, just plain dart.
Only way I found is using the elvis operator but it's quite ugly and will become unmaintanable with many conditions to handle ...
How would you do it ?
test.dart called with --dart-define CONTEXT=context-A:
// can be : "context-A" or "context-B" or "context-C" etc ...
const contextString = String.fromEnvironment('CONTEXT');
const Context contextObject = (contextString == 'context-A')
? ContextA()
: (contextString == 'context-B')
? ContextB()
: ContextC();
Any other method (like calling an init method) fails with dart telling me that I cannot init a const variable with a non const method :(
Thanks
Personally I would use the ternary conditional operator as you're already using; I don't think it's unreadable, and as long as you don't have too many cases (which itself would be a maintenance problem), the indentation creep shouldn't be too bad.
However, one alternative would be to abuse collection-if:
const contextObject = [
if (contextString == 'context-A')
ContextA()
else if (contextString == 'context-B')
ContextB()
else
ContextC()
];
which is formatted more nicely (as long as the expression is sufficiently long that dart format doesn't try to squeeze it all onto a single line). However, I don't recommend this because:
You'll need to some extra overhead of using operator [] everywhere to access the intended object.
Equality comparisons are potential pitfall. contextObject == const [ContextA()] will work, but if const is accidentally omitted, it will never compare equal.
(At some point, perhaps if-expressions will be added to Dart.)

Nix overlays and override pattern

I have trouble understanding Nix overlays and the override pattern. What I want to do is add something to "patches" of gdb without copy/pasting
the whole derivation.
From Nix Pills I kind of see that override just mimics OOP, in reality it is just another attribute of the set. But how does it work then? Override is a function from the original attribute set to a transformed one that again has a predefined override function?
And as Nix is a functional language you also don't have variables only bindings which you can shadow in a different scope. But that still doesn't explain how overlays achieve their "magic".
Through ~/.config/nixpkgs I have configured a test overlay approximately like this:
self: super:
{
test1 = super.gdb // { name = "test1"; buildInputs = [ super.curl ]; };
test2 = super.gdb // { name = "test2"; buildInputs = [ super.coreutils ]; };
test3 = super.gdb.override { pythonSupport = false; };
};
And I get:
nix-repl> "${test1}"
"/nix/store/ib55xzrp60fmbf5dcswxy6v8hjjl0s34-gdb-8.3"
nix-repl> "${test2}"
"/nix/store/ib55xzrp60fmbf5dcswxy6v8hjjl0s34-gdb-8.3"
nix-repl> "${test3}"
"/nix/store/vqlrphs3a2jfw69v8kwk60vhdsadv3k5-gdb-8.3"
But then
$ nix-env -iA nixpkgs.test1
replacing old 'test1'
installing 'test1'
Can you explain me those results please? Am I correct that override can just alter the "defined interface" - that is all parameters of the function and as "patches" isn't a parameter of gdb I won't be able to change it? What is the best alternative then?
I will write an answer in case anyone else stumbles on this.
Edit 21.8.2019:
what I actually wanted is described in https://nixos.org/nixpkgs/manual/#sec-overrides
overrideDerivation and overrideAttrs
overrideDerivation is basically "derivation (drv.drvAttrs // (f drv))" and overrideAttrs is defined as part of mkDerivation in https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/make-derivation.nix
And my code then looks like:
gdb = super.gdb.overrideAttrs (oldAttrs: rec {
patches = oldAttrs.patches ++ [
(super.fetchpatch {
name = "...";
url = "...";
sha256 = "...";
})
];
});
The question title is misleading and comes from my fundamental misunderstanding of derivations. Overlays work exactly as advertised. And they are probably also not that magic. Just some recursion where endresult is result of previous step // output of last overlay function.
What is the purpose of nix-instantiate? What is a store-derivation?
Correct me please wherever I am wrong.
But basically when you evaluate Nix code the "derivation function" turns a descriptive attribute set (name, system, builder) into an "actual derivation". That "actual derivation" is again an attribute set, but the trick is that it is backed by a .drv file in the store. So in some sense derivation has side-effects. The drv encodes how the building is supposed to take place and what dependencies are required. The hash of this file also determines the directory name for the artefacts (despite nothing was built yet). So implicitly the name in the nix store also depends on all build inputs.
When I was creating a new derivation sort of like Frankenstein based on tying together existing derivations all I did was create multiple references to the same .drv file. As if I was copying a pointer with the result of getting two pointers pointing to the same value on the heap. I was able to change some metadata but in the end the build procedure was still the same. Infact as Nix is pure I bet there is no way to even write to the filesystem (to change the .drv file) - except again with something that wraps the derivation function.
Override on the other hand allows you to create a "new instance". Due to "inputs pattern" every package in Nix is a function from a dependencies attribute set to the actual code that in the end invokes the "derivation function". With override you are able to call that function again which makes "derivation function" get different parameters.

Why we don't need to provide initial value for local variables?

While I was learning suddenly I wondered myself:
why do we have to provide initial values for global(even beyond a class scope) variable but we do not have to do same step with local variables like this? Is there any reason?
if importRequired {
let deleteObjectCount: Int
}
It is allowed, because deleteObjectCount is never been used in your code. And - and this is the difference to global variables - this fact can be checked by the compiler.
You could even do something like:
let importRequired = true
if importRequired {
let deleteObjectCount: Int
deleteObjectCount = 5
print (deleteObjectCount)
}
(e.g. kind-of modify a constant let variable) because the compiler checks that the constant is written only once, and this is done before reading it's value.
In contrast, global variables must be initialized directly, because otherwise the compiler cannot guarantee that they have been so before being initialized (because the could be accessed from anywhere in your program).

Forward define a function in Lua?

How do I call a function that needs to be called from above its creation? I read something about forward declarations, but Google isn't being helpful in this case. What is the correct syntax for this?
Lua is a dynamic language and functions are just a kind of value that can be called with the () operator. So you don't really need to forward declare the function so much as make sure that the variable in scope when you call it is the variable you think it is.
This is not an issue at all for global variables containing functions, since the global environment is the default place to look to resolve a variable name. For local functions, however, you need to make sure the local variable is already in scope at the lexical point where you need to call the value it stores, and also make sure that at run time it is really holding a value that can be called.
For example, here is a pair of mutually recursive local functions:
local a,b
a = function() return b() end
b = function() return a() end
Of course, that is also an example of using tail calls to allow infinite recursion that does nothing, but the point here is the declarations. By declaring the variables with local before either has a function stored in it, those names are known to be local variables in lexical scope of the rest of the example. Then the two functions are stored, each referring to the other variable.
You can forward declare a function by declaring its name before declaring the actual function body:
local func1
local func2 = function()
func1()
end
func1 = function()
--do something
end
However forward declarations are only necessary when declaring functions with local scope. That is generally what you want to do, but Lua also supports a syntax more like C, in which case forward declaration is not necessary:
function func2()
func1()
end
function func1()
--do something
end
Testing under the embedded lua in Freeswitch, forward declaration does not work:
fmsg("CRIT", "It worked.")
function fmsg(infotype, msg)
freeswitch.consoleLog(infotype, msg .. "\n")
end
result:
[ERR] mod_lua.cpp:203 /usr/local/freeswitch/scripts/foo.lua:1: attempt to call global 'fmsg' (a nil value)
Reversing the order does (duh) work.
To comprehend how forward referencing in Lua works compared to C, you must understand the a fundamental difference between C compilation and the Lua execution.
In C, forward referencing is a compile time mechanism. Hence if you include a forward declaration template in a C module then any of your code following will employ this template in compiling the call. You may or may not include the function implementation in the same module, in which case both declarations must be semantically identical or the compiler will error. Since this is a compile time construct, the compiled code can be executed in any order.
In Lua, forward referencing is runtime mechanism, in that the compiled function generates a function prototype internally within the code, but this is only accessible as a runtime Lua variable or value after the execution has
passed over the declaration creating a Lua closure. Here the declaration order within the source is immaterial. It is the execution order that is important: if the closure hasn't been bound to the variable yet, then the execution will throw a "nil value" exception.If you are using a local variable to hold the function value, then normal local scoping rules still apply: the local declaration must precede its use in the source and must be within scope, otherwise the compiler will compile in the wrong global or outer local reference. So forward referencing using locals as discussed in other answer will work, but only if the Protos are bound to closures before the first call is executed.
Doesn't work for me if I try to call the function before definition. I am using this Lua script in nginx conf.
lua entry thread aborted: runtime error: lua_redirect.lua:109: attempt to call global 'throwErrorIfAny' (a nil value)
Code snippet -
...
throwErrorIfAny()
...
function throwErrorIfAny()
ngx.say("request not allowed")
ngx.exit(ngx.HTTP_OK)
end
Given some other answers have also pointed out that it didn't work for them either, it is possible that forward declaration of Lua doesn't work with other tools.
PS : It works fine if I put the function definition before and then call it after wards.
If you use OOP you can call any function member prior its "definition".
local myClass = {}
local myClass_mt = { __index = myClass }
local function f1 (self)
print("f1")
self:later() --not yet "delared" local function
end
local function f2 (self)
print("f2")
self:later() --not yet "declared" local function
end
--...
--later in your source declare the "later" function:
local function later (self)
print("later")
end
function myClass.new() -- constructor
local this = {}
this = {
f1 = f1,
f2 = f2,
later = later, --you can access the "later" function through "self"
}
setmetatable(this, myClass_mt)
return this
end
local instance = myClass.new()
instance:f1()
instance:f2()
Program output:
f1
later
f2
later

Resources