NEWS

# 0.3.3 (11/08/2011)

  The version 0.3.3 is a bugfix release for the 0.3 branch.
  
  ## Changes summary
  
  * Fixed crash when indexing expressions;
  * Fixed two possible reads of uninitialized memory;
  * Plugged a few memory leaks;


# 0.3.2 (07/01/2011)

  The version 0.3.2 is a bugfix and enhancement release for the 0.3 branch.
  
  ## Changes summary
  
  * Fixed crash comparing arrays with other types;
  * Actually implemented array comparison;
  * Added support for string literals in expressions;
  * Fixed wrong reading of some numbers that led to parsing failure when the
    addition or subtraction operators was not surrounded by blank characters.
    This bug was introduced in version 0.3.1.


# 0.3.1 (13/11/2010)

  The version 0.3.1 is a bugfix and enhancement release for the 0.3 branch.
  
  ## Changes summary
  
  * Fixed crash in addition operator when handling arrays;
  * Improved floating-point numbers output;
  * Added support for blanks between a symbol and its index;
  * Added support for empty arrays in environment descriptions;
  
  The most interesting change of this release is probably the improved output of
  floating-points numbers. Floating point numbers always suffered from false
  precision: for example "3.14" was wrongly rendered as "3.1400000000000001".
  This problem should be fixed now.
  
  ### Internal changes that you might notice
  
  The way numbers are read has changed a little bit, now only the characters
  that forms a fully valid number are read. This may lead to a different error
  with some malformed templates -- even though there will still be an error, but
  maybe at another step of the lexing process.
  
  For example, template "{0x}" raised an error about the number lacking a
  mantissa (0x is a valid prefix for an hexadecimal value, but lacks the actual
  hexadecimal number), and now correctly read the number but raises an error
  about character "x" being unexpected.


# 0.3 (09/10/2010)

  The version 0.3 is an API and ABI break from the previous 0.2 branch.
  
  ## Changes summary
  
  * Heavy API cleanup;
  * Array expressions can now be indexed;
  * The `for` loop now iterates over an expression rather than a symbol name;
  * CtplEnviron now uses reference counting;
  * Improvements of CtplEnviron's memory usage;
  * Bug fixes:
    * ctpl_value_copy(), ctpl_value_set_string() and ctpl_value_set_array*() can
      now take a part of itself as the value to set/copy;
    * Fix internal handling of an error which may lead to wrong error detection;
    * Fix wrong name of streams built from GFiles, paths and URIs;
    * Fix dramatic slowness when a symbol gets pushed many times;
  * Some internal refactoring.
  
  Yes, it is the second API break since the library's birth, less than one year
  ago. I know it and I apologize for the inconvenience.
  
  But even if it's an API break, if you make normal usage of the library, it
  shouldn't be too painful for you to upgrade to the new version (see below).
  Many functions and data structures have been removed or made private, but the
  API that was meant to be used by final users had only small changes.
  
  I will also justify this new break, at least for you to understand the
  original motivations for it:
  * There was way too many symbols exposed, and a lot of them wasn't supposed to
    be used by library's users;
  * Exposing data structures (as well as some other internals) makes working on
    the core harder, because any change to one of this data structure means an
    API break.
  Then this new break is here to -- hopefully -- ease future improvements of
  CTPL, as well as preventing more API breaks.
  
  ## What to change in your code
  
  ### Token-related functions
  
  The functions ctpl_token_free() and ctpl_token_expr_free() lost their second
  (boolean) argument. If you passed TRUE here, simply remove that second
  argument. Otherwise, you did strange things and you're screwed (but see the
  next section).
  
  ctpl_lexer_free_tree() has also been removed, use ctpl_token_free() instead
  (the semantic is exactly the same).
  
  ### Environments
  
  CtplEnviron now uses reference counting. It means that you get all the good
  of reference counting, but you also have to replace calls to
  ctpl_environ_free() with ctpl_environ_unref(). Note that ctpl_environ_unref()
  does not support NULL argument.
  
  ctpl_environ_pop() has changed. It now takes a third argument to get the
  poped value and returns a boolean (see the documentation for more details).
  Anyway you should probably not need ctpl_environ_pop() at all.
  
  ### Input and output streams
  
  ctpl_input_stream_read_double() and ctpl_input_stream_read_long() are renamed
  to ctpl_input_stream_read_float() and ctpl_input_stream_read_int() for more
  consistency with the rest of the API.
  
  ### Others
  
  The environment to pass to ctpl_eval_*() is not constant anymore. This will
  probably not change anything for you, but it's a subtle change. This is to
  allow future operators to affect the environment if needed (which isn't the
  case yet).
  
  ## The dark side of the cleanup
  
  Apart the inconvenience of an API break, some "features" of the library may be
  gone -- yes, having many internal exposed may allow unwanted "features".
  First, know that these features weren't planned. Then, feel free to contact
  me, explaining what functionality you miss and why, and I'll probably be happy
  to re-introduce it cleanly for you.
  
  ## CLI tool changes
  
  The CLI tool, apart then new features of the template engine, gained support
  for encodings. This brings a new `--encoding` option allowing to specify the
  encoding of the input and output files. The default encoding is the system's
  one.


# 0.2.2 (25/05/2010)

  The version 0.2.2 is a bugfix release for the 0.2 branch.
  
  ## Changes summary
  
  * Fix lexing of a whole expression input (using ctpl_lexer_expr_lex() or
    one of its variants);
  * Fix priority of boolean operators AND and OR;
  * Fix support of operators <= and >=;
  * Better error reporting in the expression lexer;
  * New alternative build system: Waf (from a work by Enrico Tröger, thanks).


# 0.2.1 (27/04/2010)

  The version 0.2.1 is a bugfix release for the 0.2 branch.
  
  ## Changes summary
  
  * Do not export the private API;
  * Little cleaning of the build system.


# 0.2 (15/04/2010)
  
  The version 0.2 is an API and ABI break from the previous 0.1 branch.
  
  ## Changes summary (in-depth):
  
  ### New features and important changes
  
  * GIO replaces LibMB. Impact is:
    * Less memory usage (input template may or may not be loaded into memory);
    * Small performance regression, between 8% to 19% [1] (on extreme cases),
      measured on heavy templates;
    * Any GIO stream may be live-lexed, from local files to remote FTP, Samba,
      DAV, etc.
  * Better lexer error reporting, with line and position marks;
  * Improved numeric constants loading, including:
    * Integers are now loaded as integers, impacting:
      * No more precision loss;
      * Shorter maximum value, but still more than reasonable (C's long: in 64
        bits machines should be something like from -9223372036854775807 to
        +9223372036854775807, and -2147483647 to +2147483647 on 32 bits
        machines).
    * Support for octal and binary constants via 0o and 0b prefix respectively;
  * Improved token representation, saving about from 19% to 28% of memory use
    for the token tree (no measurable performance impact) (already in 0.1.90);
  * Add support for single-line comments in environ descriptions;
  * Fix support of array values that starts with blanks in environ descriptions;
  * `make distcheck` and out-of-tree build now work;
  * Add man page for the ctpl command-line utility.
  
  As you can see, the main improvements of this release are less memory
  consumption (about 30/40% better!) and GIO usage bringing almost universal
  input.
  
  ## Quid of the performances?
  
  Yes, we lost about 8% to 19% [1] of speed. But I decided that the gain worth
  it: GIO allows live streams to be parsed without loading them previously into
  memory, which means that the memory usage is about the same minus about the
  size of the input template.
  Since the parsing of a 140M (28366227 lines) example template took 15.9612s
  before and 17.4756s now (8.67% slower), I thought it was reasonable when we
  gained about 140M of memory. Another test (135M input, 10944000 lines) took
  11.4204s before and 13.3378s now (14.38% slower), but needed about 130M less
  memory.
  
  And still note that these are very heavy templates (yes, 11-28.4M lines!), and
  real world templates are really really smaller. And this is the lexing, which
  is done only once per template, the parsing is not impacted.
  
  Finally, note that invalid templates may be found invalid without reading the
  whole input, especially if the invalid data is at the start. This makes for
  example a 350M invalid template to be immediately (huh, about 0.009s, and this
  includes program launching) reported as invalid, and this about 99% faster
  than before (without any I/O latency).
  
  [1] note that the measurement was done with all the changes (except token tree
      optimization), which can mean that the overhead is not only due to GIO but
      to the new features too.
      Another thing to note is that this measurement always used a cached file
      input, meaning that any I/O gain or loss due not to load the whole
      template at once was not took into account; but I/O doesn't make so much
      sense since it depends heavily on the input location (even two hard drives
      might behave quite differently, depending on their speed, cache size and
      so on). But with I/O, results moves from +18.66% to -3.59% slower.


# 0.1.90 (06/04/2010)
  
  The version 0.1.90 is the last of the 0.1.x branch. It is the 0.2-minus-one
  release, with a part of the 0.1-compatible improvements that will come in the
  upcoming 0.2 branch.
  
  ## Changes summary
  
  * Improved token representation, saving about from 20% to 30% of memory use
    for the token tree (no measurable performance impact);
  * New ctpl_environ_foreach() and ctpl_environ_merge() functions;
  * Fix missing inclusion of readutils.h in the global header.


# 0.1.1 (15/03/2010)
  
  The version 0.1.1 is a bugfix release for the 0.1 branch.
  
  ## Changes summary
  
  * Fixed stack overflow with very large token trees;
  * Great speed improvement with large token trees.


# 0.1 (30/11/2009)
  
  The version 0.1 is the first release of CTPL. CTPL is a template engine
  library aiming to easily allow template parsing from C programs.