| Age | Commit message (Collapse) | Author |
|---|
|
1) i had to make iterator and const_iterator friends of each other so they could see each other's private constructors
2) apparently there is a bug in the name-lookup related to inline typedef structs and the friend keyword... had to move the typedef struct const_iterator to after the actual struct.
|
|
ProtocolTelnet. I'm going to have to do some reading and find out just where
ProtocolTelnet is...
|
|
doesn't inhibit building. These'll be in good working shape in no time.
|
|
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.
|
|
backwards compatibility. When using it you now have the option to do the
loading, storing, and memory allocation yourself if you want to. If you don't
it will use new/delete, and an archive to store and load your data for you.
|
|
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.
|
|
now. It helps to read the system docs. Anyway, nids is all fixed up, it seems
to work great now, and I guess I got all the corner cases we'll hit for a while,
fishtrax really did a number on them :)
I also cleaned up all the debugging output, now you can see your program run
instead of libbu++ internals.
There could still be a good amount of improvement made in nids, it really
shouldn't re-write whole blocks every time you write to a stream, but that will
be an easy change down the line that won't effect any of the existing code.
|
|
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.
|
|
append one list to another and the like.
Also, wow, I found a bug that's been around for ages, I guess we don't copy
hash tables often. The interesting thing is that it actually worked, it copied
but it would include any data that had been deleted in the old hash table but
not reclaimed yet and insert it as new data. Usually the key had been
completely destroyed (like with a string) so it came out as keyed to blank
string. So in cases like that, all deleted keys would collapse into one deleted
key in the new hash table.
|
|
just too many cases where that was causing trouble. Now it seems like
everything is working correctly again.
|
|
wasn't in a namespace, and it was a little too generic. I like the idea of
putting all the parser exceptions under a new class called ParseException, but
well do it a little later.
|
|
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.
|
|
wasn't that happening before?
|
|
|
|
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.
|
|
lot of problems. This may require a little more research, but basically, you
can't just call them inline wherever you'd like. I managed to get it to work
by providing simple one line wrapper functions for each function we acquired as
a pointer. Crazy mess. Anyway, it should load the library just once now, and
Bu::Socket looks a little bit cleaner, but not a heck of a lot.
I also added some more docs and removed the author references.
|
|
all should, but they don't really haaave to.
|
|
one to a Calc and one to a Store. It takes ownership of the two objects, and
deletes them when it gets cleaned up.
|
|
Isn't that great?
|
|
statement clearer (good coding guide).
Made the Taf code getters report their own errors, so much nicer. They actually
tell you what was looked for from where and that it couldn't be found instead of
a horrible old Bu::HashException key not found error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
