1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Request for ISO8601 plugin

Discussion in 'Plugins' started by dcantor, Mar 5, 2010.

  1. dcantor

    Joined:
    May 29, 2008
    Messages:
    507
    Likes Received:
    3
    The ISO8601 plugin mentioned in the Support conference needs a way to load functions selectively. In my particular case, I want to load only the new functions, not the ones which replace existing TCC functions.

    Is there a way, Charles? If not, could you invent one, please?

    Tnx,
    Dave C.
     
  2. Joe Caverly

    Joined:
    Aug 28, 2009
    Messages:
    680
    Likes Received:
    8
    What I would do is

    Code:
    plugin /l iso8601
    
    use the command/function/variable/etc., and then

    Code:
    plugin /u iso8601
    
    I use this method so that I only have one plugin existing in memory, and only when I require it.

    Joe
     
  3. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | What I would do is
    |
    |
    | Code:
    | ---------
    | plugin /l iso8601
    | ---------
    | use the command/function/variable/etc., and then
    |
    |
    | Code:
    | ---------
    | plugin /u iso8601
    | ---------
    | I use this method so that I only have one plugin existing in memory,
    | and only when I require it.

    That would be a very significant overhead if within a batch-file loop you
    need both a built-in function and its plug-in overload. You'd be loading and
    unloading the DLL in every iteration. OTOH, Vince has proven that the fewer
    plug-ins are loaded, the faster TCC operates (at least for some earlier
    versions).

    OTOH, the only incompatibility for valid dates between the built-in and the
    plug-in functions is for @agedate and @makeage, and even for those the
    results are the same, but the domain and range of the functions is reduced
    for future dates - the limit is 4000-12-31 @ 23:59:59 instead of 30828-09-14
    @ 02:48:05.477 which is the latest epoch that can be represented in a
    positive 64-bit 2-s complement signed integer, when the scaling is 100ns,
    and 0 represents 1601-01-01 @ 0:0:0.

    Personally, that limitation does not bother me.
    --
    Steve
     
  4. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    (Sorry for the long response time; my employers have been getting their money's worth this week.)

    I know that it is possible; Federico did something like that in his plugin (plugins?) I imagine features can only be disabled at load time, not on-the-fly; though I might be mistaken there.

    On the other hand, replacing built-in functions is the whole idea in this plugin. If there is some serious incompatibility, I'd rather fix it than invent workarounds. Are you finding some problem, or just squeamish about replacing Rex's code with mine? (Can't blame you for that!)

    Offhand, I think my preference might be to enable more functions in the QCAL plugin, rather than changing ISO8601. At the moment, QCAL only supports those new functions which would be useful for user-defined holidays; but that could change easily enough.
     
  5. dcantor

    Joined:
    May 29, 2008
    Messages:
    507
    Likes Received:
    3
    Charles,

    First, no need to apologize for the work-induced delay. I suspect everyone here understands that, but thanks for saying it.

    I agree that my goal would be to completely replace Rex's functions with yours, but there are some undocumented incompatibilities that I would be hard-pressed to describe as bugs. They're more like different undocumented behavior for the same not-quite-documented syntax.
    I need to use the original functions until I get all the discrepancies in my coding resolved.

    1. Rex's functions accept a string of spaces (or tabs) as an equivalent for a comma in separating arguments in functions. The ISO8601 plugin's functions do not, and simply concatenate two arguments into one, causing a parsing error. Cf. the two versions of @MAKEAGE[%_DATE %_TIME] . That was lousy coding on my part, but I've got a ton of 'em and until I get them fixed, I need to use the original functions.

    2. Error messages appear not to be written to the file specified for error output in the .INI file LogErrorsName directive. I specify mine to be the same place as the LogName directive; this makes it easier to find errant coding by examining the log.

    3. I found at least one occurrence of a function requiring a final parameter where Rex's version does not require it. Unfortunately, I didn't make a note of it and don't remember which function it is. (When I find it again, I'll report it.)

    Not a problem, but the HTML page has a misspelling "Regualar" instead of "Regular".

    Would you consider adding a new date conversion (maybe "@CONVDATE") in which you can specify both an input and an output format? The usage would be something like, on a system using format 2 default, there is a format 1 input, and you need output in format 4.
     
  6. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | Would you consider adding a new date conversion (maybe "@CONVDATE")
    | in which you can specify both an input and an output format? The
    | usage would be something like, on a system using format 2 default,
    | there is a format 1 input, and you need output in format 4.

    If you don't mind a bit more coding, another useful conversion would be for
    time, between AM/PM and 24-hour modes, where the AM/PM may be before or
    after the TOD, and may but need not have separating whitespace, and the "M"
    might be dropped, e.g., "a2:15", "2:15 AM", "02:15P". If no letters in the
    parameter, assume 24-hour format for input, and use "hh:mm AM" as output
    format. If "a" or "p" is in the parameter, assume AM or PM input,
    respectively, and ouput in HH:MM. Note that seconds and even milliseconds
    may be in the input, and that the field separator btw. hours and minutes as
    well as between minutes and seconds need not be the colon : - e.g. on my
    system it might be the period. @TIMECONV sounds like a good name... I have
    no objection to separate functions for the two converion directions, but I'd
    consider it quite useful in that case if the output format would also be
    acceptable as input, so @AMPM_to_24HR would accept 23.25.59 as input and
    would return it unchanged. This last feature would make it unnecessary to
    know in advance what time format a particular source has, putting it through
    the converter would yield the user's standard format.
    --
    Steve
     
  7. dcantor

    Joined:
    May 29, 2008
    Messages:
    507
    Likes Received:
    3
    More.

    @ORD with a negative argument produces strange results.

    A negative argument ought to do one of two things (in my arrogant opinion):
    1. Produce an error message or error status, or
    2. Produce a minus sign and space followed by the string that would have resulted if the argument were positive.

    ECHO %@ORD[-1]
    -1st

    @ORD[0] is just fine.
     
  8. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    Definitely a bug; FITNV.
     
  9. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    That looks like it should be a trivial tweak to one parser routine. I want to test it a while before I release it though; trivial parser tweaks sometimes have unexpected repercussions.

    Making it do that might be a major undertaking.... I just write error messages to stderr (mostly; CRLFs go to stdout because TC's color print routines don't like control characters.) And there are a lot of error messages....

    Let me know; ought to be an easy change.

    Got it; thanks. (Propagated to two places in the .CHM.)

    Or would it make more sense to add an optional third parameter to @DATECONV, at the risk of incompatibility with future versions of Take Command?
     
  10. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | ---Quote (Originally by dcantor)---
    | 1. Rex's functions accept a string of spaces (or tabs) as an
    | equivalent for a comma in separating arguments in functions. The
    | ISO8601 plugin's functions do not, and simply concatenate two
    | arguments into one, causing a parsing error. Cf. the two versions
    | of @MAKEAGE[%_DATE %_TIME] . That was lousy coding on my part, but
    | I've got a ton of 'em and until I get them fixed, I need to use the
    | original functions. ---End Quote---
    | That looks like it should be a trivial tweak to one parser routine.
    | I want to test it a while before I release it though; trivial parser
    | tweaks sometimes have unexpected repercussions.

    Rex's parser accepts it because the European setting for the decimal
    separator is the comma. In fact all routines ought to be checked for correct
    input and output formatting for both legal values of the DecimalChar
    directive. I did not check, they may already do it right!

    | ---Quote---
    | 2. Error messages appear not to be written to the file specified
    | for error output in the .INI file LogErrorsName directive. I
    | specify mine to be the same place as the LogName directive; this
    | makes it easier to find errant coding by examining the log. ---End
    | Quote---
    | Making it do that might be a major undertaking.... I just write
    | error messages to stderr (mostly; CRLFs go to stdout because TC's
    | color print routines don't like control characters.) And there are
    | a lot of error messages....

    When error messages only are redirected, would that result in concatenated
    messages, and spurious blank lines in stdout?

    --
    Steve
     
  11. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    I don't think you can redirect error messages from a function. Doesn't variable expansion take place before redirection?
     
  12. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    It might make a good function for a plugin; but not this one, I think. Maybe a general time-functions plugin to do stuff like adding and subtracting seconds/minutes/hours to a time, subtracting times, and doing time-zone and DST conversions.

    (Who the heck puts the A.M. or P.M. in front of the hour? I don't think I've ever seen that done.)
     
  13. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | I don't think you can redirect error messages from a function.
    | Doesn't variable expansion take place before redirection?

    If the function is used in a batch file...
    --
    Steve
     
  14. dcantor

    Joined:
    May 29, 2008
    Messages:
    507
    Likes Received:
    3
    Spaces not considered arg-separators -

    Yes, they sure do.

    Error messages to file -
    I can live without it, but if you can do it, it would help.

    Specifying both input- and output formats
    A third parameter would be better, but I fear a later incompatibility with TCC. If you implement this as a separate function, the default for missing format arguments should be 0 (or, perhaps, 256).

    Proposal:
    Code:
    %@DATECONV[infmt,outfmt,date]
    
    (For a U.S.-based computer, using date format 1)
    
    echo %@dateconv[01-02-03,2,4]
    2003-02-01
    
    echo %@dateconv[01-02-03,2,]
    02-01-2003
    
    echo %@dateconv[01-02-03,,2]
    02-01-2003
    
    Thanks, Charles.
     
  15. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    I'm putting up a new build 0.98.4 with the following changes:

    Parser change: Most functions will now accept an unquoted space, or a series of unquoted spaces, as an argument separator. (Exceptions: @DOWIS, @ISHOLIDAY, @NEXTDOW, @PICKDATE, @ROMAN.)

    @DATECONV: Allow two date formats to be specified -- one for input, the second for output.

    @ORD: Check for negative numbers; handle sanely.

    Changes to error messages: CR/LF now goes to stderr; if error occurs in a batch file, report filename and line number.

    Finally, there is a new, ugly/undocumented/untested hack for disabling features at startup. Before loading the plugin, you can set an environment variable DISABLE_FEATURES containing the names of commands, functions, or variables to disable (sans percent signs.) The variable is checked only at startup, and can be unset as soon as the plugin is loaded. This feature is not described in the docs, and I may change or remove it in future builds.
     
  16. dcantor

    Joined:
    May 29, 2008
    Messages:
    507
    Likes Received:
    3
    Thank you, Charles. That's wonderful.

    I don't quite understand the usage of @DATECONV[date,infmt,]
    without an output format. If %date% is already in, let's say, format 1,
    what's the point of having format 1 output? That seems to be an identity transformation. I guess it's necessary to be compatible with the function in native TCC.

    So I'll suggest for one more function:
    @datetype[date]
    returns a string containing the positive one-digit format numbers for which the date is valid, or 0 if it is not a valid date.
    Code:
    @datetype[2-13-03] would return 1 
    @datetype[31-1-86] would return 2
    @datetype[86-2-28] would return 3
    @datetype[1-2-86] would return 12
    @datetype[1-2-31] would return 13
    @datetype[13-2-03] would return 23 
    @datetype[1-2-3] would return 123 
    @datetype[86-32-12] would return 0
    @datetype[foo] would return 0
    @datetype[2003-1-2] would return 4 
    @datetype[2003-W04-3] would return 5
    @datetype[2003-123] would return 6
    @datetype[2003-456] would return 0
    
     
  17. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    Yah, I just did it that way to be compatible with the existing function. We could just as easily put the output format before the input; but that seems weird somehow. You expect 'input' to come first.

    My guess is that if you only pass one format specifier, then you already know that the input is either (1) in some unambiguous representation, or else (2) in the local date format. It would have to be anyway, to work with the built-in function, right? So if you really want to do anything-Lord-to-anything-Lord, just specify both the input and output formats.
     
  18. w_krieger

    Joined:
    Nov 2, 2008
    Messages:
    176
    Likes Received:
    0
    Plugin functions.

    WORKDAY() returns the "current" workday, or the next monday if this is on the weekend. This could be modified by %2 for a different week style, or %3 to include holidays.

    workday(date M-F) -> date

    workday(S,S) -> next monday.

    workday(date, M+W+F) gives current day, or next day being a monday, wed, or fri. eg "nextwater = %@workday(now, Tue+Thu+Sat)

    Many holidays are usually defined in this manner, eg

    australia_day = workday(*-1-25)
    christmas_day = workday(*-12-25)
    boxing_day = workday((workday(*-12-25)+1))
    proclaimation_day = workday(*-12-28) [SA for boxingday]

    When christmas falls on Sat or Sun

    workday(*-12-25) and workday(*-12-26) both give monday *-1-27. where boxing day falls on Tue *-12-28

    Most AUS holidays are gazetted in this manner.

    Options to store preferred calendar layout etc, in the INI file, so if one prefers calender to start on SUN, then these values could be extracted in place of the default.
     
  19. w_krieger

    Joined:
    Nov 2, 2008
    Messages:
    176
    Likes Received:
    0
    In my formats, i usually support dates greater than the last of the month, and more than 12 months. These simply wrap around, eg

    in YMD format: 1994-14-1 = first of feb 1995.

    1994-1-305 = 305th day of year 1994. I use march-date calendars, so something like 1994-3-xxx gives the long-date i use.

    1900-1-xxxx gives the supposed excel date, while 1904-1-xxxx gives the mac dates. Subtracting a date of the form (now)-(*-3-*) will fill in the *'s based on the days since the last 0 March xxx. eg 2000-01-01 - (*-3-*) would give 1999-3-307, meaning that it would be 307 days into a march date beginning in 1999.
     
  20. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
     

Share This Page