I have written a simple function named is_zero in Erlang which checks if the argument to the function is zero. The code is as follows.
-module(match).
-export([is_zero/1]).
% defining a function named is_zero
% this is a function with two clauses
% these clauses are matched sequentially
is_zero(0) ->
true;
is_zero(X) ->
false.
As I try to compile the code using c(match).(the file is also named as match.erl) it returns a warning saying variable "X" is unused.
If I run is_zero(0). in spite of the warning, the shell throws an exception error saying undefined shell command is_zero/1
What am I doing wrong?
I cannot think of any rectification neither can I find any advice that will help.
Functions in Erlang are defined inside modules. To distinguish functions from different modules, you need to prepend the module name to a function. In this case, you need to run match:is_zero(0). Instead of just is_zero(0)..
To avoid the warning saying variable "X" is unused, use the underscore variable:
is_zero(_) ->
false.
Note that variable names can be useful even if unused, to improve readability. If you want to name your variable and still avoid the compiler warning, prepend the underscore to the name:
is_zero(_Num) ->
false.
Related
I've run into a specific problem while trying to automate a tagging process in terraform. I've set an environment variable that is essentially a list of all the tags we'd be using for all resources provisioned in the apply. It looks like this...
export TF_VAR_taglist='{JiraEpic = "ETOS-56","AssignedResearcherPri" = "Isaac",AssignedResearcherSec = "Matt"}'
After setting the environment variable I added a variable called "taglist" in the variables.tf file that grabs the aforementioned environment variable. It looks like this...
variable "taglist"{}
Lastly, I have another locals.tf file where i set a common_tags variable. Like so...
locals { common_tags ="${var.taglist}" }
When i terraform apply, the build fails while trying to map the tags properly. This is the error i receive...
Error: Incorrect attribute value type
on kube_master_worker_nodes_ec2.tf line 9, in resource "aws_instance" "master":
9: tags = local.common_tags
|----------------
| local.common_tags is "{JiraEpic = \"ETOS-56\",AssignedResearcherPri = \"Isaac \",AssignedResearcherSec = \"Matt\"}"
Inappropriate value for attribute "tags": map of string required.
I then decided to define the type of the variable as map(string in the variables.tf file like this
variable "taglist"{ type = map(string) }
I had hoped that this would allow terraform to recognize this variable as a map of strings and not just a string literal, but I was wrong, and these are the errors I get when that definition is applied.
Error: Missing attribute separator
on <value for var.taglist> line 1:
(source code not available)
Expected a newline or comma to mark the beginning of the next attribute.
Error: No value for required variable
on variables.tf line 11:
11: variable "taglist"{
The root module input variable "taglist" is not set, and has no default value.
Use a -var or -var-file command line argument to provide a value for this
variable.
I'm really stuck on this, and I feel like I'm close. Can anyone provide some insight into this and how I should go about solving it?
I want to first thank Martin Atkins for giving me the idea of using colons instead of equal signs in my environment variable, because that was the ONLY issue. The variable was not properly represented as a JSON object so terraform was interpreting it as a string.
I changed
export TF_VAR_taglist='{JiraEpic = "ETOS-56","AssignedResearcherPri" = "Isaac",AssignedResearcherSec = "Matt"}'
to this
export TF_VAR_taglist='{"JiraEpic":"ETOS-56","AssignedResearcherPri":"Isaac", "AssignedResearcherSec":"Matt"}'
The build purrs like a kitten on catnip now.
Terraform uses the type constraint of a variable to decide how to interpret a string representation of its value. By default, Terraform will assume the value expects a primitive type such as a string or number, because that's the most typical case for variables set via the command line or environment variables.
Since your tag list is a list you need Terraform to interpret it as a map expression rather than as a string. You can tell Terraform to do that by telling Terraform which type of value you expect:
variable "taglist" {
type = map(string)
}
You can read more about this in the Terraform documentation section Complex-typed Values.
You then need to make sure that the value in the environment variable is a valid object expression in order to avoid a syntax error. If you're setting the environment variable from the shell command line then you need to be mindful of escaping/quoting to ensure that Terraform will see the value with all of the quotes intact, and without any extra metacharacters.
The result is often hard to read clearly, which is why the Terraform documentation recommends using a .tfvars file to set complex-typed variables, instead of the -var command line option or environment variables. However, since you are using automation you might find it easier to generate a .tfvars.json file instead, which uses standard JSON format and is therefore easier to generate using JSON libraries available in most programming languages. Here's the .tfvars.json equivalent of the value you showed in your question:
{
"taglist": {
"JiraEpic": "ETOS-56",
"AssignedResearcherPri": "Isaac",
"AssignedResearcherSec": "Matt"
}
}
Note that subjectively I'd find it pretty confusing to have a variable whose name ends in list when it actually expects a map. A more typical name for this variable would be just tags, though if it's useful to mention its type in order to distinguish it from other variables then I'd suggest tag_map instead, to make it less confusing.
There is something that is not completely clear to me on hydra. The following jobset:
{ nixpkgs ? import <nixpkgs>
{ config.allowUnfree = true;
config.allowBroken = true;
}
, my_package ? path/to/package/default.nix ## working expr
}:
let
jobs = {
jobA = import ../path/to/jobA/default.nix {inherit my_package;};
};
in
jobs
with 2 build inputs:
ciSrc
nixpkgs
evaluates without errors, and then is built.
BUT, when I change the working expr to:
my_package ? import <my_package> ## problematic expr
and add a third build input:
my_package, Local Path, path/to/package/default.nix
I get the following error:
hydra-eval-jobs returned exit code 1:
error: undefined variable 'foo' at /nix/store/somehash-my_package/.../default.nix:61:11
(use '--show-trace' to show detailed location information)
Why do I get it? what am I missing here?
My NIX_PATH contains both <nixpkgs> that works, and <my_package>, which isn't. This is the only change i did that produces the error.
btw both versions are built by nix-build, as recommended by the hydra-manual
on the same machine and by the same user that the hydra uses.
can anyone please shed light on it?
I doubt that the undefined variable error message is directly caused by swapping the build inputs. It's more likely that the problem has been lurking for a while but never triggered, and swapping the inputs like this has caused it to surface. If that's the case, it's impossible to say what's causing the problem since you've stripped out all of the relevant information. To get better help in the future, I suggest that you post a minimal, complete example of code which encounters this problem. What you've posted is indeed minimal, but it's incomplete (the problem seems to be with package/default.nix, which you haven't included), and also doesn't look like code which encounters this problem (based on things like somehash, path/to/package, etc. I imagine that running this code would hit a syntax error first).
All we know is that a variable has been used without an accompanying binding. Your error message says that the variable is called foo, but I assume that's not the real name. Given this scant information, I would guess that the problem is in your package/default.nix file.
There are a few gotchas to keep in mind with paths in Nix:
Path values used by a derivation (like /tmp/project/foo.nix) will be copied to the Nix store and those values (e.g. /nix/store/...-foo.nix) will be used instead of the original path. This can break relative paths, e.g. if foo.nix references ./bar.nix, then the latter will resolve to /nix/store/bar.nix which doesn't exist. This can be managed by getting the directory added to the store, e.g. "${/tmp/project}/foo.nix".
String values, like "/tmp/project/foo.nix", do not cause things to be copied into the store.
It's easy for calculations to turn paths into strings, but hard to keep them as paths. One useful trick is to use + with a path as the first argument, e.g. /tmp + "/project" will produce the path /tmp/project. We can use this with "/.." to go up a level. As an extreme case, we can convert a string containing an absolute path to a path value by doing e.g. with { myString = "/foo/bar"; }; /tmp + "/..${myString}", which will give the path /tmp/../foo/bar which resolves to /foo/bar.
When a mutable local path gets inserted into the Nix store, it's only an immutable "snapshot". If the contents are changed later, it can be a little unpredictable whether the old, cached snapshot will be used or whether a new snapshot will be made. For this reason, it's important to look at the paths given in error messages, e.g. take a look at /nix/store/...-project/foo.nix rather than /tmp/foo.nix, since they may not contain the same thing.
HHVM 3.9 is not such a fan of ternary statements with named functions, even when passed through fun(), but ≥3.10 is totally fine with them. It seems as though this is one of few cases, however, because 3.9 does accept named functions returned from concrete functions, as well as accepting named functions passed into other functions (3v4l):
<?hh
echo ((() ==> fun('strlen'))())('Hello'); // 5
echo (($f, $v) ==> $f($v))(strlen, 'Hello'); // 5 + Notice: Use of undefined constant strlen - assumed 'strlen'
echo (true ? strlen : intval)('100'); // Fatal error: syntax error, unexpected '(', expecting ',' or ';' on line 3
What changed between 3.9 and 3.10? Are there any cases in HHVM ≥3.10 where named functions cannot be referenced and used this way?
First, when writing Hack, don't write your code at toplevel; the hh_client typechecker can't check anything at toplevel. And 3v4l doesn't run the typechecker at all, you need to run it locally.
That said, no, Hack doesn't really have first-class functions. Most of its behaviour here it inherited from PHP, which also doesn't have them. Back when I was working on the Hack team, we tossed around a lot of ideas for adding them to the language; it's an obvious addition and need. But the need was never quite strong enough such that we sat down and actually worked out the details for both the type system and runtime implications; in particular, how to work out some of the scoping issues that the current callables have. Anonymous functions fill out enough of the need, especially with Hack's short lambda syntax, that there was always something more pressing to deal with.
So Hack just has PHP's normal callable forms; fun is one of a few special functions which give information to the typechecker that the string you specified actually represents a function so the typechecker can do proper type analysis. But at the end of the day, fun just boils down to the usual PHP callable forms with a bit of extra magic in the typechecker.
As to the behaviour you indicate in your 3v4l link. Using strlen and intval like that would cause a type error in Hack, since those are syntactically constants but constants with those names don't exist since Hack doesn't have first-class functions -- or it would if the code weren't at toplevel and you were running the typechecker. As to why it causes a parse error in HHVM 3.9 (which masks the "invalid constant" errors you see in 3.10), I'm not 100% sure. Judging from this example which works in PHP7 and HHVM 3.10, but not PHP5 and HHVM 3.9, my guess it is a PHP7 feature that is backwards compatible and so is always enabled in HHVM.
I'm using the closure compiler to minify and speed up my code but I'm running into some issues with JSLint when I try to export my functions.
Basically, I have an object, foo{} with a function, foo.bar() that gets called via an external file as. In order for this function to be called externally I need to add some declarations to my script before it gets compiled:
window['foo'] = foo;
window['foo']['bar'] = foo.bar;
This works great, but—as ever—JSLint thinks I'm mental for even attempting this. I've managed to suppress the dot notation error by declaring, /*jslint sub: true */ just before these two lines but I still get the following error:
"window['foo']['bar'] = foo.bar;" - Weird assignment
It's not wrong, it is a weird assignment out of context, but I need it in there in order for my code to work.
The way I see it, I have three possible options:
Tell JSLint not to bother even looking at them two lines.
Suppress the Weird assignment error.
Find another way to make my code work with closure compiler.
The problem is, I have no idea how to go about doing any of them.
You can export names using goog.exportSymbol instead of bracket notation: https://github.com/google/closure-library/blob/master/closure/goog/base.js#L1532
The Closure Compiler understands what goog.exportSymbol is so it'll remove the explicit exportSymbol call and add foo and bar directly to the window for you.
At the beginning of a makefile I have this line :
PATH := $(PATH):/other/dir
and this gives this error: Recursive variable 'PATH' references itself. What do I have to do so it works?
GNU make (and many others) has two main ways of assigning values to variables. They differ according to the operator which you use. According to the documentation, a single equals sign (=) will cause a recursive expansion of the value, whereas a colon-equals (:=) will cause a simple expansion.
Your quoted code uses a := and so should cause a simple expansion. What you are seeing is an error message associated with a recursive expansion. I would expect that sort of error if you had something like this:
PATH = $(PATH):/other/dir
Could the error be being caused by a different line in your makefile which you haven't quoted? If you're sure that your cut-and-pasting is correct, and that it is this line which is causing the problem, it would be helpful if we could see the whole, unedited makefile.
Another possibility is to use the shell function:
PATH = $(shell printenv PATH):/other/dir
try changing $(PATH) to ${PATH}