| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Also, just building without bzip2 or lzma easier.
|
|
Bu::String::const_iterator that should have always been there.
|
|
|
|
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!
|
|
|
|
|
|
This is great if you want to pre-fill a field, say.
|
|
the canonical mode had so long ago.
|
|
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.
|
|
code, but I have a feeling the fix could be much better. I'll look into it
later on.
|
|
you want to.
|
|
important, they are references to constant data, weather they should be able to
become bound still.
|
|
backspace key was pressed, backspace is to move the cursor back one
non-destructively, DEL is sent to indicate that a backspace was pressed.
I now treat BS as DEL when serving because some clients (windows), send the BS
instead of DEL key and everything else just seems to take it. I think there's
a way to negotiate that, which I'll look into later.
|
|
you the next line.
|
|
|
|
appropriate headers. bin2cpp now uses those headers to compile correctly
despite having missing filters.
|
|
of each file in the source. It would be nice to have an enumeration or
something at some point too.
|
|
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.
|
|
and both really need to be. Bu::Client is used in multi-threaded applications
and has been for a while, so it's a no brainer. It may need a little bit more
safety added around variable access, but all the buffers are safe now.
ProtocolTelnet has it's own issus, and I should probably rework a few parts of
it before too long so we can better accomidate things like line editing.
|
|
|
|
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.
|
|
We can't be waiting for an update later on to flush our buffers all the time!
|
|
|
|
I assumed a long would be 4 bytes, that was silly!
|
|
|
|
|
|
|
|
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.
|
|
|
|
and fixed a null/integer issue in Bu::Hash
|
|
iterator issue in Bu::String.
|
|
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.
|
