| Age | Commit message (Collapse) | Author |
|---|
|
errno out of ::read for no apparent reason. Now it treats it as expected, it
just returns zero bytes read.
|
|
case that you'll never care about. It didn't fix the strange warning messages
though.
|
|
properly formed iterator. That caused a few problems. I think it's all set
now though.
|
|
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.
|
|
just aweful!
Well, he's not forgotten now.
|
|
|
|
have been. Also made the Unit tests actually use expected values, so you can
mark a test as "expected fail" and it'll know. It also prints out cute reports
at the end of each run.
|
|
files. This won't affect any programs at all anywhere. This will just make it
easier to maintain and extend later. You still want to include "bu/fstring.h"
and use Bu::FString in code.
The other is kinda fun. I created a special format for unit tests, they use the
extension .unit now and use the mkunit.sh script to convert them to c++ code.
There are some nice features here too, maintaining unit tests is much, much
easier, and we can have more features without making the code any harder to use.
Also, it will be easier to have the unit tests generate reports and be run from
a master program and the like.
|
|
me, is much less messy, and makes the syntax work a little better for me as
well. What the hell was a CPtr? Who knows, but a Cache::Ptr, that makes sense.
Also, fewer includes to deal with now, just need Cache and you're set.
Oh, also, made Cache::Ptr behave much more like a regular pointer, they can be
assigned now, as well as created empty (NULL).
|
|
size of the table, it had to do with using non pointer types for the key (some
more complex types worked as well, probably because of lazy memory collection)
and then using the [] indexing operators. You wound up with pointers to local
variables that didn't exist by the end of the assignemnt operator.
Strange, but I didn't actually use references inside of all of the Bu::Hash
accessor functions, that means in cases where more complex variables are used
as keys (like Bu::FString) it was making several copies of them per operation
and destroying them all immediately. Now it will be even faster and use much
less memory.
Good catch, David.
|
|
("insert3")... with a hash of type Bu::Hash<int, Bu::FString>, when the size of the hash reaches certain points (11, 23, 46, 94, etc...), it seems to reset itself and not have any data in it...
|
|
out and allocating all memory, now it just throws an exception.
|
|
adding a property to a group that had a name but an empty value.
Also added a isEmpty() function to Bu::FString, finally.
|
|
|
|
in the deconstructors. When you deleted a server it wouldn't close it's
sockets. We never noticed because servers normally last the entire lifetime
of the program they're in.
|
|
that we need a concatination operator for both const chr * and chr *. This
fixed a suprising number of problems.
|
|
added some more tests and whatnot. A lot happened, but I can't remember
everything.
Also, Bu::File reports errors in more error cases.
|
|
Bu::CacheCalc still needs to reference the Bu::Cache so that it can make the
changes it needs to.
|
|
binary data much better, actually escaping it properly and not stopping on null.
Bu::FString has an iterator, it's actually just a raw datatype, but it may have
more function later, so careful assuming that it's a char and using it in any
non-iterator like way.
Also augmented the taf unit test, and added the Bu::CacheCalc base class, the
rest of the simple develpment cycle will happen between here and project hhp.
|
|
|
|
it was off two characters on the first line for error reporting.
|
|
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.
|
|
|
|
|
|
tests to test it
|
|
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.
|
|
other libraries, so I got it all compiling and working in windows, yay!... I tried to minimize the impact on the code: I made a DYNLOAD macro that evaluates to nothing on everything else, but runs the dynamic code if compiled for windows... also, apparently I had been randomly switching between ifdef and ifndef WIN32: so i made most of them ifdefs so it was less confusing...
|
|
Bu::CPtr a while ago.
|
|
compliling without warnings. added win32_compatibility.h along the same lines as osx_copatibility.h
|
|
compiles, but there are a lot of warnings, and it hasn't been tested yet...
|
|
|
|
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.
|
|
mode.
|
|
|
|
|
|
writing...so...what more do you need? It was ignoring the open flags you gave
it anyway.
|
|
problem with a missing include. Also, if you get errors about conflicts and
things being declared twice, then "rm src/exceptions.o" it shouldn't be
sneaking in there still, but it may be. then do a full "build -c all" and
build.
Oh, also found some solid gold taf code that never got included, but is very
much needed. Remembering to commit would be useful...
|
|
What changed API-Wise:
- I deleted a constructor in Bu::File that shouldn't have been used anyway.
- I changed it from using fopen style mode strings to using libbu++ style
mode flags. Check the docs for the complete list, but basically instead of
"wb" you do Bu::File::Write, and so on, you can or any of the libbu++ flags
together. There is no binary/text mode, it just writes whatever you tell it
to verbatim (binary mode). Lots of extras are supported. Nothing else
should have changed (except now the file stream is unbuffered, like all the
other streams).
Sorry if this breaks anything, if it's too annoying, use the last revision for
a while longer.
|
|
exception related code that's been annoying me. You should no longer have to
include any exception header explicitly for normal operations, every class that
has it's own exception to throw defines it in it's own headers.
This may break some code that uses libbu++, but it's an easy fix, just delete
the include for exceptions.h. Sometime soon I would also like to move from
Bu::ExceptionBase to Bu::Exception, but that will affect a lot more code than
this change did.
|
|
stub. We are going to need some windows api stuff to do that...
|
|
slow, painful death? Anyway, I removed all the extra debugging info.
|
|
|
|
warnings. Of course, it said that a class with a copy constructor that also has
one or more base classes should explicitly initialize the base classes in the
copy constructor so nothing too suprising happens to you. I agree with this.
|
|
wrote it, it's pretty feature complete, index, append, iterators. You can't
delete anything yet, exactly, but that's tricky in an array anyway, basically
you just want to be able to remove elements from the end, and that's halfway
there.
Also, fixed some documentation and minor issues in Bu::Set, and made the
Bu::Archive include fewer other classes while still defining archive oprators
for them. I think I may yet move those into the headers for the classes that
are being stored instead, makes a little more sense.
I also would like to move the Exception classes out of the exceptions.h file
and into the appropriate class' files'. There still should probably be a
couple of general ones in there, or maybe just in exceptionbase.h, we'll see.
|
|
test.
|
