1. Bug fixes

Elixir

• [Code] Ignore tracers if lexical tracker is dead or explicitly nil when evaling code with an environment
• [GenServer] Do not show warning when using super in GenServer.child_spec/1
• [Kernel] Do not crash when :reduce is set to nil in comprehensions
• [Kernel] Fix a scenario where undefined function warnings were not being emitted

IEx

• [IEx.Helpers] Properly handle tags inside typespec when showing Erlang docs

Logger

• [Logger] Do not deadlock Logger if handler crashes on sync mode

Mix

• [Mix] Add inet6 fallback to Mix usage of httpc
• [mix compile.app] Do not list apps that do not match the current target

Checksums

• Precompiled.zip SHA1: f03301dd10072f3643a4c1e5f012a49bfc493608
• Precompiled.zip SHA512: c70e7d3e338ab2449301c7864a2dd96e8d474f3fee533a66706c67cd733db74c2d529b9887961db9f07530eeed4cce917c480e5e8c4201060c7fa494e8b376da
• Docs.zip SHA1: b4045584e5dddc01202bcbd0f4ff0623b3a37958
• Docs.zip SHA512: 9e8d5467b37588c3a885b4745e014fffe91a72194fc076ccaf4abee4bd08c48792d0d89fd3fa16f0d3d10739e0c6d2213e07bfa51bd50ebcad6d74fbad79277b

Over the last releases, the Elixir team has been focusing on the compiler, both in terms of catching more mistakes at compilation time and making it faster. Elixir v1.11 has made excellent progress on both fronts. This release also includes many other goodies, such as tighter Erlang integration, support for more guard expressions, built-in datetime formatting, and other calendar enhancements.

Tighter Erlang integration

Following Elixir v1.10, we have further integrated with Erlang's new logger by adding four new log levels: notice, critical, alert, and emergency, matching all log levels found in the Syslog standard. The Logger module now supports structured logging by passing maps and keyword lists to its various functions. It is also possible to specify the log level per module, via the Logger.put_module_level/2 function. Log levels per application will be added in future releases.

IEx also has been improved to show the documentation for Erlang modules directly from your Elixir terminal. This works with Erlang/OTP 23+ and requires Erlang modules to have been compiled with documentation chunks.

Compiler checks: application boundaries

Elixir v1.11 builds on top of the recently added compilation tracers to track application boundaries. From this release, Elixir will warn if you invoke a function from an existing module but this module does not belong to any of your listed dependencies.

These two conditions may seem contradictory. After all, if a module is available, it must have come from a dependency. This is not true in two scenarios:

• Modules from Elixir and Erlang/OTP are always available - even if their applications are not explicitly listed as a dependency

• In an umbrella project, because all child applications are compiled within the same VM, you may have a module from a sibling project available, even if you don't depend on said sibling

This new compiler check makes sure that all modules that you invoke are listed as part of your dependencies, emitting a warning like below otherwise:

:ssl.connect/2 defined in application :ssl is used by the current application but the current application does not directly depend on :ssl. To fix this, you must do one of: 1. If :ssl is part of Erlang/Elixir, you must include it under :extra_applications inside "def application" in your mix.exs 2. If :ssl is a dependency, make sure it is listed under "def deps" in your mix.exs 3. In case you don't want to add a requirement to :ssl, you may optionally skip this warning by adding [xref: [exclude: :ssl] to your "def project" in mix.exs 

This comes with extra benefits in umbrella projects, as it requires child applications to explicitly list their dependencies, completely rejecting cyclic dependencies between siblings.

Compiler checks: data constructors

In Elixir v1.11, the compiler also tracks structs and maps fields across a function body. For example, imagine you wanted to write this code:

def drive?(%User{age: age}), do: age >= 18 

If there is either a typo on the :age field or the :age field was not yet defined, the compiler will fail accordingly. However, if you wrote this code:

def drive?(%User{} = user), do: user.age >= 18 

The compiler would not catch the missing field and an error would only be raised at runtime. With v1.11, Elixir will track the usage of all maps and struct fields within the same function, emitting warnings for cases like above:

warning: undefined field `age` in expression: # example.exs:7 user.age expected one of the following fields: name, address where "user" was given the type %User{} in: # example.exs:7 %User{} = user Conflict found at example.exs:7: Check.drive?/1 

The compiler also checks binary constructors. Consider you have to send a string over the wire with length-based encoding, where the string is prefixed by its length, up to 4MBs. Your initial attempt may be this:

def run_length(string) when is_binary(string) do <<byte_size(string)::32, string>> end 

However, the code above has a bug. Each segment given between <<>> must be an integer, unless specified otherwise. With Elixir v1.11, the compiler will let you know so:

warning: incompatible types: binary() !~ integer() in expression: <<byte_size(string)::integer()-size(32), string>> where "string" was given the type integer() in: # foo.exs:4 <<byte_size(string)::integer()-size(32), string>> where "string" was given the type binary() in: # foo.exs:3 is_binary(string) HINT: all expressions given to binaries are assumed to be of type integer() unless said otherwise. For example, <<expr>> assumes "expr" is an integer. Pass a modifier, such as <<expr::float>> or <<expr::binary>>, to change the default behaviour. Conflict found at foo.exs:4: Check.run_length/1 

Which can be fixed by adding ::binary to the second component:

def run_length(string) when is_binary(string) do <<byte_size(string)::32, string::binary>> end 

While some of those warnings could be automatically fixed by the compiler, future versions will also perform those checks across functions and potentially across modules, where automatic fixes wouldn't be desired (nor possible).

Compilation time improvements

Elixir v1.11 features many improvements to how the compiler tracks file dependencies, such that touching one file causes less files to be recompiled. In previous versions, Elixir tracked three types of dependencies:

• compile time dependencies - if A depends on B at compile time, such as by using a macro, whenever B changes, A is recompiled
• struct dependencies - if A depends on B's struct, whenever B's struct definition changed, A is recompiled
• runtime dependencies - if A depends on B at runtime, A is never recompiled

However, because dependencies are transitive, if A depends on B at compile time and B depends on C at runtime, A would depend on C at compile time. Therefore, it is very important to reduce the amount of compile time dependencies.

Elixir v1.11 replaces "struct dependencies" by "exports dependencies". In other words, if A depends on B, whenever B public's interface changes, A is recompiled. B's public interface is made by its struct definition and all of its public functions and macros.

This change allows us to mark imports and requires as "exports dependencies" instead of "compile time" dependencies. This simplifies the dependency graph considerably. For example, in the Hex.pm project, changing the user.ex file in Elixir v1.10 would emit this:

$ touch lib/hexpm/accounts/user.ex && mix compile Compiling 90 files (.ex) 

In Elixir v1.11, we now get:

$ touch lib/hexpm/accounts/user.ex && mix compile Compiling 16 files (.ex) 

To make things even better, Elixir v1.11 also introduces a more granular file tracking for path dependencies. In previous versions, a module from a path dependency would always be treated as a compile time dependency. This often meant that if you have an umbrella project, changing an application would cause many modules in sibling applications to recompile. Fortunately, Elixir v1.11 will tag modules from dependencies as exports if appropriate, yielding dramatic improvements to those using path dependencies.

To round up the list of compiler enhancements, the --profile=time option added in Elixir v1.10 now also includes the time to compile each individual file. For example, in the Plug project, one can now get:

[profile] lib/plug/conn.ex compiled in 935ms [profile] lib/plug/ssl.ex compiled in 147ms (plus 744ms waiting) [profile] lib/plug/static.ex compiled in 238ms (plus 654ms waiting) [profile] lib/plug/csrf_protection.ex compiled in 237ms (plus 790ms waiting) [profile] lib/plug/debugger.ex compiled in 719ms (plus 947ms waiting) [profile] Finished compilation cycle of 60 modules in 1802ms [profile] Finished group pass check of 60 modules in 75ms 

While implementing those features, we have also made the --long-compilation-threshold flag more precise. In previous versions, --long-compilation-threshold would consider both the time a file spent to compile and the time spent waiting on other files. In Elixir v1.11, it considers only the compilation time. This means less false positives and you can now effectively get all files that take longer than 2s to compile by passing --long-compilation-threshold 2.

mix xref graph improvements

To bring visibility to the compiler tracking improvements described in the previous section, we have also added new features to mix xref. mix xref is a task that describes cross-references between files in your projects. The mix xref graph subsection focuses on the dependency graph between them.

First we have made the existing --label flag to consider transitive dependencies. Using --sink FILE and --label compile can be a powerful combo to find out which files will change whenever the given FILE changes. For example, in the Hex.pm project, we get:

$ mix xref graph --sink lib/hexpm/accounts/user.ex --label compile lib/hexpm/billing/hexpm.ex └── lib/hexpm/billing/billing.ex (compile) lib/hexpm/billing/local.ex └── lib/hexpm/billing/billing.ex (compile) lib/hexpm/emails/bamboo.ex ├── lib/hexpm/accounts/email.ex (compile) └── lib/hexpm/accounts/user.ex (compile) lib/hexpm/emails/emails.ex └── lib/hexpm_web/views/email_view.ex (compile) lib/hexpm_web/controllers/api/docs_controller.ex └── lib/hexpm_web/controllers/auth_helpers.ex (compile) lib/hexpm_web/controllers/api/key_controller.ex └── lib/hexpm_web/controllers/auth_helpers.ex (compile) lib/hexpm_web/controllers/api/organization_controller.ex └── lib/hexpm... 

Checksums

• Precompiled.zip SHA1: 5d70b6254d7a89930e09c85718d99deddd186092
• Precompiled.zip SHA512: bc2bb21b5dd8fadc8bbd9b53ba676e31af3b13fcaca776ee0b461acef55964ee453fb7e1e95cc3c4bbfd12d6cd68c02034cc104597e18047a574d484eb64cd52
• Docs.zip SHA1: df47a509caafa9b99c1d4bdf5fae6bdccce3f32b
• Docs.zip SHA512: 0372f7a8ed98044c7cce4d5b690373abec81818c3e6790543653675f2359131d6ba485921e8f30cafc660f8849525383a175e1c4eeb7707c47986792e7616e4f

1. Bug fixes

Elixir

• [Kernel] Fix a bug where custom types were printed as built-in types
• [Kernel] Don't add compile-time dependency on defdelegate
• [Kernel] Add line numbers to warnings on deprecated imports
• [Kernel] Report the correct line number when raising inside a macro
• [Task] Include callers in translated Logger metadata for Task
• [Task] Fix Task PID and caller in Task Supervisor reports

ExUnit

• [ExUnit.Formatter] Avoid crashes when diffing guards when the pattern does not match
• [ExUnit.Formatter] Also blame exceptions that come from linked and trapped exits

IEx

• [IEx.Helpers] Do not crash when printing a type that cannot be code formatted

Mix

• [mix app.start] Fix reading .app file located in archives (.ez files)
• [mix local.hex] Provide more guidance when Hex can't be installed
• [mix release] Properly encode config in releases

Checksums

• Precompiled.zip SHA1: 5b400c829c4f239ac89a7eb97aac642b961f38fd
• Precompiled.zip SHA512: 9727ae96d187d8b64e471ff0bb5694fcd1009cdcfd8b91a6b78b7542bb71fca59869d8440bb66a2523a6fec025f1d23394e7578674b942274c52b44e19ba2d43
• Docs.zip SHA1: 178f08724c63496878b6e427467f650f03cd978c
• Docs.zip SHA512: cefaf0371a9751d37d6d1181f910a23d6cc627f7b77fe7fa1b303a9b4769d1fb2a9bbeea54566109fa5acf8e0455a5a44cb3ac9ccb9e968d92610b869d15d27c

1. Bug fixes

Elixir

• [Code] Return [{mod, bin}] from Code.compile_file/2, Code.require_file/2, Code.load_file/2
• [Code] Make sure the formatter respects newlines before and after module attributes
• [Kernel.ParallelCompiler] Fix a bug where the parallel compiler would raise in long compilation cycles
• [Kernel.ParallelCompiler] Fix a bug where the parallel compiler would raise if some of the modules being compiled referred to a module that has been loaded directly to memory
• [Module] Fix accidental breaking change where bodiless clauses had their body value on @on_definition callbacks set to an empty list instead of nil
• [String] Undeprecate String.normalize/2 normalize and fix infinite loop caused by certain invalid strings

ExUnit

• [ExUnit.Assertions] Fix pattern matching diff when matching on pinned variables
• [ExUnit.Assertions] Fix pattern matching diff when matching variable struct names
• [ExUnit.Assertions] Fix pattern matching diff when matching on the binary concat operator (<>) and the left side is not a literal string
• [ExUnit.Assertions] Fix pattern matching diff when matching on pseudo-vars (__MODULE__, __DIR__, etc)

Mix

• [mix release] Respect the :path option when creating a :tar file for releases

Checksums

• Precompiled.zip SHA1: 382fa22e6f184c0cc87fcfbfa0053c349d85f6f1
• Precompiled.zip SHA512: fc6d06ad4cc596b2b6e4f01712f718200c69f3b9c49c7d3b787f9a67b36482658490cf01109b0b0842fc9d88a27f64a9aba817231498d99fa01fa99688263d55
• Docs.zip SHA1: e417c3849bbc0371e805b3265dbbb21e3ef02d3f
• Docs.zip SHA512: 6ffb0376701570fc06ecc801c8151deec700b8636278834c0e3b06798418193da916e99de9644239347d5239915b2161e17d6a155723551d82eb212592adb9bf

1. Bug fixes

Elixir

• [Macro] Fix a bug where Macro.to_string/1 would emit invalid code for sigils
• [Task] Do not crash async_stream monitor if it receives spurious DOWN messages

Logger

• [Logger] Fix a bug where the Logger formatter would fail when handling unknown metadata values

Mix

• [mix compile] Do not write files to disk if --warnings-as-errors was given and warnings were emitted

Checksums

• Precompiled.zip SHA1: 830264881231e711d8bade711ed2819a2d10b918
• Precompiled.zip SHA512: 532f43f08a29b5cbfca5a544c337b4a6d336d372ba0a5b3393681426d57ecaa85960e8eb3548aea26f213cc36914c6b66b83707cd719e27dc34c40efadb9f0b9
• Docs.zip SHA1: cca85f8f2dec9adbc52022d4666dd01bd0793424
• Docs.zip SHA512: c485dd315113cc13509bf47b4992f9e1825d433f5f5c923f22c792b100afa09e42ee7975c93c8d585bf58fce1713b50864c1fde829feda3c361335357b9b10ae

1. Bug fixes

Elixir

• [Code] Do not emit invalid code when formatting nil, false, and true keys in maps
• [Kernel] Ensure with clauses properly unpack "implicit guards" (such as matching on the struct name)
• [Kernel] Do not warn if commas are used by themselves in ~w/~W sigils
• [Kernel] Do not validate the :line option in quote (the validation has been moved to v1.11 to give users more time to update their code)
• [Module] Ensure the code verifier handles the :erlang.size/1 guard properly

Logger

• [Logger] Properly handle the report_cb/2 option from Erlang
• [Logger] Fix truncation for multi-byte characters
• [Logger] Do not rebroadcast messages from remote nodes as this is now taken care by Erlang's logger

ExUnit

• [ExUnit] Ensure assert_receive produces valid exception messages in case of errors

Mix

• [mix release] Make sure the install command (Window specific) works on paths with spaces in the name
• [mix release] Allow using remote and rpc commands with Application.compile_env/3

Checksums

• Precompiled.zip SHA1: 606ffaff6c7c3d278d7daa1fee653aa8183f225f
• Precompiled.zip SHA512: e8809aff909ca6e2271493690a6a095959e551f6d04e2d384ead0d6cfde23a3707492b53563b9a78080509b44728a63645dc37be108cd6ea3f9501f5d616fe1d
• Docs.zip SHA1: bb050e0b56a2d32562f7c876f8eed53846b857fe
• Docs.zip SHA512: be8ffec17cd15a439f78857eee615793d4d22a9b38b34df94d8546bb0f0b5745974115337cadcefebc82feef62d6f2d5a19f50f563f4efc9c9e4543815ccf85b

Support for Erlang/OTP 21+

Elixir v1.10 requires Erlang/OTP 21+, allowing Elixir to integrate with Erlang/OTP's new logger. Currently, this means that the logger level, logger metadata, as well as all log messages are now shared between Erlang and Elixir APIs.

We will continue improving the relationship between the logging systems in future releases. In particular, we plan to expose all log levels and runtime filtering functionalities available in Erlang directly into Elixir in the next Elixir version.

This release also adds two new guards, is_struct/1 and is_map_key/2, thanks to the strict requirement on Erlang/OTP 21+.

Releases improvements

Elixir v1.9 introduced releases as a mechanism to package self-contained applications. Elixir v1.10 further improves releases with bug fixes and new enhancements based on feedback we got from the community. The highlights are:

• Allow the dual boot system of releases to be disabled on environments that are boot-time sensitive, such as embedded devices

• Track and raise if compile-time configuration is set or changes at runtime (more in the next section)

• Support for easily adding extra files to releases via overlays

• Allow RELEASE_DISTRIBUTION to be set to none in order to fully disable it

• Add a built-in :tar step that automatically packages releases

See the full CHANGELOG for more improvements.

Improvements to sort-based APIs in Enum

Enum.sort/1 in Elixir by default sorts from lowest to highest:

iex> Enum.sort(["banana", "apple", "pineapple"]) ["apple", "banana", "pineapple"]

If you want to sort from highest to lowest, you need to call Enum.sort/2 with a custom sorting function, such as Enum.sort(collection, &>=/2), which is not immediately obvious to someone reading the code:

iex> Enum.sort(["banana", "apple", "pineapple"], &>=/2) ["pineapple", "banana", "apple"]

Furthermore, comparison operators, such as <= and >=, perform structural sorting, instead of a semantic one. For example, using >= to sort dates descendingly won't yield the correct result:

iex> Enum.sort([~D[2019-12-31], ~D[2020-01-01]]) [~D[2020-01-01], ~D[2019-12-31]]

To perform proper semantic comparison for dates, one would also need to pass a custom sorting function:

iex> Enum.sort([~D[2019-12-31], ~D[2020-01-01]], &(Date.compare(&1, &2) != :lt)) [~D[2019-12-31], ~D[2020-01-01]]

Elixir v1.10 streamlines the sorting functions by introducing both :asc and :desc shortcuts:

iex> Enum.sort(["banana", "apple", "pineapple"], :asc) ["apple", "banana", "pineapple"] iex> Enum.sort(["banana", "apple", "pineapple"], :desc) ["pineapple", "banana", "apple"]

As well as adding the possibility to pass a module to perform semantic comparisons. For example, to sort dates, one now only needs to pass the Date module or even {:desc, Date} for descending semantical sort:

iex> Enum.sort([~D[2019-12-31], ~D[2020-01-01]], Date) [~D[2019-12-31], ~D[2020-01-01]] iex> Enum.sort([~D[2019-12-31], ~D[2020-01-01]], {:desc, Date}) [~D[2020-01-01], ~D[2019-12-31]]

These API improvements make the code more concise and readable and they have also been added to Enum.sort_by, Enum.min_by, Enum.max_by, and friends.

Tracking of compile-time configuration

In Elixir, we organize our code in applications. Libraries, your dependencies, and your own project are all separate applications. All applications in Elixir also come with an application environment.

The application environment is a key-value store that allows us to configure said application. While reading the application environment at runtime is the preferred approach, in some rare occasions you may want to use the application environment to configure the compilation of a certain project. This is often done by calling Application.get_env/3 outside of a function:

defmodule MyApp.DBClient do @db_host Application.get_env(:my_app, :db_host, "db.local") def start_link() do SomeLib.DBClient.start_link(host: @db_host) end end

This approach has one big limitation: if you change the value of the application environment after the code is compiled, the value used at runtime is not going to change! For example, if you are using mix release and your config/releases.exs has:

config :my_app, :db_host, "db.production" 

Because config/releases.exs is read after the code is compiled, the new value will have no effect as the code was compiled to connect to "db.local".

Of course, the obvious solution to this mismatch is to not read the application environment at compilation time in the first place, and instead move the code to inside a function:

defmodule MyApp.DBClient do def start_link() do SomeLib.DBClient.start_link(host: db_host()) end defp db_host() do Application.get_env(:my_app, :db_host, "db.local") end end

While this is the preferred approach, there are still two scenarios we need to address:

1. Not everyone may be aware of this pitfall, so they will mistakenly read the application environemnt at compile-time, until they are bitten by this behaviour

2. In rare occasions, you trully need to read the application environment at compile-time, and you want to be warned when you try to configure at runtime something that is valid only at compilation time

Elixir v1.10 aims to solve these two scenarios by introducing a Application.compile_env/3 function. For example, to read the value at compile time, you can now do:

@db_host Application.compile_env(:my_app, :db_host, "db.local")

By using compile_env/3, Elixir will store the values used during compilation and compare them with the runtime values whenever your system starts, raising an error in case they differ. This helps developers ensure they are running their production systems with the configuration they intend to.

In future versions, we will deprecate the use Application.get_env at compile-time with a clear message pointing users to configuration best practices, effectively addressing the scenario where users read from the application environment at compile time unaware of its pitfalls.

Compiler tracing

This release brings enhancements to the Elixir compiler and adds new capabilities for developers to listen to compilation events.

In previous Elixir versions, Elixir would compile a database of cross references between modules (such as function calls, references, structs, etc) for each project in order to perform all kinds of checks, such as deprecations and undefined functions.

Although this database was not public, developers would still use it to run their own checks against their projects. With time, developers would request more data to be included in the database, which was problematic as Elixir itself did not have a use for the additional data, and the database was not meant to be used externally in the first place.

In Elixir v1.10, we have addressed these problems by introducing compiler tracing. The compiler tracing allows developers to listen to events as they are emitted by the compiler, so they can store all of the information they need - and only the information they need.

Elixir itself is using the new compiler tracing to provide new functionality. One advantage of this approach is that developers can now disable undefined function warnings directly on the callsite. For example, imagine you have an optional dependency which may not be available in some cases. You can tell the compiler to skip warning on calls to optional modules with:

@compile {:no_warn_undefined, OptionalDependency} defdelegate my_function_call(arg), to: OptionalDependency 

Previously, this information had to be added to the overall project configuration, which was far away from where the optional call effectively happened.

Other enhancements

Elixir's calendar data types got many improvements, such as sigil support for third-party calendars, as well as the additions of DateTime.now!/2, DateTime.shift_zone!/3, and NaiveDateTime.local_now/0.

There are many improvements related to Elixir's AST in this release too. First of all, Code.string_to_quoted/2 has two new options, :token_metadata and :literal_encoder, that give more control over Elixir's parser. This information was already available to the Elixir code formatter and has now been made public. We have also extensively documented all of Elixir's AST metadata. These changes alongside compiler tracing means static analyzers and IDE integrations have a better foundation to analyze the source code.

ExUnit, our test framework, ships two small but important improvements: ExUnit.CaptureIO can now be used by tests that run concurrently and we have added "pattern-matching diffing". To understand the last feature, take this code:

assert %{"status" => 200, "body" => %{"key" => "foo"}} = json_payload

Now imagine that json_payload is a large JSON blob and the "key" inside the "body" did not have value of "foo". In previous Elixir versions, if the assertion failed, Elixir would print the right side and let you up to your own devices to figure out what went wrong. In Elixir v1.10, we diff the data structure against the pattern so you can see exactly which parts of the data matched the pattern and which ones did not. Note ExUnit already performed diffing when comparing data types, this new version adds diffing when matching data agaainst a pattern.

CHANGELOG

1. Enhancements

Elixir

• [Application] Add Application.compile_env/3 and Application.compile_env!/2 for reading values at compilation time and tracking if they accidentally change during runtime
• [Calendar] Allow custom calendar representations in calendar sigils
  ...

Checksums

• Precompiled.zip SHA1: ed80d00c3d805da50787f8dd9d0d02acf6ae5668
• Precompiled.zip SHA512: b878d802c9ad9d9d8ee2493c653d4e5335f68fce2c237e0e5c13c2af0c8855eb6219842b480b794fc3076606a4832c90932bed8262ce4c0164f5af6756f26997
• Docs.zip SHA1: c6fac84cca76c6ff9450e9dfc305e1db24ecee75
• Docs.zip SHA512: 3e4eaa181ab9cd002ff0dbdd4790a630e422fcbfd35d0fe10987bfac0ffa8ceeda313e1c06381063426ba02a63b44f959c5e4151663dcdd612e77a68a06888fa

1. Bug fixes

Mix

• [mix local.hex] Remove invalid deprecation warning on mix local.hex command

Checksums

• Precompiled.zip SHA1: ec4c7d15b28373b8fd7025b4502b7f2036229f20
• Precompiled.zip SHA512: f86170bde3b3ad3d1365f34f77ab9cb424c4638a4067fd7d509787c03dea0d40061ef1a2c8d1d9e42bec65b8cda8c1bf32801e4712531eeaef50e0cd53ac2369
• Docs.zip SHA1: 3c7496c77c9ce303d1b9eceb036ec2e8154f6347
• Docs.zip SHA512: b7f9efad208e52432302a04799a66f10ea217ecc01eae056c1204e17cc5ce232780c1b9c8b50a33004b180f1bc51a86b9de5ef8502c1428e9c2b50050f0ebe60