Elixir v1.7.0-rc.0 released

Ahh yes this makes sense, thanks for explaining, I was able to fix the issues via: https://github.com/absinthe-graphql/absinthe/commit/8c622942364c585e30d2ef03256a9a7103861e7d

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.

1 Like

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. :slight_smile:

4 Likes

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. :smiley:

2 Likes

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.

2 Likes

I tested it with Conduit. I had to fix a warning related to System.stacktrace(). I was doing the equivalent of:

def try_a_thing do
  # something might fail
rescue error ->
  log_error(error)
end

def log_error(error) do
  Exception.format(:error, error, System.stracktrace())
  |> Logger.error()
end

Which I changed to:

def try_a_thing do
  # something might fail
rescue error ->
  log_error(error, System.stracktrace())
end

def log_error(error, stacktrace) do
  Exception.format(:error, error, stracktrace)
  |> Logger.error()
end

Otherwise everything was fine.

2 Likes

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

Seems like the function is deprecated: @kip

@LostKobrakai Mix.Dep.loaded/1 was private API, so folks should not be invoking it in the first place. :slight_smile:

EDIT: I have added it back with a warning but it will be removed in the future.

I have an application that doesn’t want to start:

13:41:22.543 [info]  Application schema exited: Schema.Application.start(:normal, []) returned an error: shutdown: failed to start child: Schema.Repo
    ** (EXIT) exited in: GenServer.call(Ecto.Registry, {:associate, #PID<0.356.0>, {Schema.Repo, Schema.Repo.Pool, [name: Schema.Repo.Pool, otp_app: :schema, repo: Schema.Repo, timeout: 15000, pool_timeout: 5000, adapter: Ecto.Adapters.Postgres, database: "argus_dev", username: "postgres", password: "secret", hostname: "localhost", pool_size: 10, pool: DBConnection.Poolboy]}}, 5000)
        ** (EXIT) no process: the process is not alive or there's no process currently associated with the given name, possibly because its application isn't started
** (Mix) Could not start application schema: Schema.Application.start(:normal, []) returned an error: shutdown: failed to start child: Schema.Repo
    ** (EXIT) exited in: GenServer.call(Ecto.Registry, {:associate, #PID<0.356.0>, {Schema.Repo, Schema.Repo.Pool, [name: Schema.Repo.Pool, otp_app: :schema, repo: Schema.Repo, timeout: 15000, pool_timeout: 5000, adapter: Ecto.Adapters.Postgres, database: "argus_dev", username: "postgres", password: "secret", hostname: "localhost", pool_size: 10, pool: DBConnection.Poolboy]}}, 5000)
        ** (EXIT) no process: the process is not alive or there's no process currently associated with the given name, possibly because its application isn't started

Schema is a path dependency. The weird thing is that I have an other application that also has a dependency on Schema and that one works fine.

Not much info here, except the above error, so not sure if this is an issue, but because I have an other application that does start and switching back to 1.6.6 fixes things, it might be an issue with rc?

This does not look like an issue with Elixir 1.7. The error is most likely caused by the :ecto application not being started before starting repos.

Thanks for giving the RC a try. Is this an umbrella app or a path dependency? Because we have found a bug in them: https://github.com/elixir-lang/elixir/pull/7931.

It’s a path dependency and it looks indeed like that bug. Thanks

I gave 1.7 RC.0 a try with one of our projects. It’s an umbrella app with 3 apps and a phoenix UI app. (Total of 4 in the apps directory.) Tests are all failing with an exception like:

     ** (ArgumentError) argument error
     code: |> D.exceeded_items(
     stacktrace:
       (stdlib) :ets.lookup(:tzdata_current_release, :release_version)
       (tzdata) lib/tzdata/release_reader.ex:47: Tzdata.ReleaseReader.current_release_from_table/0

I tried both erlang 21.0.3 and 20.3. The project works fine under elixir 1.6.6.

I thought it might be an apps startup order issue since my tests were failing with a different ets.lookup call and as long as I do an Application.ensure_started so the ets table has a value that ets.lookup call succeeds. Maybe the issue is that ets.lookup throws an ArgumentError exception if the table doesn’t exist rather than returning :undefined?

Sorry, I’m guessing a little.

I have tried my job application and, apart from the expected warnings, everything seems to work properly. The tests are passing and I can not find any errors.
The compilation times also seem to improve. Running time mix compile --force has gone from about 32s to 24s.

Great job and congratulations to the core team, this release looks wonderful :raised_hands:

1 Like

Hi @baldmountain, thanks for giving the RC a try. We have found a regression with umbrellas and I believe you have ran into it. We shall release a new RC tomorrow with a fix.

That’s nice to hear! Did you upgrade just the Elixir version or something else? We did optimize the compiler in some places but we were not expecting such a big improvement. :slight_smile:

My home server was updated to OTP 21 and Elixir 1.7 and I updated the things I’m running on it without much issue, they use ProtocolEx, Meeseeks, and a few other odd things without issue as well. The dependencies are a lot more noisy with warnings upon compilation though, which all seem legit so should be fixed. ProtocolEx had an interesting state where the compiler would not detect a module that definitly exists (seemed like an ordering issue?), but changing a seemingly unrelated line of code fixed it (and putting it back caused it again, and since it didn’t need to belong there and I could move it, then I moved it), and the issue persisted onto 2 different machines with fresh git clone’s and then I tested it with Elixir 1.6 and the issue was there too, so I have no clue what was happening (feel free to check the recent ProtocolEx commit’s, one is marked that it doesn’t work in 1.7, it was that commit that didn’t work on 1.6 or 1.7 on multiple machines here if you are curious as to why the compiler had some kind of ordering issue), but as that ended up not being a 1.7 issue I didn’t report it, and been too busy to start digging in to it to make a PR.

I’ve also updated to OTP 21, which seems to provide the other part of the compilation improvements. Updating Elixir only reduced the compilation time to about 29s, and updating OTP 21 reduced them further to only 24s.

Overall I am really happy since we have some nasty module interdependencies that sometimes trigger the recompilation of many files. I am looking into it, but in the meantime with these compilation speed improvements there should reduce the inconveniences on development.

Cheers! :sunflower:

1 Like

@LostKobrakai Mix.Dep.loaded/1 is not in the RC, but it is in master. And as you say, its deprecated. It looks like it might be in the next RC but of course José and team are right to note it was never public API.

I will finish up a workaround today.

I need to push harder to get Cldr version 2.0 done since that removes the need for the compiler (which itself is just a workaround for a poor design choice in 1.x).

Of course the immediate workaround is to not use the Cldr compiler and to manually force recompile ex_cldr and any of its “relatives”.

1 Like

Updated ex_cldr to support Elixir 1.7.0-rc.0.

2 Likes

Thanks everyone for the feedback!

A new RC is out: Elixir v1.7.0-rc.1 is out

In case no new regressions are found, v1.7.0 should be out on July 25th.

2 Likes