Request for ISO8601 plugin

[dcantor]

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.

 

[Joe Caverly]

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.

Tnx,
Dave C.

What I would do is

plugin /l iso8601

use the command/function/variable/etc., and then

plugin /u iso8601

I use this method so that I only have one plugin existing in memory, and only when I require it.

Joe

 

[Steve Fabian]

| 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

 

[Charles Dye]

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?

(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.

 

[dcantor]

(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.

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.

 

[Steve Fabian]

| 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

 

[dcantor]

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.

 

[Charles Dye]

@ORD with a negative argument produces strange results.

Definitely a bug; FITNV.

 

[Charles Dye]

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.

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.

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.

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....

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.)

Let me know; ought to be an easy change.

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

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

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.

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?

 

[Steve Fabian]

| ---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

 

[Charles Dye]

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

I don't think you can redirect error messages from a function. Doesn't variable expansion take place before redirection?

 

[Charles Dye]

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".

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.)

 

[Steve Fabian]

| 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

 

[dcantor]

Spaces not considered arg-separators -

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.

Yes, they sure do.

Error messages to file -

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....

I can live without it, but if you can do it, it would help.

Specifying both input- and output formats

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?

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:

%@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.

 

[Charles Dye]

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?

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.

 

[dcantor]

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.

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.

@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

 

[Charles Dye]

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.

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.

 

[w_krieger]

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.

 

[w_krieger]

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.

 

[Charles Dye]

I figure anyone who wants to override QCAL's defaults can create an alias:

alias qcal=*qcal /w:0 /h /3

Actually, that didn't work, so I'm putting up a new build 0.99.1 to fix it.