The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Friday, April 28, 2000

“Plan to throw one away. You will anyway … ”

So I'm plugging away at mod_blog, slowly putting the pieces together first into a standalone program, then after that works, start the actual process of writing the Apache module.

What I'm finding is that I have a very large mess on my hands right now. I've developed the pieces pretty much in isolation and I'm finding that wasn't probably the best idea, but since I have no idea what I'm doing anyway, the point might be moot.

What I have right now are the following pieces:

  1. Code to retrieve and store the entries. It works fine, except I'm not all tha thrilled with using Standard C's struct tm to reference entries. It's one of those “it's almost useful but not quite” type problems. The definition of struct tm is:

    int tm_sec;	/* seconds after the minute (0 .. 61*)	*/
    int tm_min;	/* minutes after the hour (0 .. 59) 	*/
    int tm_hour;	/* hours since midnight (0 .. 23)	*/
    int tm_mday;	/* day of the month (0 .. 31)		*/
    int tm_mon;	/* months since January (0 .. 11)	*/
    int tm_year;	/* years since 1900		*/
    int tm_wday;	/* days since Sunday (0 .. 6)		*/
    int tm_yday;	/* days since January 1 (0 .. 365**)	*/
    int tm_isdst;	/* DST flag				*/
    

    * Allows up to two leap seconds.

    ** But the standard doesn't say anything about leap years. Sigh.

    And there are calls to convert struct tm to time_t and back again, but years since 1900? Months since January? What were they thinking? But reading the Standard is helpful. For instance, mktime() takes a struct tm * and returns a time_t. But it also normalizes the values in struct tm * so you can add say, seven days to tm_mday, call mktime() and have the structure renormalized.

    Then there's the problem of comparing dates. The Standard just says that time_t is an arithmetic type, which means it can be either an interger or floating point type. With integer types, you can do meaningful comparrisons for equality, but all bets are off for floating point values.

    Sure, you may think modern floating point hardware can give meaningful results when doing an equivalence comparrison, but you can't really. For instance, sin() is a cyclic function over the range [0 ‥ 2pi] (or is it (0 ‥ 2pi)? I can't remember if [] or () mark inclusive ranges) so that sin(0) == sin(2pi) == sin(4pi) … right?

    #include <math.h>
    #include <stdio.h>
    #include <stdlib.h>
    
    int main(void)
    {
      double pi2   = acos(0.0) * 4.0;	/* 2pi */
      double c     = sin(0.0);
      double a     = 0.0;
      double r;
      double d;
      
      for ( ; ; )
      {
        r = sin(a);
        d = c - r;
        printf("%e\n",d);
        a += pi2;
      }
      return(EXIT_SUCCESS);
    }
    

    I ran that on my system (AMD 586) and well …

    [spc]linus:/tmp>a.out | more
    0.000000e+00
    2.449213e-16
    4.898425e-16
    7.347638e-16
    9.796851e-16
    1.224606e-15
    

    I even tried using the constant 2pi and I got even worse results.

  2. Code to handle what I call tumblers. It's about the sixth or seventh revision of the code and it still isn't quite what I need. Problem here is one of solving a generalized problem. I had this discussion with Mark about the definition of a tumbler. I don't want a fixed separator for a variety of reasons (namely one, user entry. Mark hates user interface so he's like “Just pick a single character and that's that!” But that isn't that for what I want to do. And it's causing problems. Using the same code, I want it to accept

    Genesis.1:15

    and

    2000/4/5.2

    as correct, yet if you type in

    Genesis:1.15

    and

    2000.4.5/2

    Know those are valid but need to be corrected (and in this case, sent a redirect back to the user's browser). I have an idea but it requires changes for it to work. So for now I'm going with what I have. The external interface shouldn't change that much (and knowing Mark, he'll be going “I told you so!”)

    Then again, this is a person who would rather use an embedded operating system for a phone switch to do word processing rather than trust his data to an operating system doesn't even bother with error analysis, like Unix (then again, it's not like Mark does word processing either …)

  3. Code to process HTML templates. What I have works nice, but I'm thinking if I really want the ability to include other chunks in chunks. But that breaks the method I'm using now, since you can only specify a callback, but not a callback with data specified in the HTML chunk.

    I have to think about this one.

So I have the pieces. But it's pretty much a mess right now.

Then again, this is the one I'll be throwing away.

Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.