69 lines
2.3 KiB
XML
69 lines
2.3 KiB
XML
<section xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
version="5.0"
|
|
xml:id="ssec-relnotes-1.6.1">
|
|
|
|
<title>Release 1.6.1 (2013-10-28)</title>
|
|
|
|
<para>This is primarily a bug fix release. Changes of interest
|
|
are:</para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>Nix 1.6 accidentally changed the semantics of antiquoted
|
|
paths in strings, such as <literal>"${/foo}/bar"</literal>. This
|
|
release reverts to the Nix 1.5.3 behaviour.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Previously, Nix optimised expressions such as
|
|
<literal>"${<replaceable>expr</replaceable>}"</literal> to
|
|
<replaceable>expr</replaceable>. Thus it neither checked whether
|
|
<replaceable>expr</replaceable> could be coerced to a string, nor
|
|
applied such coercions. This meant that
|
|
<literal>"${123}"</literal> evaluatued to <literal>123</literal>,
|
|
and <literal>"${./foo}"</literal> evaluated to
|
|
<literal>./foo</literal> (even though
|
|
<literal>"${./foo} "</literal> evaluates to
|
|
<literal>"/nix/store/<replaceable>hash</replaceable>-foo "</literal>).
|
|
Nix now checks the type of antiquoted expressions and
|
|
applies coercions.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Nix now shows the exact position of undefined variables. In
|
|
particular, undefined variable errors in a <literal>with</literal>
|
|
previously didn't show <emphasis>any</emphasis> position
|
|
information, so this makes it a lot easier to fix such
|
|
errors.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Undefined variables are now treated consistently.
|
|
Previously, the <function>tryEval</function> function would catch
|
|
undefined variables inside a <literal>with</literal> but not
|
|
outside. Now <function>tryEval</function> never catches undefined
|
|
variables.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Bash completion in <command>nix-shell</command> now works
|
|
correctly.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Stack traces are less verbose: they no longer show calls to
|
|
builtin functions and only show a single line for each derivation
|
|
on the call stack.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>New built-in function: <function>builtins.typeOf</function>,
|
|
which returns the type of its argument as a string.</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</section>
|