Age | Commit message (Collapse) | Author |
|
|
|
UtfString supports a load of new stuff, and Json uses UtfString
exclusively now.
|
|
I need to redo it completely, it's stupid.
|
|
|
|
It still needs to handle the rest of unicode properly. It'll require a
minor change but shouldn't be too bad overall.
|
|
Also started some FS related thread safety.
|
|
|
|
|
|
|
|
It didn't handle empty arrays or objects correctly.
|
|
|
|
It may not have had as much to do with low-level protocol details, and a
lot of this can be reverted, but I can't revert it right now. I'll look
it over later in the week.
|
|
|
|
|
|
|
|
It would be really cool to add more features, like pre-websocket
negotiation and callbacks for serving web content, etc.
|
|
It immedaitely converts it to UTF-8 and stores it for now, but later on
we may keep it longer, do some better validation, and have encoding
options.
|
|
|
|
It needs a lot more help.
|
|
|
|
It needs a lot more work before it can be used to programattically build
complex objects, but it's a great start.
|
|
|
|
|
|
This new setup is one class for everything, the values are kept in a union, and
the instance knows what type it is. The tree of objects is a tree of
instantiations of the same class. It's much simpler, it's much easier to write,
and maybe even easier to use.
|
|
I'm honestly not sure what kind of interface I want here, or how to organize
it. It may just be better to expand the whole thing, spread it out some.
|
|
This allows you to write data to multiple streams simultaneously and
easily. It's pretty much complete, but it feels like it could use
more...features somehow.
|
|
|
|
sentence, but it's true. Also, oddly enough, Lockers aren't thread-safe, but
they shouldn't ever have to be. Figure that one out!
|
|
|
|
unprotected, but fortunately this time I was able to use a read lock which is
much lest nasty and persistant.
|
|
syncing changes. That was important so that more changes wouldn't be added
while we're writing, but it also meant that in a very particular circumstance
where one thread was syncing changes, another was marking changes as having
happened, and another locked an object that was being written because it had
changes they would all deadlock. This should be fixed now.
|
|
important, they are references to constant data, weather they should be able to
become bound still.
|
|
|
|
that we don't get valgrind errors, and is probably safer in general.
Added Bu::ArchiveStream. It could use some tweaks, but as a quick hack it's
handy to allow systems that can only read/write from/to streams to work with
archives.
|
|
deleted before the sync could occur properly. They are now ignored during
sync.
|
|
it still has active references, and it will be safely cleaned up when the last
reference is released.
|
|
|
|
|
|
|
|
things seem to work. We've also tested against LLVM.
|
|
cache information before they are deserialized from storage. This changed the
signature of the cache loading template function, but the new function isn't
harder to use, and provides the key information as well.
|
|
wrapper that lets you take advantage of nifty Locker based mutex locking when
in a CacheObject subclass.
|
|
after they are saved. It needs some more testing, but the theory is sound.
|
|
to be re-engineered to actually do a lazy erase like removing an iNode in a
posix filesystem. While the file remains open it exists, but the references
visible to the user on disk are gone.
|
|
in the CacheEntry class, not the CacheObject, so you can't lock it until you
have an entry. This isn't a big deal unless your objects aren't actually
part of a cache yet. I changed it so that lock/unlock have no effect if you
haven't joined to a cache yet, probably not ideal, I'll think about moving
that mutex.
I also fixed it so you can lock/unlock even when const.
|
|
|
|
saving an entry or syncing.
|
|
|
|
key is loaded then the query doesn't even get to the superclass.
|
|
|