This is awesome idea! When I firstly saw related github issue I was so surprised, because I did not expect such useful change. I believe that it will simplify lots of things.
compile_time_purge_matching
I really love this. I will use it definitely in already maintained projects!
âfailed flag
It will definitely help. Fortunately my tests are really fast.
[Code] Add Code.purge_compiler_modules/0 that purges any compiler module left behind. This is useful for live systems dynamically compiling code
Added on personal TODO list for rewrite plan of ex_api library!
[IO.ANSI] Add cursor movement to IO.ANSI
Awesome! It will definitely help creating console scripts.
I will try to find a time to test those changes in this weekend. Good work!
This is generally only required if the compiler cannot automatically release the compiler modules - this is the case if the module body contain anonymous functions (because we donât know if they wenât used for spawning processes or stored somewhere). I donât think itâs required for fastglobal.
EDIT: Iâve just checked the fastglobal code and it compiles the data modules using Erlang compiler and not the elixir one, so it does not affect it in any way.
Hey @josevalim it seems that Absinthe schemas are entirely broken on the RC, Iâm trying to trace down what the root issue here, but Iâm not seeing any notable changes to macros or module attributes.
I have a __using__ macro that returns
quote do
Module.register_attribute(__MODULE__, :foo, accumulate: true)
end
which seems to be behaving differently now. If I change that call to Module.register_attribute(__CALLER__.module, :foo, accumulate: true) in the macro body it seems to work better, although that doesnât totally fix the issue.
@benwilson512 We did refactor this part of the codebase, so I will gladly take a look if you have failing tests in Absintheâs suite or a small file I can run with mix run inside Absinthe.
If you mess with that file youâll run into Bug #1 weâve actually had a while, where editing the Writer module file requires rm -rf _build or you get a compilation error for some reason.
Iâll apologize ahead of time for the complexity of the module, the schema building code is some of the oldest in Absinthe. Weâre in the middle of reworking it to be simpler and more data driven but itâs still a ways from being ready to ship.
@benwilson512 Thanks. I will investigate. You should probably consider have an optional build on Travis for Absinthe that runs on Elixir master. This way we can find this failures earlier.
So I understand the current behaviour and why accumulate did not work in previous Elixir versions.
It seems that you are calling put_definition many times before you invoke accumulate: true. If I do this:
if @absinthe_definitions do
raise "omg"
end
Module.register_attribute(__MODULE__, :absinthe_definitions, accumulate: true)
You will see that @absinthe_definitions is not nil. The behaviour of setting an attribute to accumulate after it is set is âundefinedâ. In previous versions, we were still able of keeping whatever has been accumulated (with caveats) but in the new version we discard it.
However, I would say that the previous behaviour (in earlier Elixir versions) is also broken because your put_definition would lead to a bunch of duplicated definitions. When accumulate: true is false, put_definition works fine, but when it is enabled, you would end-up getting the whole list, prepending to it, and then adding it as an entry on top of the existing list. For example, imagine you had definitions x, y and z already stored. In the attribute, they would be stored as [:z, :y, :x]. Now imagine that you add :a, at the end you will end-up with [[:a, :z, :y, :x], :z, :y, :x]. However, it seems accumulate: true is only set too late in your suite, so this doesnât happen there.
Any thoughts on the Writer module issue? Iâve hesitated to create an Elixir error before because I couldnât reproduce it outside the Absinthe project.
Folks, please let us know if you tried the release candidate and if everything is fine. Even if you found no regressions, say so in the comments, otherwise we canât know if everyone is quiet because nobody tried it yet or if because nobody found bugs. Hoping for the latter.
The Meeseeks tests run fine using the RC and OTP21.
Edit: And a larger Phoenix 1.2 project with a bunch of deps also runs its tests fine (RC and OTP21), though it did complain that I shouldnât use length(res) > 0 in my tests.
Seems to work with Caravan and a Phoenix 1.3 app that we have. My Phoenix project using Abinsthe wonât compile for what l assume are the reasons that Ben mentioned.
I just tried it on a project of mine and found it to not work with ex_cldr's compiler task:
could not compile dependency :ex_cldr_dates_times, "mix compile" failed. You can recompile this dependency with "mix deps.compile ex_cldr_dates_times", update it with "mix deps.update ex_cldr_dates_times" or clean it with "mix deps.cleanex_cldr_dates_times"
** (FunctionClauseError) no function clause matching in Mix.Dep.loaded/1
The following arguments were given to Mix.Dep.loaded/1:
# 1
[env: :prod]
Attempted function clauses (showing 1 out of 1):
def loaded([])
(mix) lib/mix/dep.ex:156: Mix.Dep.loaded/1
lib/mix/tasks/compile.cldr.ex:86: Mix.Tasks.Compile.Cldr.compile_cldr_files/0
lib/mix/tasks/compile.cldr.ex:67: Mix.Tasks.Compile.Cldr.run/1
(mix) lib/mix/task.ex:316: Mix.Task.run_task/3
(mix) lib/mix/tasks/compile.all.ex:68: Mix.Tasks.Compile.All.run_compiler/2
(mix) lib/mix/tasks/compile.all.ex:52: Mix.Tasks.Compile.All.do_compile/4
(mix) lib/mix/tasks/compile.all.ex:23: anonymous fn/1 in Mix.Tasks.Compile.All.run/1
(mix) lib/mix/tasks/compile.all.ex:39: Mix.Tasks.Compile.All.with_logger_app/1