User Tools

Site Tools


pdclib:blog

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
pdclib:blog [2020/04/02 07:24]
solar
pdclib:blog [2021/10/07 15:53] (current)
solar
Line 2: Line 2:
  
 Here I jot down thoughts, roadmaps, to-do's and other things related to [[pdclib:start | PDCLib]]. Newest entry first. Here I jot down thoughts, roadmaps, to-do's and other things related to [[pdclib:start | PDCLib]]. Newest entry first.
 +
 +==== 2021-10-07 ====
 +
 +This past month seemed a lot longer than a month. There had been productivity elsewhere, new professional challenges, and some private heartbreak.
 +
 +No progress on the library though. I hope this is excusable.
 +
 +==== 2021-09-09 ====
 +
 +The reimplementation is online. Please //do// pull the new version. I am a bit embarrassed at the poor quality of the previous attempt, and how long it took me to actually realize.
 +
 +==== 2021-09-06 ====
 +
 +Turns out my ''printf( "%a" )'' support was (is) not only inefficiently implemented, but also bugged in multiple ways. I am in the process of reimplementing the whole thing in a bit more robust way.
 +
 +==== 2021-08-14 ====
 +
 +I decided to shut down the Subversion repository (which had been the master repo until now). I still consider Subversion to be the better option for a small project like PDCLib, but I guess it is time to move on. I basically need the practice with Git, so... yea.
 +
 +==== 2021-08-08 ====
 +
 +Technically it is not that much, but it feels like a huge step forward -- PDCLib now supports printing floating point values using the ''%a'' conversion specifier.
 +
 +Why this weird specifier that is not used by anybody out there? Because it is the one that works without changing the base of the mantissa, i.e. this is the one format that avoids all the issues of the other FP conversions. And //having// the ability to print //some// kind of FP output will help immensely when debugging the other conversions.
 +
 +==== 2021-07-12 ====
 +
 +Back in the groove with a new employer. In pursuit of floating point support, I pulled apart the rather monolithic ''_PDCLIB_print.c'' and did some cleanups.
 +
 +Big integer support is mostly done,so I can try my hand at implementing the Dragon algorithm for float support in ''printf()''.
 +
 +==== 2021-04-12 ====
 +
 +Sorry for the long silence. An opportunity has opened up for me employment-wise which, however, requires my full attention.
 +
 +I hope to return to PDCLib by mid '21.
 +
 +==== 2020-10-25 ====
 +
 +I was asked to add floating point support to my ''printf()'' function family. I have been looking into the Dragon4 algorithm, which seems to be "the thing to do" here. This requires some bigint support for the high-precision conversions; I have started to add functions to that end.
 +
 +==== 2020-10-23 ====
 +
 +Two functions in stdio() (fread(), fgetpos()) did not handle ungetc()'ed characters correctly. Fixed.
 +
 +==== 2020-08-03 ====
 +
 +I erased my previous work on tzcode, and started anew. This time, I kept the original mostly untouched for the initial setup (instead of trying to refactor major parts of it as I go, the way I tried in the first go). This means that, at this point, I got a lot of code in the PDCLib repo that is... well... unkempt. Also, no documentation. But the ''<time.h>'' functions work now, even if the testing is rudimentary. For one, the local time function tests will fail in different time zones, because I cannot set a specific time zone for the test yet...
 +
 +This is a dirty hack, but it gives me a base from which to refactor ''functions/_tzcode'' till it feels like a true part of PDCLib.
 +
 +==== 2020-07-24 ====
 +
 +The last two months had been... unsavory. I had a lot of things on my hands, and unfortunately had to drop the ball on PDCLib for some time.
 +
 +I've returned to the keyboard though. The current work will take some more polish before being checked in, but I am confident that I tackled the tzcode issue from the correct angle this time.
 +
 +==== 2020-05-29 ====
 +
 +Well, that was to be expected. In my effort to untangle the internal data flows of tzcode, I have painted myself into a corner. Nothing serious really, but something that requires a couple hours of uninterrupted focus. Which is hard to come by currently... I hope to get this done over the long weekend.
 +
 +==== 2020-04-23 ====
 +
 +I've made inroads on [[https://data.iana.org/time-zones/tz-link.html|tzcode]], using it as a basis and reference for reading the Olson database for time zone and leap second information, in order to (you guessed it) provide actually functional implementations of the ''<time.h>'' functions.
 +
 +As opposed to ''dlmalloc'', which I assimilated more or less unchanged into PDCLib so it serves as its ''malloc'' / ''free'' implementation, tzcode requires a bit more work. I am not adopting the code, but more or less am rewriting the functionality along its general lines. I might get into some more detail on the why and how when I am satisfied that I am on the right track; right now I am still testing the waters so to speak.
 +
 +Progress has slowed a bit toward the end of the holidays; both work and real life have caught up with me again. But my partner has shown a remarkable interest in what I'm doing with PDCLib, and I guess that will keep me doing it whenever time allows. 8-)
 +
 +==== 2020-04-07 ====
 +
 +See that <del>strike-through text</del> in the previous entry? I went ahead and implemented that change anyway, because I was a bit fed up that types kept being "a bit off" whenever I switched platform. For the record, I am working on-and-off on either a desktop, a netbook (both x86_64 Linux), a Raspberry Pi (ARM Linux), my mobile (ARM Android, and yes, I //am// actually working on that at times), and more recently I got a Windows laptop (for home office work) which allowed me to double-check x86_64 Cygwin, MinGW 32 and 64bit compilations. Which had apparently stopped working some time ago because the types weren't set up correctly by ''_PDCLIB_config.h''. It was time to do an overhaul of the whole type handling.
 +
 +One thing that had bugged me (pun intended) for a long time was that I originally implemented the ''leastN_t'' types in terms of the exact-width ''intN_t'' types. That was bass-ackward because the latter are optional and the former aren't. I also did rely on ''_PDCLIB_config.h'' being set up "just right" instead of using compiler predefines, and of course manual setup gets it wrong from time to time.
 +
 +So I sat down, wrote little test programs, and ran those on //all// the platforms at my disposal to figure out what was actually required. I also made an overview of what GCC / clang provided (which is //almost// identical across platforms and compilers, but not completely). This was not only for the types mentioned above, but (because that was what I was //originally// working on) for ''clock_t'' and ''time_t'' as well. For obvious reasons, these have to fit the types used by the platform API.
 +
 +In the end this necessitated a complete rework of all the files affected -- ''_PDCLIB_config.h'', ''_PDCLIB_int.h'', ''stdint.h'', and ''inttypes.h''. It took a while to figure out what actually belonged where, and how the logic could work out, but I think I got it right eventually. Should any problems occur at your end due to this change, please tell me so I can adjuct the screws.
 +
 +But right now it's 4 AM. I am happy this is checked in, but I am even more happy to go to bed now. I guess I will take a break tomorrow (today?) and enjoy a day of //real// vacation for a change.
  
 ==== 2020-04-01 ==== ==== 2020-04-01 ====
pdclib/blog.1585805060.txt.gz ยท Last modified: 2020/04/02 07:24 by solar