| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
addresses. Windows wouldn't work with the other way at all. But, fortunately,
this seems to work, it does more for us, and it looks pretty cute.
|
|
|
|
|
|
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.
|
