• another convoluted brainteaser for the gurus

    From Richard Webb@1:116/901 to all on Thu Jan 12 13:15:51 2012
    Hello all!


    Some of you batch gurus will be able to point out some
    pitfalls I've missed, but let me explain first what this is
    about.

    I email out a little weekly journal newsletter to a group of ham radio folks I work with, our common interest assisting
    vessels at sea, folks serving their country or faith abroad, etc.

    One thing I've always wanted to implement was a bit of a
    history section, keyed by date. These go out on Sunday
    mornings, of course.

    This batch would run at midnight utc on Sunday of course adn prepare the history information, compiling into it a file
    that the weekly email generator code would find.

    So, taking this Sunday's for example, the batch would look
    in a defined directory for files named 0115.txt; 0116.txt; 0117 ... etc.

    Easy enough done, stuff number of month and day into an env
    var called %NEWS% using HOrst's logecho.
    OF course I'm using HOrst's nset and count, as well as
    ifnumber in this thing.

    The first thing we need to do is see if the date's getting
    toward roll over to next month.
    That one's easy. Check if day of the month is 22 or
    greater.

    IF the date is 22 or greater we then need to create a
    "turnover" file which will be used to create another
    environment variable.

    So here's how we're accomplishing that so far. the fun
    comes once we've defined all this.
    We start the set up for it to do its beautiful work like
    this:


    :: 300hist.bat
    @echo off
    :: desc: This batch is under construction
    :: desc: function: Runs on Sundays 0000 utc or is triggered at that time. :: desc: helps us grab historic trivia for weekly journal
    logecho $D | nset starter=$1
    set checker=22
    ifnumber %STARTER% biggerequivalthan %CHECKER > nul
    if errorlevel 1 goto workit
    :: if starter is bigger or equal to checker we may need to
    :: turn over to a new month. IF not, we just cruise along.


    set starter=
    set checker=
    goto regular
    :workit
    set starter=
    set checker=
    logecho $M | nset bump=$1
    :: now we use HOrst's count to add one.

    count BUMP +1
    set checknum=10
    :: environment variables are stored ignoring leading zeroes
    :: unless you stuff them in. So we set checker to 10 and
    :: test for smaller than, because if %BUMP% os a somg;e
    :: digit we need to add a zero.
    :: we're going to create a file to use to capture
    :: data for the environment variable at turnover of month.
    ifnumber %BUMP% smallerthan %CHECKNUM% > nul
    if errorlevel 1 goto addzero
    goto doit
    :addzero
    set checknum=
    echo 0%BUMP%01 >> bumper.txt
    set bump=
    goto workout
    :doit
    set checknum=
    echo %BUMP%01 >> bumper.txt
    set bump=
    goto workout
    :workout
    cd \working


    :: now we see how many days are in the current month, so
    :: that we turn over at the appropriate place utilizing the
    :: file bumper.txt we created to set the new %NEWS%
    :: env var for the appropriate day's history capture.
    :: we already have repnum.txt with the data inside. HEnce:
    nset repnum=$1 <repnum.txt
    cd \
    logecho $M%REPNUM% >> turnover.txt
    set repnum=
    nset turnover=$1 <turnover.txt
    del turnover.txt

    That's the setup, now let me show in you next msg how this
    works if turnover not needed.

    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From Richard Webb@1:116/901 to all on Thu Jan 12 21:46:00 2012
    HI Folks,

    following up a message from Richard Webb to all:

    One thing I've always wanted to implement was a bit of a
    history section, keyed by date. These go out on Sunday
    mornings, of course.

    This batch would run at midnight utc on Sunday of course adn prepare
    the history information, compiling into it a file
    that the weekly email generator code would find.

    A couple of changes since that post ...

    First, I came to the brilliant realization that when HOrst's count increments or decrements a numeric environment
    variable it's going to nuke the leading 0 if it exists.

    So, we rename all the files for months under 10 such as
    315.* 518.* etc. etc.

    This means we set the %NEWS% environment variable a little
    bit differently as well, by playing with HOrst's count then
    moving it to where we want it, to lose any leading 0 that
    would have been generated.

    AS for what happens with the month turnover, we could lose
    the prepend leading 0 to single digit months code of course, and then use ifnumber to see if %NEWS% and %TURNOVER% are
    equal. IF so, we reset %NEWS% to the date found in
    %TURNOVER%
    and call another batch. Because of this, we also create
    semaphores for each day in the original batch.

    An example, since we'll always have the proper date for
    Sundays we don't need to test for turnover, but on mondays ...
    :chkmon
    count NEWS +1
    ifnumber %NEWS% biggerequivalthan %TURNOVER%
    if errorlevel 255 goto conmon
    if errorlevel 1 goto turnover
    goto conmon
    :conmon
    echo %NEWS% >> c:\hold\work\mon.sem
    call mmsnhist.bat %NEWS%
    if exist c:\hold\work\history.dat goto monhist
    goto chktue

    So, if turnover is reached, we branch to that label, reset
    the env var %NEWS% and call rollhist.bat which checks for
    the flag files, branches, and moves on.

    Still open to suggestions if anybody sees an easier way to
    roll this.


    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From Paul Quinn@3:640/384 to Richard Webb on Fri Jan 13 17:23:00 2012
    Hi! Richard,

    In a message to All you wrote:

    One thing I've always wanted to implement was a bit of a
    history section, keyed by date. These go out on Sunday
    mornings, of course.

    Uh, huh.

    This batch would run at midnight utc on Sunday of course adn prepare
    the history information, compiling into it a file that the weekly
    email generator code would find.

    Okay, I want to look at your system... no scripting at this point...

    The daily files consist of some sort of activity logs? The weeklies consist of
    a compilation for the previous week?

    I would be looking at a system something similar to...

    -----8<-----C-U-T--H-E-R-E----->8-----
    remark: YYYYMMDD.txt is the daily transaction/logging file
    remark: the weekly file weekMMYY.txt is built on-the-fly after each day's logging

    DAILY_LOOP
    LOGGING_LOOP
    YYYYMMDD.txt = [YYYYMMDD.txt + (new activity log entry)]
    END LOGGING_LOOP
    weekMMYY.txt = [weekMMYY.txt + YYYYMMDD.txt]
    archive YYYYMMDD.txt
    kill YYYYMMDD.txt
    END DAILY_LOOP

    WEEKLY_JOB
    post weekMMYY.txt in email
    archive weekMMYY.txt
    kill weekMMYY.txt
    END WEEKLY_JOB
    -----8<-----C-U-T--H-E-R-E----->8-----

    This system probably varies a little from what you intended. Can you explain what I might be missing?

    So, taking this Sunday's for example, the batch would look
    in a defined directory for files named 0115.txt; 0116.txt; 0117 ...
    etc.

    Ermm... shouldn't that be 0108.txt; 0109.txt; 0110.txt... :)

    (With the system I propose, those files won't be necessary. The weekly file would be built-up during the week's daily operations. They would still be available in the relevant archive if something screws up, somewhere.)

    Question. What happens Sunday 5 February, with the 30th & 31st of January's logging? Do they get caught up in "week0212.txt"?

    Cheers,
    Paul.

    ---
    * Origin: !WARNING(205): Power not on. Press any key to continue. (3:640/384)
  • From Richard Webb@1:116/901 to Paul Quinn on Fri Jan 13 12:36:33 2012
    Hell Paul,

    On Fri 2012-Jan-13 17:23, Paul Quinn (3:640/384) wrote to Richard Webb:

    One thing I've always wanted to implement was a bit of a
    history section, keyed by date. These go out on Sunday
    mornings, of course.

    Uh, huh.

    This batch would run at midnight utc on Sunday of course adn prepare
    the history information, compiling into it a file that the weekly
    email generator code would find.

    Okay, I want to look at your system... no scripting at this point...

    The daily files consist of some sort of activity logs? The weeklies consist of a compilation for the previous week?

    I would be looking at a system something similar to...

    DO that with station logs, but this is for the whole group.
    The weekly file is mainly what vessels have used us and
    that's already done.

    There are a couple of sections that prepend all this
    hwoever, and they're built as well to generate this email.
    they're a "welcome newcomers" type section, a logistics, who needs pinch hitters, etc. section, etc.

    <snip>
    So, taking this Sunday's for example, the batch would look
    in a defined directory for files named 0115.txt; 0116.txt; 0117 ...
    etc.

    Ermm... shouldn't that be 0108.txt; 0109.txt; 0110.txt... :)

    (With the system I propose, those files won't be necessary. The

    weekly file would be built-up during the week's daily operations.
    They would still be available in the relevant archive if something
    screws up, somewhere.)

    Yep, had to lose the leading 0 in single digit months anyway because when HOrst's count does its thing it loses it. I'm
    sure you saw that later.

    These are still quite relevant as I might not be around.
    For example, in April the Birthdays of Samuel MOrse, the
    inventor of MOrse Code, and Gugliemo Marconi are both in
    files for those dates.
    So yes, still necessary as these aren't quite logging
    functions per se. That part's already written and working
    great.

    Question. What happens Sunday 5 February, with the 30th & 31st of January's logging? Do they get caught up in "week0212.txt"?

    There's a good example of what I've had to wrestle with for
    this part of it. This thing will go out on January 29, as
    usual, discussing anything of significance for Sunday the
    29th, Monday the 30th, the 31st, Wednesday the 1st, 2nd, 3rd and finally the 4th.
    The "logging" part of this as I say is already done,
    automagically, on the fly. What isn't and has required some manual intervention by me was looking through these little
    text files to find historic trivia to stuff in there. For
    example, had this been built last week it would have noted
    that Thursday the 12th was the 2nd anniversary of the big
    quake in Haiti. A few ham ops really used our network
    services to get help to people who needed it. So that would of course be in 112.txt, (was 0112.txt) and would have been
    automagically posted in last Sunday's history section.
    Except, I never got to looking through those last weekend,
    hence doing the automation shuffle <g..

    HEre's another wrinkle. the batch it calls looks for two
    files. For example, for today it would look in that
    director for 113.all, and 113.txt as well.
    the *.all file of course is retained, it has data we'll want to stuff in next year. the *.txt file will be deleted after it's appended.

    Oh btw, the example i showed yesterday in a subsequent
    message got changed up a bit too. I did the ifnumber test
    before we incremented the environment variable by one, my
    brain woke up and saw I had it in the wrong place, and also
    had the test greater than or equal, or biggerequivalthan as
    he calls it, and wanted "equival" instead.
    YEs I ran it with some testbed stuff and stumbled across
    that one <g>.

    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From Richard Webb@1:116/901 to Paul Quinn on Fri Jan 13 14:12:10 2012
    Hello Paul,

    following up a message from Richard Webb to Paul Quinn:

    I would be looking at a system something similar to...

    DO that with station logs, but this is for the whole group.
    The weekly file is mainly what vessels have used us and
    that's already done.

    There are a couple of sections that prepend all this
    hwoever, and they're built as well to generate this email.
    they're a "welcome newcomers" type section, a logistics, who needs
    pinch hitters, etc. section, etc.

    Meat of this "weekly journal" is made up of info regarding
    vessels who file position and weather reports via our
    network while offshore.
    I'll grab one of those entries from this week and parse it
    to explain. Btw, that code is already written, and working
    pretty darned well. This is year #5 of this journal in fact <g>.

    First, the raw entry in my data file ...


    01/10/2012 01:13 KC2TIU W1CT 12-38.0n 061-21.0w SV TSAMAYA 2 POB

    FIrst you can see that the entry was posted as of 01/10/2012 at 01:13 utc.

    The call sign of the vessel's ham op was kc2tiu. The guy
    who took the data was w1ct.

    So, on Sunday mornings a batch (already created and working) parses each entry in the weekly data file. IT shows readers the last entry we have for kc2tiu, and looks in another file for info about the sailing vessel, such as marine call
    signs, communications capabilities, operator's name, marine
    service call sign if known, etc.

    IN another section of the journal it looks at entries posted by JOhn, w1ct, or other posters. IT then tells readers how
    many reports JOhn took last week, how many over the month,
    how many over the year, and how many since my system started tracking this data. So the "next week in history ... "
    section is just part of this, and the current one under
    development <grin>.




    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From Richard Webb@1:116/901 to Paul Quinn on Tue Feb 7 19:04:13 2012
    HI Paul,

    following up a message from Richard Webb to Paul Quinn:

    Okay, I want to look at your system... no scripting at this point...

    The daily files consist of some sort of activity logs? The weeklies consist of a compilation for the previous week?
    <snip>
    Ermm... shouldn't that be 0108.txt; 0109.txt; 0110.txt... :)
    Yep, had to lose the leading 0 in single digit months anyway because
    when HOrst's count does its thing it loses it. I'm
    sure you saw that later.

    YEp, and it's doing its thing quite nicely.

    Oh, yeah, the main program, it does everything to a file
    which is named "boatweek.lst" which is the email product
    itself.
    Within this is current logistical notes, notes on regular
    net participants, and of course the info regarding vessels
    underway I showed you a sample of, a short humor piece, and
    maybe some additional stats.
    Question. What happens Sunday 5 February, with the 30th & 31st of January's logging? Do they get caught up in "week0212.txt"?

    There's a good example of what I've had to wrestle with for
    this part of it. This thing will go out on January 29, as
    usual, discussing anything of significance for Sunday the
    29th, Monday the 30th, the 31st, Wednesday the 1st, 2nd, 3rd and
    finally the 4th.
    The "logging" part of this as I say is already done,
    automagically, on the fly. What isn't and has required some manual intervention by me was looking through these little
    text files to find historic trivia to stuff in there. For
    example, had this been built last week it would have noted
    that Thursday the 12th was the 2nd anniversary of the big
    quake in Haiti. A few ham ops really used our network
    services to get help to people who needed it. So that would of
    course be in 112.txt, (was 0112.txt) and would have been
    automagically posted in last Sunday's history section.
    Except, I never got to looking through those last weekend,
    hence doing the automation shuffle <g..

    Yep, we do a rollover thing, so that if when the environment variable is incremented we now have the next month, such as
    what happenedon February 29, we now roll it over, invoke a
    different batch which is essentially the same code. It
    played flawlessly on January 29 with the rollover to
    February in midweek, so should do the same for February.

    The whoel thing keys for number of days in a given month off a little text file
    which contains that info which my system
    creates at the beginning of each month. Of course I have to edit it for leap years, since by default it assumes February has 28 days. So, it should be quite happy rolling over as
    it's supposed to when invoked on 2/26.

    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From Paul Quinn@3:640/384 to Richard Webb on Wed Feb 8 09:42:00 2012
    Hi! Richard,

    On Tue, 07 Feb 12, you wrote to me:

    The whoel thing keys for number of days in a given month off a little
    text file which contains that info which my system creates at the beginning of each month. Of course I have to edit it for leap years, since by default it assumes February has 28 days. So, it should be
    quite happy rolling over as it's supposed to when invoked on 2/26.

    You know, I was only thinking about this the other day. I had thought to ask how the doo-hickey had operated during the rollover, and was gonna prompt you.
    I'm glad you got in first. Thanks for the update. :)

    Cheers,
    Paul.

    ---
    * Origin: *Real* programmers use COPY CON MYAPP.ZIP (3:640/384)
  • From mark lewis@1:3634/12 to Richard Webb on Tue Feb 7 22:34:30 2012
    The whoel thing keys for number of days in a given month off a
    little text file which contains that info which my system
    creates at the beginning of each month. Of course I have to edit
    it for leap years, since by default it assumes February has 28
    days.

    you know that you can automatically handle this with a small bit of math, right? i'd have to look at some code to make sure i state it correctly but leap
    years can be determined by current year div 4 but there's also a 400 involved... this is why i need to take a sec later on and look at the real formula... then you can have an array with all of the month days count and automatically adjust FEB when it has 29 days ;)

    )\/(ark


    * Origin: (1:3634/12)
  • From Richard Webb@1:116/901 to Paul Quinn on Wed Feb 8 02:08:02 2012
    Hi Paul,

    On Wed 2012-Feb-08 09:42, Paul Quinn (3:640/384) wrote to Richard Webb:

    The whole thing keys for number of days in a given month off a little
    text file which contains that info which my system creates at the beginning of each month. Of course I have to edit it for leap years, since by default it assumes February has 28 days. So, it should be
    quite happy rolling over as it's supposed to when invoked on 2/26.

    You know, I was only thinking about this the other day. I had
    thought to ask how the doo-hickey had operated during the rollover,
    and was gonna prompt you. I'm glad you got in first. Thanks for
    the update. :)

    YEp, I watched it run first couple weeks, I was pretty sure
    it would operate alright during the rollover, but now I feel safe letting it run when I'm not here to attend it <g>. Had to fix a couple minor errors the first week it ran, but
    nothing fatal, I'm rather proud of myself. That means I'll
    break something really good next time i get to fiddling i
    guess <g>.

    YOu know I was really surprised, as I had a house full of
    stepdaughter and her boyfriend and their zoo going on at the time, which was one reason I was finding something to do
    that would keep them away from me. If I was doing a lot of
    radio they'd be in here doing the "hey wow cool ... " thing, but programming, they'd leave me alone, she's mouse potato
    gui only, and he's not literate enough to even handle that
    one, so I figured I'd leave them with their version of Jerry Springer dealing with her mother in the other room and bury
    myself in a programming project.

    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From Paul Quinn@3:640/384 to Mark Lewis on Wed Feb 8 15:22:00 2012
    Hi! mark,

    In a message to Richard Webb you wrote:

    edit it for leap years, since by default it assumes February has
    28 days.

    you know that you can automatically handle this with a small bit of
    math, right? i'd have to look at some code to make sure i state it correctly but leap years can be determined by current year div 4 but there's also a 400 involved...

    I think the 400 test is for century years, like: 1900, 2000, 2100 & so on.

    this is why i need to take a sec later
    on and look at the real formula... then you can have an array with
    all of the month days count and automatically adjust FEB when it has
    29 days ;)

    How about a bit of something in some old Turbo-C...

    --- 8< ---
    int leap_yr_test(int test_yr)
    /*
    function determines if a given year is a leap year
    Uses: 'test_yr' which is defined prior to function call
    Pre: none
    Post: a boolean value is returned indicating TRUE/FALSE
    */
    {
    /* local variables */
    int result = FALSE;

    switch (test_yr % 100)
    {
    case 0 : if ((test_yr % 400) == 0) result = TRUE; break;
    default : if ((test_yr % 4) == 0) result = TRUE;
    }
    /* end switch. */
    return(result);
    }
    /* end function. */
    --- 8< ---

    =:)

    Cheers,
    Paul.

    ---
    * Origin: If it itches, it will be scratched. (3:640/384)
  • From Paul Quinn@3:640/384 to Richard Webb on Wed Feb 8 15:56:00 2012
    Hi! Richard,

    On Wed, 08 Feb 12, you wrote to me:

    even handle that one, so I figured I'd leave them with their version
    of Jerry Springer dealing with her mother in the other room and bury myself in a programming project.

    I've gone one better, and have moved downstairs again for summer. (The house is a 100-odd year old place, high-set, where the huge shady area downstairs is about 5-6 degrees cooler than 'up there'... and away from the womenfolk.)

    These days I tend to play a lot with various virtual machines. Most of the older DOS ones don't get used but the Windows ones, except the WinXP box, run pretty much 24/7. Check out...

    http://members.dodo.com.au/~colgilly/hideaway/Page.html (for some of them.)

    I've recently commenced work on another Linux vBox (Xubuntu v11.10) which will eventually replace the two Win98 vBoxen and hopefully one of the Linux vBoxes as well. There's never enough time in the day 'cause if I'm not actually tinkering then I'm reading & researching.

    Cheers,
    Paul.

    ---
    * Origin: Any day spent above ground is a good one. (3:640/384)
  • From Richard Webb@1:116/901 to mark lewis on Wed Feb 8 13:54:06 2012
    HI Mark,

    On Tue 2012-Feb-07 22:34, mark lewis (1:3634/12) wrote to Richard Webb:

    The whoel thing keys for number of days in a given month off a
    little text file which contains that info which my system
    creates at the beginning of each month. Of course I have to edit
    it for leap years, since by default it assumes February has 28
    days.

    you know that you can automatically handle this with a small bit of
    math, right? i'd have to look at some code to make sure i state it correctly but leap years can be determined by current year div 4 but there's also a 400 involved... this is why i need to take a sec
    later on and look at the real formula... then you can have an array
    with all of the month days count and automatically adjust FEB when
    it has 29 days ;)

    YEp, knew about the divisible by four part, just hadn't
    played with that in the code that runs Feb 1 yet. Would
    like to see that other formula when you find it. I'm sure
    we could plug it in. TImo's batch calculator does some
    interesting things.

    Think I'd heard of the other one too, but was thinking about the divisible by 4
    bit, just hadn't implemented that one
    <g>.

    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From Richard Webb@1:116/901 to Paul Quinn on Wed Feb 8 13:57:33 2012
    HI Paul,

    On Wed 2012-Feb-08 15:22, Paul Quinn (3:640/384) wrote to Mark Lewis:

    Hi! mark,

    edit it for leap years, since by default it assumes February has
    28 days.

    you know that you can automatically handle this with a small bit of
    math, right? i'd have to look at some code to make sure i state it correctly but leap years can be determined by current year div 4 but there's also a 400 involved...

    I think the 400 test is for century years, like: 1900, 2000, 2100 &
    so on.

    Think you might be right, I'm pre coffee at the moment but
    that sounds right.

    this is why i need to take a sec later
    on and look at the real formula... then you can have an array with
    all of the month days count and automatically adjust FEB when it has
    29 days ;)

    How about a bit of something in some old Turbo-C...

    --- 8< ---
    int leap_yr_test(int test_yr)
    /*
    function determines if a given year is a leap year
    Uses: 'test_yr' which is defined prior to function call
    Pre: none
    Post: a boolean value is returned indicating TRUE/FALSE
    */
    {
    /* local variables */
    int result = FALSE;

    Ah so if one were to compile that does it give you an
    errorlevel if true and another if false?
    test_yr easy to define, especially as an environment
    variable as in
    logecho $C$Y | nset test_yr=$1
    USes HOrst's logecho and nset.

    switch (test_yr % 100)
    {
    case 0 : if ((test_yr % 400) == 0) result = TRUE; break;
    default : if ((test_yr % 4) == 0) result = TRUE;
    }
    /* end switch. */
    return(result);
    }
    /* end function. */
    --- 8< ---

    =:)

    INteresting!

    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From Richard Webb@1:116/901 to Paul Quinn on Wed Feb 8 14:04:19 2012
    Hi Paul,

    On Wed 2012-Feb-08 15:56, Paul Quinn (3:640/384) wrote to Richard Webb:

    even handle that one, so I figured I'd leave them with their version
    of Jerry Springer dealing with her mother in the other room and bury myself in a programming project.

    I've gone one better, and have moved downstairs again for summer.
    (The house is a 100-odd year old place, high-set, where the huge
    shady area downstairs is about 5-6 degrees cooler than 'up there'...
    and away from the womenfolk.)

    Except for my lady I finally got them moved out a couple
    weeks ago. Too much crazy for me.

    These days I tend to play a lot with various virtual machines. Most
    of the older DOS ones don't get used but the Windows ones, except
    the WinXP box, run pretty much 24/7. Check out...

    http://members.dodo.com.au/~colgilly/hideaway/Page.html (for some
    of them.)

    Sounds like you're having fun. I'm busy with lots of radio
    projects still, trying to sell some equipment to regroup the business scaled down a little bit, with hopes of returning
    to New Orleans this summer.


    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From mark lewis@1:3634/12 to Paul Quinn on Wed Feb 8 14:49:23 2012
    this is why i need to take a sec later on and look at the real
    formula... then you can have an array with all of the month days
    count and automatically adjust FEB when it has 29 days ;)

    How about a bit of something in some old Turbo-C...

    pretty neat... but it looks like it is missing something...

    function leapyear( year : integer) : boolean;
    { Returns true if YEAR is a leaplear
    A year is a leap year if it is evenly divisible
    by 4 except :
    if it is divisible by 100 then :
    it is NOT a leap year unless it is divisible
    by 400 but not 4000

    Thus 2000 (divisible by 400 but not by 4000) is a leap year
    but 4000 (divisible by 4000) is NOT a leap year.
    Reference : Introductory Astronomy and Astrophysics, page 61
    By E. v. P. Smith and K. C. Jacobs - (C) 1973 W. B. Saunders Co.}

    { By Jud McCranie, Jan. 4, 1987 }
    { Revised Jan. 5, 1987 }

    begin
    leapyear := (year mod 4 = 0);

    if year mod 100 = 0
    then leapyear := (year mod 400 = 0) and (year mod 4000 > 0);

    end; {*** leap year ***}


    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to Richard Webb on Wed Feb 8 14:53:59 2012
    YEp, knew about the divisible by four part, just hadn't
    played with that in the code that runs Feb 1 yet. Would
    like to see that other formula when you find it. I'm sure
    we could plug it in. TImo's batch calculator does some
    interesting things.

    i just posted pascal code for it... the modulo arithmetic (aka clock math) routine is needed for ease of coding... the full explanation of how to determine a leapyear is contained in the comments at the start of the code i posted...

    )\/(ark


    * Origin: (1:3634/12)
  • From Richard Webb@1:116/901 to mark lewis on Wed Feb 8 22:12:47 2012
    Hi Mark,

    On Wed 2012-Feb-08 14:53, mark lewis (1:3634/12) wrote to Richard Webb:

    YEp, knew about the divisible by four part, just hadn't
    played with that in the code that runs Feb 1 yet. Would
    like to see that other formula when you find it. I'm sure
    we could plug it in. TImo's batch calculator does some
    interesting things.

    i just posted pascal code for it... the modulo arithmetic (aka clock
    math) routine is needed for ease of coding... the full explanation
    of how to determine a leapyear is contained in the comments at the
    start of the code i posted...

    YEp, now if I had the compiler I'd compile it. We'll ahve
    to bounce this around some more <g>.

    Btw my error when I commented divisible by 400 isntead of
    100, pre coffee <g>.

    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From Paul Quinn@3:640/384 to Mark Lewis on Thu Feb 9 11:28:00 2012
    Hi! mark,

    On Wed, 08 Feb 12, you wrote to me:

    How about a bit of something in some old Turbo-C...
    pretty neat... but it looks like it is missing something...

    Not just neat! It was a part of a programming assignment that helped me win an
    'honours' pass for the language at a tech college... 20-something years ago. However...

    function leapyear( year : integer) : boolean; { Returns true if YEAR
    [ ...trim... ]
    Reference : Introductory Astronomy and Astrophysics, page 61
    By E. v. P. Smith and K. C. Jacobs - (C) 1973 W. B. Saunders Co.}
    { By Jud McCranie, Jan. 4, 1987 } { Revised Jan. 5, 1987 }

    Now, that's neat. ;-) I didn't have that reference available and was only able to verify date information from an encyclopedia, with a table that covered
    from 1582 to 3099. That was sufficient for the assignment (and was probably another bonus point in my favour, as I was the only one in the class to verify the output thusly). Even though the tutor was an amateur mathematician he didn't want to belabour the point with a bunch of rowdy, smelly students who were only in it for the computing credits.

    Cheers,
    Paul.

    ---
    * Origin: This tagline made from 100% recycled electrons. (3:640/384)
  • From Paul Quinn@3:640/384 to Richard Webb on Thu Feb 9 11:58:00 2012
    Hi! Richard,

    On Wed, 08 Feb 12, you wrote to me:

    How about a bit of something in some old Turbo-C...

    --- 8< ---
    int leap_yr_test(int test_yr)
    /*
    function determines if a given year is a leap year
    Uses: 'test_yr' which is defined prior to function call
    Pre: none
    Post: a boolean value is returned indicating TRUE/FALSE
    */

    Ah so if one were to compile that does it give you an errorlevel if
    true and another if false? test_yr easy to define, especially as an environment variable as in
    logecho $C$Y | nset test_yr=$1 USes HOrst's logecho and nset.

    Nah. It's only a 'function' stub. You would need to wrap a main program section around it, and call the function.

    Have a look at a couple of other utils from Horst's archive. There's one that might simplify the job called "what.com". Another one that might help is "isdate.com". I haven't played with either, so caveat emptor. ;-)

    Cheers,
    Paul.

    ---
    * Origin: In CyberSpace, no one can hear you scream. (3:640/384)
  • From Richard Webb@1:116/901 to Paul Quinn on Thu Feb 9 07:29:57 2012
    HI Paul,

    On Thu 2012-Feb-09 11:58, Paul Quinn (3:640/384) wrote to Richard Webb:

    How about a bit of something in some old Turbo-C...

    --- 8< ---
    int leap_yr_test(int test_yr)
    /*
    function determines if a given year is a leap year
    <snip>
    Ah so if one were to compile that does it give you an errorlevel if
    true and another if false? test_yr easy to define, especially as an environment variable as in
    logecho $C$Y | nset test_yr=$1 USes HOrst's logecho and nset.

    Nah. It's only a 'function' stub. You would need to wrap a main
    program section around it, and call the function.

    Have a look at a couple of other utils from Horst's archive.
    There's one that might simplify the job called "what.com". Another
    one that might help is "isdate.com". I haven't played with either,
    so caveat emptor. ;-)

    I've looked at those, but not with an eye toward this. I
    get over this creeping crud I'll have to do that.

    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From Richard Webb@1:116/901 to Paul Quinn on Thu Feb 9 14:45:57 2012
    HI Paul,

    following up a message from Richard Webb to Paul Quinn:

    <snip>

    Have a look at a couple of other utils from Horst's archive.
    There's one that might simplify the job called "what.com". Another
    one that might help is "isdate.com". I haven't played with either,
    so caveat emptor. ;-)

    Just had a look at what.com from HOrst, used Timo's level to test waht it does when given the command

    "what year"

    Since we're 2012 it returned 112. <hmmm> That might be
    worth a look.

    When my daily batch invokes first of month batch and we're
    at February 1 we can always call a batch which runs wht.com, checks for errorlevels.
    I'd have to set 'em up as

    if errorlevel 140 goto leap
    if errorlevel 139 goto normal
    if errorlevel 137 goto normal
    if errorlevel 136 goto leap

    etc. on down. If we go to normal it dumps the number 28 in
    that little text file we'll use at the end of the month, and at different times
    during the month to see how many days
    we've got and plug it into an environment variable when
    necessary.

    I've got a eyar to play with that one, but I think that'll
    do it!

    Thanks for reminding me of those. I use some other tools
    for handling day of the month, so never really looked at
    either one that closely. I've got all of HOrst's little
    tools on my dos path though, and the documentation handy,
    just because i know there will be just the occasion when
    they're the right tool <g>.




    Regards,
    Richard
    ---
    * Origin: (1:116/901)
  • From Paul Quinn@3:640/384 to Richard Webb on Fri Feb 10 14:58:00 2012
    Hi! Richard,

    On Thu, 09 Feb 12, you wrote to me:

    Just had a look at what.com from HOrst, used Timo's level to test
    waht it does when given the command

    "what year"
    [ ...trimmed... ]
    I've got a year to play with that one, but I think that'll
    do it!

    I had in mind something simple, like...

    -+- 8< ---
    WHAT day
    IF ERRORLEVEL 1 GOTO NEWMONTH

    :NEWMONTH
    :: Do your processing for a following new month...
    --- 8< ---

    That way it doesn't matter what month, or whether the year is a leap year or not, it just does a new week's worth of post-able notes over the rollover period.

    Thanks for reminding me of those. I use some other tools
    for handling day of the month, so never really looked at
    either one that closely. I've got all of HOrst's little
    tools on my dos path though, and the documentation handy,
    just because i know there will be just the occasion when
    they're the right tool <g>.

    Me too. I'm looking for something to use ISDATE with now... there must something I can invent... It looks too groovy to leave it alone. ;-)

    Cheers,
    Paul.

    ---
    * Origin: Smash forehead on keyboard to continue... (3:640/384)
  • From Richard Webb@1:116/901 to Paul Quinn on Fri Feb 10 13:45:04 2012
    HI Paul,

    On Fri 2012-Feb-10 14:58, Paul Quinn (3:640/384) wrote to Richard Webb:

    I've got a year to play with that one, but I think that'll
    do it!

    I had in mind something simple, like...

    -+- 8< ---
    WHAT day
    IF ERRORLEVEL 1 GOTO NEWMONTH

    :NEWMONTH
    :: Do your processing for a following new month...
    --- 8< ---

    Take care of all that with a process that runs once a day,
    does some specifics for what day of the week, gets the day
    of the month, does some other things accordingly.

    When we roll over to a new month on the first we capture how many days it has for other reasons anyway, so that capture
    is used in this little history thing that runs 0000 utc
    Sunday morning.

    I use days in the month, again at the end of the month to
    average how many vessels logged per day, posts in a couple
    of echoes/newsgroups, etc.

    Were I building such a system from scratch though I'd
    probably look at something such as you showed there.

    That way it doesn't matter what month, or whether the year is a leap
    year or not, it just does a new week's worth of post-able notes over
    the rollover period.

    Still would because of the way I end up doing things around
    here.

    Regards,
    Richard
    ---
    * Origin: (1:116/901)