Project Status
This page is my "development diary", a tiny window into my life so you can see how work on PDCLib is coming along. ;-)
2010-07-19
Commit number [450]. Picking up speed wrapping up the v0.5 release.
2010-07-18
What I guessed to be a bug in fseek() turned out to be one in fgetc() (see [437]). But I'm on my way to creating printf() / scanf() tests that work on both 32 and 64 bit platforms, and the number of errors reported is steadily decreasing. After that, write drivers for the few functions that don't have any yet, do the cleanups, and we're set.
Can't wait.
2010-07-01
Doggedly moving on. Many, many small things to fix, improve, and consider. My fseek() seems to be wildly off, as far as my fscanf() test drivers can be trusted. Some things (like the fscanf() test drivers) aren't located where they should be, the headers in ./internals are pretty messed up, the Makefile still doesn't handle dependencies correctly, and so the list goes on.
But I blew up the roadblocks, all I'm doing now is cleaning up the rubble.
2010-06-23
Things are getting along well, as can be seen in [427], [428], [429] and [430].
2010-06-21
With the implementation of tmpfile() and tmpnam(), I think I got <stdio.h> covered. But many things had been done ad-hoc, and been left with a "TODO" or "FIXME" comment. I'm in the process of cleaning these up, implementing missing test drivers and generally double-checking everything.
2010-06-15
I'd really love to take a week of vacation to get v0.5 shipped. As a matter of fact, I had a week of vacation, but that was spent on Real Life (tm) things like spending time with the kids (upper!), and getting my mother-in-law into a care home (downer...). And as much as I like programming, having a BBQ with friends while watching the World Cup on TV does have its own charme.
My wife is pretty down because of her mother (and has much to do in the way of sorting out her papers, washing her clothes and generally getting things organized), so we're going for the "easy entertainment" option these days (instead of her doing something else while I'm spending evenings with the laptop on my knees). I am pretty down because it's a sad thing to see someone becoming old and frail, and because I've a bad conscience thinking about how close I am to v0.5 of PDCLib at a time like this...
2010-05-14
I know I'm sounding like a manically depressed here, but once I got the problems around _PDCLIB_scan() resolved, I started looking at all the other little projects I had neglected in the meantime, and got sidetracked, and v0.5 was again swamped. Got to rearrange that priority list.
2010-04-08
With the implementation of scansets ("%[a-z]") in _PDCLIB_scan(), the test driver no longer reports any errors. That means:
- tmpnam()
- tmpfile()
- perror()
- a couple of test drivers,
- general cleanup, double-checking etc.,
and I am set for releasing v0.5.
This feels great. After four years of little to no real progress, it's nothing less but the rebirth of this project.
2010-04-04
Well, the visit at Breakpoint didn't work out, but I holed myself up in my study and tried to nail those remaining problems regardless. Didn't work out as well as I expected, but that was to be expected. I still hope to make v0.5 within the week.
2010-03-19
I think I got all the "funny parts" of the standard worked out. It's a pretty clear path from here to v0.5 release, and I expect to cover most of the ground over the Easter weekend at the Breakpoint demo party.
It is scary that I worked on stdio.h already the last time I was at BP... seeing how I didn't attend the last two years...
2010-02-08
In case you are wondering, "what could take so long to find out if scanf() works or not", try this one:
#include <stdio.h>
#include <limits.h>
int main()
{
FILE * file = fopen( "tmpfile", "wb+" );
fprintf( file, "%#x\n", INT_MIN );
rewind( file );
{
unsigned u;
fscanf( file, "%x", &u );
fprintf( "Expected: %x, read: %x\n", INT_MIN, u );
rewind( file );
}
{
int i;
fscanf( file, "%i", &i );
fprintf( "Expected: %x, read: %x\n", INT_MIN, i );
}
fclose( file );
return 0;
}
I get an unexpected "0x7fffffff" on my home machine and my office machine. I get the expected "0x80000000" on my office server. And now I have got to figure out which one is correct... and there are more such corner-cases where this one came from.
2010-02-01
It seems progress on PDCLib is either strong or non-existent. Yesterday, I finally got around to start debugging scanf(), and as usual, am mortified to see how long this has seen no activity. I've written a test program (not in the SVN) that tests the various shallows of the standard (such as, what should happen for scanf( "%0c", &c )...). This needs some extending, and then I will run it on various platforms to get an idea how other implementations interpreted the standard. I expect adjusting PDCLib scanf() accordingly to be no big deal. Plus the couple of so-far unfinished functions like tmpfile() / tmpnam()...
2009-11-18
Life can be surprisingly time-consuming. No progress yet on the scanf() debugging.
2009-10-26
Started cleaning up; can't get myself to continue debugging scanf() right now.
2009-10-22
Still here.
I hope to pick up testing / debugging of PDCLib again this upcoming weekend.
2009-10-06
Heh. When I start to "expect" something. My estimations on remaining work are usually correct (luckily, or I would be in trouble at work). But what seems to be always wildly off is my estimation of how much private time I will be able to spend on a subject.
I won't finish scanf() this week (or next week). But I'm still confident that v0.5 will be released this year.
2009-09-30
I am on a one-week business trip in Rostock. I made good progress on the five-hour train ride, but evening work at the hotel has been slow so far. Nevertheless I expect to finish the scanf() stuff within next week.
2009-09-23
It would be rather presumptious to claim the scanf() function family "done", especially since I haven't run a single test yet, but the framework has been layed. It's all testing / debugging from here.
2009-09-22
Ah well, when I start to "expect" something. Shopping and a soccer game on Saturday, visiting friends on Sunday. Still, things are progressing.
2009-09-19
And when all the forums of the web fail, trust on good old Usenet to be the place where the Pro's hang out. The roadblock has been cleared, I expect to finish the scanf() family over the weekend.
2009-09-18
What seemed like some fun a few days ago has developed into a veritable roadblock. It seems there is no agreement on how the parsing of numeric strings should work in detail... I am trying to communicate on the subject through various channels, hoping to find an authoritative answer on the subject.
2009-09-16
It seems that I've struck on a scanf() / strtoul() bug in most available libraries. See OS Dev and StackOverflow. Heh.
2009-09-15
The scanf() implementation is coming along well. I was surprised to find that scanf() (which I have seldom if ever used in code myself) is actually much simpler to implement than its printf() counterpart.
2009-09-13
The stdio_rewrite branch is history. It was merged back into trunk as soon as it could do everything the old trunk could (mostly stable output functionality), plus X (mostly stable character and bulk input).
Note that the current implementation is well below my usual quality standards, as for this one time I focussed on "get it running first, bother with details later". There will be much cleaning-up work in days to come, together with the implementation of the scanf() family.
2009-09-11
The implementation for scanf() is still missing, and testdrivers in the printf() function family are failing, but the rest is looking good. (Take this with a grain of salt, I don't have test drivers for everything yet.)
2009-09-09
Commit number [350]... that's 50 commits in three weeks (see entry from 2009-08-19). Basics are done, I am starting to sync branches/stdio_rewrite with trunk so I can merge that branch back not too far into the future.
2009-09-07
I think no-one can really comprehend how much commit [341] means to me. There are lots of errors left in the current code, but from here on it's mere bugfixing and straightforward implementation work. No more trying to figure out how it should work, between changing my son's diapers, playing a game of UNO with my daughter and trying not to neglect my wife.
The interdependent stuff has been resolved. I see a clear road from here to the release of v0.5, this year.
2009-09-05
Detour into malloc(). Some random testing showed that the malloc() test driver reported errors on a 64bit machine. It turned out to be a false alarm, but while figuring that out I reworked the malloc() testing code.
Still ugly overall, but it will be replaced with a "real" malloc() implementation long before v1.0. For now, it gives me some confidence that my memory management is not too wildly off.
2009-09-02
I think I got the errno handling nailed down now. Returning to the buffer and EOF handling in the fillbuffer() / flushbuffer() glue functions, I plan to add prepread() / prepwrite() to seperate sanity checks, buffer pre-reads etc. from the "real" buffer I/O.
Once I get this done (and tested), the rest will be a "piece of cake".
And while we're at it scope-creeping (I thought I'd delay <errno.h> until later), I'll also add example_x86_64 to the supported platforms.
2009-08-30
Gosh, this <errno.h> stuff is indeed, to quote P.J. Plaugher, "a notoriously murky corner of the C language". It's not difficult per se, it's just so contrary to how C is normally done. I am almost sure what I've got in the repository right now has at least two serious flaws...
2009-08-26
After a visit back to the drawing board, I'll finish the basics first: Correct handling of errno, and the low-level functions for <stdio.h>. A project is only as stable as its foundation.
2009-08-23
Too eager, too fast. In my haste to get as many functions as possible "nailed" over the weekend, I think I overextended. It just doesn't make sense poking around in fgets() when I haven't bothered to put some thought into _PDCLIB_fillbuffer() with regards to error and EOF handling.
I'll switch down two gears for the rest of the day and pick up the threads tomorrow.
2009-08-22
And that is what happens when you're bone tired and can't be bothered to look up the function before implementing it. Yes, puts() does append the system EOL after printing the parameter string. fputs(), on the other hand, does not. Commit [312] looks a bit silly now. I'll fix that one, and then it's off to bed...
2009-08-21
Commit [308] yesterday makes me believe I finally solved the buffer handling. I'll focus on more testing now. If the buffering is really resolved, the only thing that still means significant work is the scanf() functionality - and since I have written a functional printf(), scanf() shouldn't be too hard either.
2009-08-20
Biff.
This morning I hacked together some preliminary testing, which showed me that my buffer handling is still completely off.
But it doesn't matter. I immediately saw what I did wrong, the fixes will be easy. This is fun again. After the long standstill, I feel like flying. At supersonic speeds.
I haven't made any anouncements regarding the v0.5 release in a long time, because all those hopes have been dashed. I won't make an anouncement now, either. But if I can continue at this pace, v0.5 might even be released before this year is over.
And good riddance, too. How long have I itched to get to the next step, leaving all that I/O stuff behind me and get working on <ctype.h> and <locale.h> (which will be child's play compared to <stdio.h>...)
2009-08-19, pt. 2
I just made the 300th commit to the PDCLib SVN repository. Happy birthday, PDCLib!
2009-08-19
Half a week later, and while I don't have the amount of time I had during my vacation, I can say that progress does, indeed, continue. In fact, all the "blocks" that hindered me previously are now resolved, in code or in my head. (That was the handling of read/write buffering which required some careful thinking-through, the handling of behaviour undefined in the standard which required me to take a step back from my own quality principles and allow the undefined to happen, and an elegant sollution for ungetc().)
This means I don't see anything but time requirements between now and the release of v0.5.
The downside is that I've used up my vacation for this year, so I'll have to squeeze the coding into the evenings and weekends where I can. Ah well. ;-)
2009-08-16
A year later, and while there's still lots to be done on the house and garden, it looks like we're finally getting somewhere we can take some time off without having a bad conscience about it.
Work has been rather stressful this last year, but I won't bore you with details there.
The good news is: I thought I would never get over that coder's block I had regarding <stdio.h>. But this last week of vacation finally got me working on the library again. It looks as if v0.5 of PDCLib might actually see the light of day.
I hope, though, that this spell of productivity continues once the vacation is over - which is tomorrow already...
2008-06-26
Things on my mind: inheritance tax, mortgage, getting the refurbishment of the house finished, bills payable. Oh, and Germany is in the finals of the Euro2008, which means no PDCLib work done next Sunday, either.
2008-06-10
Many things took priority over continuing work on PDCLib since v0.4.1 - birth of my second kid, death of my mother, a new job and an old house.
But finally: the server is set up, code and tickets migrated, lokal workdirectory cleaned up - I have looked forward to this a long time.
<stdio.h> is still a total mess - since the v0.4 release, I had started over two or three times, and generally made a mess of things because of problems that were only in my mind. Teaches you not to do highly interdependent stuff like that in 30-minute-windows before and after work. :-/
The total time I can dedicate to PDCLib is still at an all-time low, but I got a hunch I will make progress again. I want this v0.5 to happen, and soon, if only because I cannot stand looking at stdio functions anymore. ;-)
