Age | Commit message (Collapse) | Author |
|
I should add a new class of program to libbu++ or clear out most of my old tests
or something. Anyway, almost fully C99 compliant float to normalized hex string
and back functions in pure math. Really slick, really portable. they don't
handle +/-NaN, +/-Inf, or the special alternate format for subnormal numbers,
try entering a 0.0...01 where I cut out about 200 zeros, you'll see what I mean.
|
|
now.
|
|
the queue immediately, with or without rescheduling, by id or name.
|
|
|
|
there's one more fix I can make later to really speed up transmission, but it's
a little more delicate.
Also, Cache::Ptr objects are now camparable even when unbound.
|
|
|
|
|
|
rename, but there seems to be a problem, rename uses mkHardLink, and if the
target exists, hey, it adds another one...not quite ideal...
|
|
tell, we're missing rename, chown, and chmod.
|
|
addressed, besides that, only a couple more functions need to be added to
myriadfs before it's totally ready to have linux installed on it :-P
|
|
|
|
along quite nicely. It looks like it works great for normal programs, but there
need to be some tweaks made to a few things before it's working 100% via fuse.
Also, the fuse module won't let you specify a file, a little odd.
|
|
|
|
etc. Next up is creating directories, and other special file types.
|
|
decisions to make and we're set.
|
|
|
|
commas or quotes quite right, it's much better now. Also, added an SHA1 unit
test.
|
|
|
|
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.
|
|
|
|
the fixstrings.sh script in the support directory to (hopefully) automatically
update your projects.
|
|
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?
|
|
|
|
changes many others, including source files that were deleted and renamed.
Before doing this update, I reccomend a full clean, or even a fresh checkout.
Things to note, most outstanding about this update:
- Bu::Socket was changed to Bu::TcpSocket and the default mode is blocking.
- All templatized container classes are SharedCore now, which is good, but
SharedCore is inherently non-reentrant safe. However, all SharedCore classes
have a "clone" function that return a non-shared copy of the object, safe for
passing into a reentrant safe function accessing shared memory.
|
|
|
|
|
|
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.
|
|
|