cson  News

ACHTUNG: THIS PAGE IS NOW MAINTAINED IN THE NEW WIKI: http://whiki.wanderinghorse.net/wikis/cson/?page=News

cson news

Newest items are at the top...



  • Added several convenience routines to cson_cpdo for binding cson_value (JSON) objects to db columns and parsing JSON from those columns.



  • Added an on-disk-hashtable-based session manager to cson_session.


  • Added the select-to-json application.
  • Added initial support for handling form-urlencoded HTTP POST data. Seems to work.


  • Moved the cson_cgi API into the trunk. Created several different amalgamation build variants providing various levels of features.


  • The new cson_cgi API is basically functional.


  • Added cson_value_clone() to deeply copy JSON values.
  • Pulled the reference-counting code into the trunk. It is now legal for a given cson_value instance to be inserted into multiple object/array containers or into the same container multiple times, provided that no cycles are introduced (cycles are still strictly illegal). This feature costs us 4 bytes of memory per value instance (boo!) but gives us a good deal more flexibility in what we can do with cson_value instances (yeah!).


  • Started work on a branch which uses reference counting to allow value instances to be inserted multiple times into the same container or across different containers. The No Cycles rule still applies, however. This feature adds a bit of memory overhead (4 bytes/value) but should enable us to do more interesting things with the object trees. This code is currently in the with-refcount branch, and i'm not yet decided as to whether to pull it into the trunk.


  • Manuel Rülke kindly pointed out that someone (a bot) had vandalized all the wiki pages and tickets in this site. While no source code appears to have been violated, the repository has been re-built from known-clean sources.


  • Added cson_sqlite3.
  • Some of the routines, like cson_value_new() and cson_value_set_xxx(), have been removed from the public API because they are easy to mis-use (in terms of memory management) and because they make implementing certain memory allocation optimizations impossible.
  • Internal allocation optimizations have cut the total number of calls to malloc() by 20-30% for "some average test input." Certain internal constant values (e.g. true, false, null, integer 0, double 0.0, and empty strings) now internally use shared value instances. A minor optimization in the parser cuts the total number of allocations somewhat, but does not significantly change the total amount of memory allocated.
  • We no longer need to dynamically allocate integer values for platforms where (void *) is big enough to hold a cson_int_t value. This is a compile-time option defaulting to 32-bit behaviour (i.e. dynamically allocate integer values) if it cannot automatically determine (at preprocessor time) that your (void *) is big enough to hold a cson_int_t value. Interestingly, in my tests this cuts down the number of allocations compared to 32-bit builds, but it does not cut the actual amount of memory used when compared to 32-bit builds because the overhead of the larger pointer size makes such a difference on 64-bit builds.
  • Yet more optimizations in how object keys are handled saves us one allocation and 1 strcpy op, further reducing total number of allocations made during parsing by about 12-14% in my tests.
  • In total, and the above optimizations have cut malloc calls (when parsing) by about 30-40% for my tests, and total memory usage by 15-20%, compared to 36 hours ago. These results are for 64-bit builds, which might not have to dynamically allocate integers. On 32-bit platforms, or when cson is built without "large void pointer" support, that particular optimization doesn't apply.