lix/doc/manual/release-notes/rl-1.6.1.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 (October 28, 2013)</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>