* core/khash.h: the last malloc departs.

* core/pn-gram.y: allow a newline or separator before a square bracket.

* core/string.c: fixing the `at` method to use `slice`. a bug when using strings as functions.

* core/gc.c: two bugs found in the new table code. first, hashes weren't being checked for forwarding pointers in the gc. second, the string table wasn't being updated with its new pointer. with these changes in place, my rigorous test of table allocation is passing.

* core: hi, everybody. this work i'm checking in surrounds the representation of hash tables in memory. i'm trying to squeeze down the size they take up. potion has three different types of hash tables: the basic table, the method table, and the strings table. this is the last object structure to be moved into gc (there are only two small malloc calls left in Potion.) previously, a basic hash table would take up 48 bytes of overhead on 64-bit. in addition, the table object was split into two parts: the immutable table object and a mutable table array. with this code, the table overhead is 24 bytes and the objects are combined. this means every table object is mutable and will move about in memory (like lists already do.) the total cost of a hashtable is now: 24 bytes + 4 bytes for every 16 pairs + each pair (8 bytes * 2). for comparison, a list is 16 bytes + each item (8 bytes).

* core/vm-x86.c: incorrect jump on x86.

* core: trying out a change of object hashing. got this idea from steve dekorte's blog. <http://www.dekorte.com/blog/blog.cgi?do=item&id=4003> mostly i'm just trying to hold off from writing hash functions for every individual class type. it incurs a 4 byte hit per object on 32-bit, so i'm not sure if it's permanent yet.

* test/closures/upvals.pn: test use of setlocal with non-upvals.

* core: removing use of PN_FWEAK. it's an optimization that's rare and complicates the stack scanner and the VM. anyway, turns out the JIT code is slightly simplified this route.

* README: pathos.

* core/gc.c: when an aged object is reallocated, a forwarding pointer will be left in its place and noted behind the write barrier. during a minor cycle, potion needs to rewrite the forwarding pointer. the write barrier isn't checked during a major cycle, but code is here to rewrite during a major cycle anyway.

* INTERNALS: describing the movement of objects in potion's gc. accounting the object overhead of some types.

* test/api/gc-bench.c: test allocation of a smaller self-populated tree, ensuring memory from the first test is automatically released.

* test/api/potion-test.c: fix stack scan test to skip forwarded pointers and copies.

* core/gc.c: due to reuse of memory pages and old pointers (or temporary pointers to an object's insides) hanging around the stack, do a type check only during the stack scanning phase. since i'm not keeping an index of all the allocations, i'm going to combine this with some stack wiping (and perhaps storing vtable pointers directly in PNObject.vt in the future) to be sure strange pointers are ignored.

* core/gc.c: clearing page pointers on the stack, to be sure they don't get caught during scanning. (since some old variables often end up laying around the stack.)

* core/gc.c: a count-only phase for the gc, just to give back the number of allocations in the birth region.

* core/gc.c: handle only pointers on the stack which are within potion's pages. be strict about not copying PNFwd pointers.

* core/gc.c: major collection was running first due to small size of initial old region. stack marking wasn't working because of IS_NEW_PTR check. old region pages were getting release in the stackmarking phase because the old_cur pointer was IN_OLD_REGION. gave the old_cur and birth_cur pointers slight padding to compensate for this.

* core/internal.h: O_BINARY used only under mingw.

* core/potion.c: open scripts in binary mode on windows, in case it's bytecode.

* core/vm-x86.c: working 64-bit into the potion_x86_debug func.

* core: pass the PNProto into all jit operations, move locals clearing code into each target platform's `registers` call.

* core/vm-x86.c: working on routine to build stacktraces from inside the jit: following stack pointers with closure objects next to them.

* core/vm-x86.c: only compile the upvals lookup if the functions inside each function contain upvals. (since blocks can't refer to enclosing variables if they're brought in from other scopes.)

* core/potion.c: using a file descriptor rather than FILE, to avoid any use of malloc in the core.

* core: okay, all allocation is moved to the potion gc.

* lib/hpricot/tag.rb: Hpricot::Attributes proxy object for using `ele.attributes[k] = v` directly. however, it is preferred to use the jquery-like `elements.attr(k, v)`.

* lib/hpricot/tag.rb: solve issue #3 with bogus etags being preserved in `to_s` rather than just `to_original_html`.