| Age | Commit message (Collapse) | Author |
|---|
|
installed. That was odd. Anyway, also set props on the bu, unit, and test
directories so that the contents won't be listed on svn status.
|
|
effort.
|
|
the pipes properly, resulting in the child process going defunct and not dying,
it also wasn't buffering properly, it now collects as much data as it can before
returning from a read operation.
|
|
coming up...it's just like popen only cool and managed, and streamey.
|
|
compile error I introduced last commit.
|
|
|
|
comment block as a tag...oops.
|
|
of which use printf style formatting and accept the same parameters as printf.
|
|
brought back the formula class with some cool twists, and added a basic stack
class, very cute, fast, and little.
|
|
|
|
this with the Bu::Archive next. Basically, there's one generic template
function that will convert anything that can safely cast to a uint32_t and that
supports direct comparisson, and doesn't have it's own override already to be
a Hash key, such as char, uint8_t, uint64_t, etc.
The Telnet protocol handler does everything I need it too for now, next up for
it is escape sequence handling, it would be nice to make this general too, by
using the termcap database or something, but there is an ANSI/ISO standard now,
I may just go ahead and use that. Also, it looks like it'd be pretty easy to
make the canonical mode editing functions be pluggable to facilitate different
types of editing, but that can be done down the road as well.
|
|
the existing docs. Taking advantage of some of the cooler extra features of
doxygen I've started writing extra how-to pages covering working with sections
of the library. Also, I started grouping the classes by function so they show
up on the Modules page together, very cute.
|
|
very similarly to the Bu::Server class, except that every incoming connection
gets it's own thread. This functionality may have to be tuned later, to allow
for maintaining a pool of connections as an option, but this is fine for now.
|
|
(common in web addresses) was put in the middle of a property list, now it
doesn't get confused, it just complains bitterly and refuses to work.
|
|
compile under OSX. So far, no problems with anything else, it looks like build
and nango both build without problems, libbu++ is truly becoming a full cross-
platform toolkit.
|
|
|
|
|
|
|
|
some things, so here they are, after being manually copied.
|
|
now allows you to include extra printf formatting in your fields just like the
docs say you can.
|
|
comment blocks, and it retains the order of all nodes.
|
|
a decent replacement for multilog now that we use runit.
|
|
|
|
|
|
now when the end has been reached.
|
|
|
|
that could be in this, but it's going to be hard to tell...
|
|
has a lot more helper functions and the like, the filters give more info back
to the caller, minor updates to taf.
|
|
to compensate for overshooting the end of the compression block yet, which it won't
be able to do on streams that don't support seeking...I think I'll make it only
try on stop commands, and try to re-use the buffer otherwise...maybe...it's an
interesting problem since it *always* overshoots (unless you're really, really
lucky...)
|
|
had anticipated, and much cleaner. I'll have to add some documentation to it,
because it's not really obvious how any of it fits together from the outset,
although I have to say that the bzip2 test program is the easiest general bzip2
compression program I've ever made...it just goes :)
Decompression in Bu::BZip2 isn't finished yet, but that's ok, it's coming soon.
|
|
TafNode structures are immutable, it all looks really good. Saving should be a
snap, and the immutable part I'm not sure is bad...we'll see what happens.
Also, I'm contemplating looking into a way to add "named data structure" support
to the Archive at a lower level, then allow it to use a nameing system to apply
names to each data structure and then output to any backend that supports
naming, like taf, xml, etc.
|
|
working. Now you can load Taf structures and clean up, you just can't access
all of the data inside 100%.
|
|
Some more generalizations are in order, then we'll stuff the data somewhere.
|
|
with objects at the moment, still contemplating that one...
|
|
the std::string copy by a rather large margin. This seems very odd, so I'm
going to do a few tests, the first one is stripping out the FString shared
pointer stuff and seeing if that makes an appreciable difference.
|
|
actually interacting with clients, and the Client class is almost there, except
that it doesn't really do anything yet.
|
|
should act, you can't change anything in there. I'm still debating changing
the const_iterator to a constIterator, or something else that's more Bu::worthy.
Heh, the namespaces are funny...ok...I'm really tired.
|
|
forgotten proper cleanup in the deconstructor, but besides that you can do
almost everything you need. I'll make a slist/stack next, probably with the
same basic code, just a different structure (not doubley-linked).
The xml system from old-libbu++ is almost completely converted, I was going to
re-write it, but this seemed easier at first, it may not have been, we'll see.
It almost parses everything again, and almost outputs again, and it does use
streams now.
The FString is partway to doing minimum chunk allocations, so that adding
single-characters will be really fast up to the minimum chunk size. I also
figured out how to add this optimization without any extra variables taking
up space, and it's optional in the template, which is cool. You can specify
the size of the blocks (default 256 bytes), if it's 0 then they'll be like the
old FString, 1 chunk per operation.
The next FString update should be allowing efficient removal from the begining
of the string by faking it, and simply moving a secondary base pointer ahead,
and then optimizing appends after that fact to simply move the existing data
around if you shouldn't have to re-allocate (alla FlexBuf). The final fun
addition that I'm planning is a simple switch in the template (boolean) that
will switch an FString into a thread-safe mode without changing the interface
or anything that you can do with them at all. It may increasing memory usage,
but they should still be better than std::strings, and totally thread-safe.
The best part of that is that if it's done with a boolean template parameter and
if statements that only test that parameter controlling flow, the code that you
don't want (threadsafe/non-threadsafe) won't be included at all
post-optimization.
|
|
(textual archive format), but named it wrong, this seemed easier than redoing
it all.
|
|
formatting on the comments, some of the lines wrap, but I'm not too worried
about it right now. I also fixed up the doxygen config and build.conf files
so that everything is building nice and smooth now.
|
|
|
|
tweaks to archive. The && operator is now a template function, and as such
requires no special handling. It could be worth it to check this out for other
types, yet dangerous, since it would let you archive anything, even a class,
without writing the proper functions for it...we shall see what happens...
|
|
isn't done yet, I'm going to make it rely on streams, so those will be next,
then we can make it work all sortsa' well.
|
|
into src as it's fixed and re-org'd. This includes tests, which, I may write a
unit test system into libbu++ just to make my life easier.
|
|
|
|
now.
|
|
templates are confusing.
|
|
|
|
the other classes in functionality. It's already rather fast.
|
|
|
