| Age | Commit message (Collapse) | Author |
|---|
|
it's done. It works great, and provides much flexibility and usefulness.
It now relies on the input side of the Formatter class, which at the moment
supports reading strings...not real useful yet...
Next up, adding readers for numbers and such, then it'll be mostly complete.
Also, fixed a bug when copying uninitialized signal objects.
|
|
Now I just have to come up with a way to modify data that you already have,
that sure was a nice feature of the old one, even if it was implemented in a
silly way.
|
|
now, I'll probably add more later on...
I've also started on the replacement for ParamProc, OptParser. It should do
everything that ParamProc did, only with less code, and much better.
|
|
it's functions now, such as isEos and whotnot, although it won't work in non-
blocking mode yet, and I'm still trying to figure out a good way to have it
deal with both stdout and stderr.
|
|
|
|
data or order etc.
|
|
as includes go. This required a little bit of reworking as far as archive goes,
but I've been planning on changing it aronud for a bit anyway.
The final result here is that you may need to add some more includes in your
own code, libbu++ doesn't include as many random things you didn't ask for
anymore, most of these seem to be bu/hash.h, unistd.h, and time.h.
Also, any Archive functions and operators should use ArchiveBase when they can
instead of Archive, archivebase.h is a much lighterweight include that will
be used everywhere in core that it can be, there are a few classes that actually
want a specific archiver to be used, they will use it (such as the nids storage
class).
So far, except for adding header files, nothing has changed in functionality,
and no other code changes should be required, although the above mentioned
archive changeover is reccomended.
|
|
change to the Taf system. Really all that's happened is I've broken out the
core taf data types into seperate files, and gone ahead and created a helpful
new header file ("taf.h") that will include the entire taf system, including
the reader and writer for you.
This means that a lot of programs will start complaining, but fortunately,
there's an easy solution, if it complains about taf, make sure to include taf.h
at the top, instead of other taf files and you'll be set.
The next set of changes will add lots of helpers to the taf system and change
the reader to read non-const structures, i.e. I'll actually add editing support
to created taf structures.
|
|
type. It's really just that easy.
More info, docs, and tweaks to come.
|
|
|
|
actual Date class.
|
|
much anymore, for the fishtrax issues, maybe.
|
|
Bu:;SharedCore actually is in and works, it's well tested and there are no
known memory leaks or violations as of now. It's been applied to Bu::List and
Bu::FBasicString so far. This means that everything using Bu::List and
Bu::FBasicString will be much, much faster and use considerably less memory.
I still have plans to apply this to Hash and maybe a couple of other core
classes.
|
|
|
|
basics. It works, so now I'm going to apply SharedCore to Bu::List and see how
bad it is.
Also, I got rid of all the warnings and things that showed up during
compilation, they were all silly anyway.
Finally, mkunit.sh is much cooler. Hard to believe it's a shell script, it now
also adds proper #line directives to the cpp output so if there is an error or
warning g++ will give you the right line number in your .unit file, not the
resultant cpp file.
|
|
|
|
it returns the raw binary string that makes up the md5 sum, this matches the
original goal of the API and makes the whole system more general and
transportable. I have added a handy helper function named getHexResult that
will return the same classic hex md5 string we're used to, change anything in
your code that uses getResult to getHexResult now.
I've also added a handy function to the CryptoHash to write the result to a
stream, writeResult. I've fixed some more things in the formatter, and added
a cryptPass function that works very much like the system crypt function, md5
and base64. If I knew more about the glibc implementation I could probably
make them compatible. For now there are some subtle differences in the
formatting and the salting algorithm, also the output mantains it's base64
trailer (==) wheras the system function chops those off. There's also another
helper that will only work on linux for now, that only takes the password, and
generates a salt for you using urandom.
|
|
also made sure the copyright is at the top of all the files, it's been too long.
Anyway, this may effect some code, but not much, and it's an easy enough fix.
|
|
it throws exceptions. It'll still try to process bad data for a while though.
Also, it turns out that Bu::File never reported EOS, now it does, appropriately.
I'm about to change Bu::Stream::isEOS to be Bu::Stream::isEos, this is your
warning.
|
|
|
|
follows the new filter guidelines, where read and write report the amount of
data consumed, not the amount processed. I.e. when writing, it reports how
much of your incoming data it used, not how many bytes it wrote on the other
end.
|
|
|
|
chain on the base stream, which for the moment is a socket.
I also demonstrate this in the new rot13 test, with a rot13 filter, and a simple
echo protocol.
|
|
Truncate, and Create, the flags used most commonly when writing a new file.
Also added the Bu::Base64 filter class, it does base64 encoding and decoding,
it may need a couple more interfaces added, but for the most part, it's solid.
|
|
encoding and decoding and uri encoded splitting etc in one class.
|
|
adding some more helpers. Hopefully this won't affect anything, but if it
complains about any functions not working the way they used to, see if they're
returning an int or an iterator. I made several functions handle iterators
instead of ints, the int versions have an "Idx" suffix added now. I'm trying
to switch entirely to iterators to reduce flattening and increase performance
and stability.
Also...something must have changed in the cache code...
|
|
Also I added a bunch of classes that I've been tinkering with that are almost
ready for use, so I figured I may as well throw them in here.
|
|
about each object that it has and weather or not to sync it. This will probably
be made optional in the future.
|
|
cachestorenids all support synchronizing now. Url is pretty much done.
|
|
to rock. sha1 is still only a shell, I dunno if/when I'm going to implement
that one.
So far Bu::Md5 is 100% compatible with md5sum in all tests performed so far, in
fact the test program's output is compatible with md5sum in every way (and it's
so cute and little too!)
Oh, minor update for stdstream and the formatter, they can handle more handy
types now.
|
|
|
|
lets see how nice we can really make it.
|
|
indexing. It is now many times faster, and requires less overhead. Also,
more stuff iterator related in every class. More on that later.
|
|
block size. Isn't that nifty?
|
|
creator functions for the cache store...soon, you'll also be able to define
you're own loader/writer functions, but the default will still work exactly
like this.
I also did more work on nidstool, I think I may actually have to create a
tools dir that will just compile some executables for the libbu++ root, because
this thing is handy. You can get info on the system, trace streams' blocks,
and I'm working on an analysis function that will help you figure out how to
optomize your nids files. Plus, it'll have a function soon for re-writing a
nids stream, which will let you change the block size, defragment, and remove
unused blocks.
|
|
often within nids. There's still a problem somewhere, but I'll find it.
Also, even after having the file class canRead and canWrite functions work
properly, and using them before trying to write to a nids to update info, we
never ever write anything, so something is still wrong there. For now, all
utilities that open a nids stream read-only will crash when it closes. Pretty
minor really.
|
|
BitString is...not so good...I may have to rewrite big chunks.
|
|
clear function to Bu::Stack
|
|
unary operators now, such as negate and not, and it now handles functions.
Functions are actually implemented as unary operators at the moment, so they'll
only act on a single value, no commas :-P, but it would probably be pretty easy
to make it work on longer call lists. Although I do think that this will work
for pretty much all cases out there.
|
|
Bu::Socket::read will throw an exception if the socket has been closed. Also,
you'll get an exception at object creation if the socket could connect to a
computer, but not the given port.
|
|
one to a Calc and one to a Store. It takes ownership of the two objects, and
deletes them when it gets cleaned up.
|
|
implement in Bu::ItoServer, but I'll get to it. Basically you can trigger a
"tick" any time you want and it will propegate as an onTick event to all active
clients. You can also have these generated automatically everytime the system
passes through a polling cycle. In this case, you should never ever write
data to the socket every tick. It will cause your program to go bursurk.
|
|
added some more tests and whatnot. A lot happened, but I can't remember
everything.
Also, Bu::File reports errors in more error cases.
|
|
keytypes. It doesn't yet use the stackable CacheStore concept, but the code
is all in place to make it easy to switch to. There also needs to be some more
accounting code in place, so that we can actually use the Schedulers, whatever
they happen to be called in the future.
A whacky side note, it turns out that we totally need to ensure an object is
loaded from the cache in order to delete it, we can't ensure that any
references to other objects that are in the cache will be loaded otherwise.
|
|
can be hashed. And we're about to test actually loading and saving persistant
cache items. Fun.
|
|
do a few more tests, and hopefully get something loading/saving.
|
|
just fine, since they can do it any way they want. The Congo CacheHandlers
will all have to be specialized versions of the generic ones, but they'll use
all the general functionality, just make up IDs differently. It'll rock.
|
|
functors. I like template functions a little more, but functors can be at
least as fast. It won't be much of a change.
|
|
goes into an infinite loop while doing certain kinds of read. Also, it zeros
out new blocks to make things easier to cope with in the hex editor, it'll
probably also compress better.
I also fixed Bu::MemBuf so that you can now write to arbitrary places
mid-stream.
|
|
|
