I see; I did think it was the problem that affected a lot of OTP 26 functionality in Windows last fall, and which I was very glad got fixed. I haven’t run into this issue.
(well, I’m still not sure what issue. I did see the linked issue about Ctrl-C breaking the terminal, and I run into that all the time but I have a little batch file to fix it when it happens, and it wouldn’t happen to an end user. The batch file to fix that goes like this:
Oh, yeah - it’s often thing when you update your Elixir version. Well … you don’t need to see logs of dependencies, so maybe simply call mix deps.compile and mix compile separately then? After first one you can just clear your console.
At the moment, Elixir developers will interact with set-theoretic types only through warnings found by the type system.
I’d love to test out the new type system and see the new warnings. I tried an example based on the reference document, but I think I must be doing something wrong:
defmodule Test do
def negate(x) when is_integer(x), do: -x
def negate(x) when is_boolean(x), do: not x
def test() do
IO.puts negate(1)
IO.puts negate(true)
# warning expected?
IO.puts negate("Hello")
end
end
I noticed this too but on a re-read, I believe the opening paragraph of the Warnings from gradual set-theoretic types is slightly confusing and not meant to mean all patterns and guard. I believe it’s just examples in the second bulleted list that work (as in my experimenting everything there works).
I can only suggest opening an issue in the relevant deps.
As a library writer I try to get ahead of the elixir release curve, but typically only work in earnest at the first release candidate (so now for Elixir 1.17). I suspect that’s true for other library writers too.
Not sure if this is an issue in Elixir 1.17 or not, but warnings related to Absinthe are failing the build of our project with the --warnings-as-errors flag.
As I’m sure everyone is aware, that flag usually only fails the build if the project itself contains warnings.
You probably should not have --warnings-as-errors when compiling dependencies, as you have little control over dependencies’ code. Instead I prefer to first run mix deps.compile (without --warnings-as-errors) and then mix compile --warnings-as-errors to get warning-errors only from my application code.
This is correct, --warnings-as-errors should only be failing if the warnings is emitting when compiling the project, not its dependencies.
In this case, I suspect this is because of meta programming - the library is probably generating code which gets compiled when compiling the project.
Instead I prefer to first run mix deps.compile (without --warnings-as-errors) and then mix compile --warnings-as-errors to get warning-errors only from my application code.
This should be the same as just running mix compile --warnings-as-errors, for the reason mentioned above.
Here is a very hacky way of suppressing the ubiquitous warning (bash shell) in the log output only (it will still fail warnings-as-errors compilation).
mix test 2>&1 | awk '/you must add parentheses instead/{p=0} /^$/{p=1} p'
quick hand-wavey explanation:
2> means "redirect the error output, usually called stderr
&1 refers to stdout
awk does awk things. Run man awk in your shell for more info.
NB: This redirects all warnings/errors to the stdout. Also you won’t get the nice green dots appearing 1-by-1. They will all appear at the same time (probably with no color).
