Age | Commit message (Collapse) | Author |
|
now ready for actual use.
|
|
The old cache system will be going away now, so if you need it for anything,
grab a version before this commit.
Oh, also, happy 1,000th commit!
|
|
|
|
it works very, very differently, but the interface is proving much easier to
use and it should be much faster, not to mention thread-safe.
|
|
The new cache is really coming along now.
|
|
computers.
|
|
two classes, one for the store, one for the cache itself. The index will have
to go with the store, which I find a little odd, but it'll...probably work out.
|
|
Creating an experimental new cache system that's controlled primarily with a
subclass. This should cut down significantly on the amount of code needed to
use the cache. The new one also features a required (for now) base class for
objects that use the cache. This simplifies so many different things.
|
|
been added, and I deleted a whole slew of stupid old tests that I don't need.
|
|
semantics go as well as switching everything to the new string formatting code.
|
|
fstring, and updated the copyright notice to extend to 2011
|
|
that were using fstring, I hope.
|
|
|
|
|
|
copyright 2007-2008.
|
|
key just belongs first, that's all there is to it.
|
|
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.
|
|
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.
|
|
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...
|
|
about each object that it has and weather or not to sync it. This will probably
be made optional in the future.
|
|
BitString is...not so good...I may have to rewrite big chunks.
|
|
one to a Calc and one to a Store. It takes ownership of the two objects, and
deletes them when it gets cleaned up.
|
|
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.
|