We used to generate a module T with a serialize() and deserialize() fn,
but this was suboptimal for a number of reasons:
- it required moving serialization into core so that uint etc worked
- it was harder to override the serialization behavior locally
(this is now trivial)
- Move io, run and rand to core.
- Remove incorrect ctypes module (use libc).
- Remove os-specific modules for os and fs.
- Split fs between core::path and core::os.
As per discussion on IRC. I am about to file an RFC for further
discussion about the more general issue of whether to enforce
invariants through types, typestate, or dynamic checks, but for now,
removing the misleading name "last_unsafe".
This required changing almost all users of hashmaps to import the hashmap interface first.
The `size` member in the hashmap structure was renamed to `count` to work around a name conflict.
This required changing almost all users of hashmaps to import the hashmap interface first.
The `size` member in the hashmap structure was renamed to `count` to work around a name conflict.
Our json implementation did not conform to the spec, and
was missing support for escpaed characters and exponental
numbers. This fixes it, and adds support for reading/writing
json directly from/to a stream.
There are two things left unimplemented. We could use a
"to_json" iface/impl, but that really needs traits to cut
down on code duplication. The other is it wouldn't be that
not that hard to turn this implementation into a event driven
parser like YAJL, but I ran into some type-inference bugs,
so I cut that out. It'd be nice to revisit this in the future
though.
because of the last change, the loop ptr is no longer cleaned up
when the loop exits. This api call addresses that. Sadly, the loop
ptr is not "reusable" across multiple calls to uv::run().
the core impl is there, with a async handle in place
to take incoming operations from user code. No actual
uv handle/operations are implemented yet, though.
