Age | Commit message (Collapse) | Author |
|
our results are right, but I can at least write a unit test and make sure that
minor changes in the inputs create different results in the output.
|
|
|
|
|
|
we can figure that out later.
|
|
|
|
|
|
are failing...
|
|
|
|
use a Bu::String as it's backend storage, so we'll get all the great out of
that...
|
|
fstring, and updated the copyright notice to extend to 2011
|
|
that were using fstring, I hope.
|
|
|
|
|
|
|
|
|
|
|
|
errors now...uh...woo?
|
|
|
|
|
|
|
|
to do right now. This commit contains minor fixes to the cache stores so they
don't generate any warnings, and the hashtable includes == and != operators now.
|
|
comma was the last character. It's best to preserve every field, even if it's
completely blank.
|
|
conflict with this file... #undefed them for now, figure out better solution later
|
|
|
|
|
|
Unicode handling we'll need to implement a series of codecs and converters as
well as tables of codepages and lookups. It'll be interesting, I guess, but
it makes me care a lot less about proper encoding. Anyway, UtfString uses
shorts instead of chars, so it's a step in the right direction, but still not
enough to be able to handle proper UTF-16 encoding, maybe UCS-2 encoding, but...
...that's lame. Bu::FBasicString has been generalized a bit with optimizations
from libc for char based strings. It also, unfortunately, still uses char-only
functions in several places, those all rely on char casting strings at the
moment just to get the thing to compile. Basically, it's not a good UTF-16
solution yet, and it may never be and remain compatible with char based strings.
|
|
cli tool.
|
|
|
|
underlying stream hits the end before the end of the bzip2 stream then it just
reads forever...that's lame. Now it throws an exception.
|
|
would always fail if a const char * was passed in, it now converts these
silently to Bu::FStrings, good to know...
Also, the OptParser now uses a Variant for overrides, meaning it doesn't have
to do extra parsing, and the amount of code you have to write may be
significantly reduced. Pretty sweet, overall. There is one downside. For the
moment if you use a non-standard type or object as the target of a parameter
it always needs to have a formatter >> operator defined, even if you override
and the formatter >> operator is never called. Hopefully we can get around
this in the future.
Also, it looks like it should be relatively trivial to create conversion
functions for the variant, they'll just be global template functions that
take two parameters, source type and target type. Should be good times.
|
|
|
|
The parser works! The parser compiler works! It makes parsers!
Now we just have to implement post processing, token lookup tables, and storage.
|
|
lookahead or precedence, but I should be able to do that easily with the next
version. I'm treating this more as a proof of concept than a real working
model. Although it can handle +, -, (), and = :)
|
|
TcpSocket, fixed many other things, and finally removed ParamProc. Anything
that needs it will now have to switch to OptParser.
|
|
may be a few other things that should change too, we'll see.
Played with doxygen docs on List, we can actually use @cond to remove things
from the docs, either permenently or conditionally, and so I could trick it into
making all of the sharedcore classes inherit from the same SharedCore in the
docs instead of different ones. Or, just not inherit from SharedCore at all.
What to do...? :-P
I also got rid of ListHash, it wasn't working out yet anyway.
|
|
another object of the parent type has the same core, and another to clone the
parent object. That one is pretty cool, it means you can now get a real copy
when you want to, great for multi-threaded stuff.
Also, two more classes are now SharedCore: Hash and Heap!
|