Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
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 simply forces a hard copy, which means the instance you called this
on will be independant of any other copies. It's something that should
exist, but I'm not sure if unshare is the right name. It's in there
now, though.
|
|
|
|
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!
|