aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2009-01-14david - removed debugging goo after finally getting it to workDavid
2009-01-14Gettin' closer.Mike Buland
2009-01-14david - WSA functionsDavid
2009-01-14Ok, no...now we have better debugging.Mike Buland
2009-01-14More debugging.Mike Buland
2009-01-14Ok...this may work. We completely changed the way Bu::Socket resolvesMike Buland
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.
2009-01-14david - added getaddrinfo and freeaddrinfoDavid
2009-01-13Ok...now UnsupportedException has text in it's what.Mike Buland
2009-01-13Fixed an out there corner case in Bu::Socket::read where it would get an EAGAINMike Buland
errno out of ::read for no apparent reason. Now it treats it as expected, it just returns zero bytes read.
2009-01-12Really a nothing change, the array is slightly more optimized in one cornerMike Buland
case that you'll never care about. It didn't fix the strange warning messages though.
2009-01-12The Bu::List::end() function was returning a null pointer instead of aMike Buland
properly formed iterator. That caused a few problems. I think it's all set now though.
2009-01-11A new feature has been added to Bu::Server. It's going to be trickier toMike Buland
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.
2009-01-09Whoops! You can't fix a problem in server and forget about ItoServer! That'sMike Buland
just aweful! Well, he's not forgotten now.
2009-01-09Hey, that's better. The server now idles the same, but sends data uber-fast!Mike Buland
2009-01-07Corrected a couple of places where std:: classes were being used and shouldn'tMike Buland
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.
2009-01-07Only two real changes. First, Bu::FString and Bu::FBasicString are in differentMike Buland
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.
2009-01-05I mergered Bu::CPtr into Bu::Cache as Bu::Cache::Ptr. This makes more sense toMike Buland
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).
2008-12-31Wow, that was a freaky bug. Turned out to not have anything to do with theMike Buland
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.
2008-12-30david - i found a strange hash bug, and made a unit test to reproduce it ↵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...
2008-12-29Corrected the premature end of stream read corner case in Taf...it was freakingMike Buland
out and allocating all memory, now it just throws an exception.
2008-12-29Fixed some horror inside the Taf writer. It had a strange corner case whenMike Buland
adding a property to a group that had a name but an empty value. Also added a isEmpty() function to Bu::FString, finally.
2008-12-25Minor change, just some cleanup goo.Mike Buland
2008-12-24Strange, I never actually made any of the server code clean up behind itselfMike Buland
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.
2008-12-22Hey, corrected a minor issue in Bu::FString. Turns out C++ is hardass enoughMike Buland
that we need a concatination operator for both const chr * and chr *. This fixed a suprising number of problems.
2008-12-20All of the basic, core workings of the Cache are complete, and tested. EvenMike Buland
added some more tests and whatnot. A lot happened, but I can't remember everything. Also, Bu::File reports errors in more error cases.
2008-12-13The Calc should be functional, and is being called by the Cache itself. TheMike Buland
Bu::CacheCalc still needs to reference the Bu::Cache so that it can make the changes it needs to.
2008-12-12All of those changes I thought I'd already committed. The taf writer handlesMike Buland
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.
2008-12-10Whoah, got rid of maaajor debuging goo.Mike Buland
2008-12-10Fixed a couple of minor Bu::TafReader bugs. It wasn't parsing the colons, andMike Buland
it was off two characters on the first line for error reporting.
2008-12-03Alright, the caching system now passes the basic CRUD tests with arbitraryMike Buland
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.
2008-12-01Wow, that's a lot of changes. You can use anything as a key now, as long as itMike Buland
can be hashed. And we're about to test actually loading and saving persistant cache items. Fun.
2008-12-01Woo! Very nearly there cache-wise, I'm about to change the name of the handler,Mike Buland
do a few more tests, and hopefully get something loading/saving.
2008-11-13Huh, there should be more here...I...uh...I'm confused.Mike Buland
2008-11-11david - needed Bu::Array to be in the windows buildDavid
2008-11-11david - added operator= and copy constructor to Bu::Array, and updated unit ↵David
tests to test it
2008-11-10Ok, the cache-id officiation is being delegated to the CacheHandlers, this isMike Buland
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.
2008-10-27david - apparently windows prefers to dynamically load winsock and a couple ↵David
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...
2008-10-27Deleting the Bu::CachePtr files, there's nothing in them, I decided to call itMike Buland
Bu::CPtr a while ago.
2008-10-24david - ok, fixed the compiler warnings in socket class. got serversocket ↵David
compliling without warnings. added win32_compatibility.h along the same lines as osx_copatibility.h
2008-10-23david - first steps to getting socket to compile in windows (MinGW)... it ↵David
compiles, but there are a lot of warnings, and it hasn't been tested yet...
2008-10-20Hey, Bu::Array supports erasing elements in two distinct, yet flavourful ways.Mike Buland
2008-10-09More cache development. I'm going to have to switch from template functions toMike Buland
functors. I like template functions a little more, but functors can be at least as fast. It won't be much of a change.
2008-10-09david - make the operator= on iterator and const_iterator return themselves.David
2008-10-08Hey, more cachey goo!Mike Buland
2008-10-08Ok...corrected a problem with new block allocation in nids, and it no longerMike Buland
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.
2008-10-02Really fixed the rest of the file open issues...it was always using exclusiveMike Buland
mode.
2008-10-02Ok...now Bu::File doesn't set stupid permissions when it creates a new file...Mike Buland
2008-10-02david apparently window doesn't have O_NONBLOCKDavid
2008-10-02More changes to File...turns out tempFile always opens the file for reading andMike Buland
writing...so...what more do you need? It was ignoring the open flags you gave it anyway.
2008-10-02Updated on my laptop and discovered that the new, more pedantic gcc had aMike Buland
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...