Features Recently Added To Daytona

transparent caching of expensive functions
// comments
getopt
DS Resync
DS Clean
local_date_clock_for()
INT(_huge_), UINT(_huge_), HEKINT(_huge_)
Bit Operations
typed_like
Regular Expression Extensions
Declarative Predicates


transparent caching of expensive functions

The transparent caching of expensive functions by means of associative array defaults is now supported. Here is a test query:

local:
    INT .zzz = 11
 
    DATE ARRAY[ INT .iii, DATE .ddd  ] .yy = { ? => ggg(.iii+2,.ddd,.zzz) }
 
    TUPLE[ DATE, DATE ] ARRAY[ INT .iii, DATE .ddd  ] .xx
            = { ? => [ ggg(.iii+2,.ddd,.zzz), ggg(.iii+4,.ddd,.zzz) ] }
 
do Write_Line( "This is dynara.g.Q" );
 
_Say_Eq( @<.yy[ 8, ^3-1-99^ ]>@, ^1999-03-22^ );
 
_Say_Eq( @<.xx[ 8, ^3-1-99^ ]#1>@, ^1999-03-22^ );
_Say_Eq( @<.xx[ 8, ^3-1-99^ ]#2>@, ^1999-03-24^ );
 
define DATE FUN( INT .x, DATE .y, INT .z ) ggg
{
    return( .y+.x+.z );
}

C++ style double-slash comments from-here-thru-next-end-of-line are now supported.

Back To Top



getopt

STR getopt( STR .options )
takes a STR of command line option flags as defined by the user in accordance with the POSIX command syntax standard (see intro(1)). As getopt is called repeatedly, it returns the next option flag in the command line for the current executable invocation. It returns "" when there are no flags left that haven't been visited. Here is an excerpt from getopt.1.IQ:

 while( getopt( "ab:c:d" ) != "" )
 {
	 switch( .opt )
	 {
		 case( = "a" )
		 {
			 do Write_Line( "Found -a" );
		 }
		 case( = "b" )
		 {
			 do Write_Words( "Found -b", .optarg  );
		 }
		 . . .
	 	case( = "?" )
		 {
			 do Write_Words( "Found bad flag", .optopt  );
		 }
	 }
 }

The Cymbal getopt is implemented using its cousin getopt(3C). The + arguments that Daytona automatically supports for executables are appropriately ignored for the purposes of getopt. getopt operations are handled completely independently of _cmd_line_ work.

Back To Top

DS Resync

Resynchronizing Applications

To get a project, if any, and applications back in sync again, use DS Resync. In particular, to sync up just one application, execute DS Resync <app> to cause Daytona to rebuild all of its derived files for application <app> and use DS Resync - to sync them all up. In general, the DS Resync usage is:

 
   DS Resync [ [ -i{ndices} | -o{bjects} ]  | -cyd{_mod_tm} ]
		 [ -create | -truncate | -clean_slate ]   [ <app_seq> | - ]

If applications are specified, then application regeneration is done in addition to any project regeneration. The -i option causes all record class indices in the applications given to be redone. The -o option causes all Tracy-generated RECORD_CLASS I/O .c and .h files to be generated and compiled again. In addition, all of the system- maintained *.env.c are recompiled as well as the *.c that are specified using FILE_BASE under the MAKE_GOODS subtree in all corresponding apd's. Lastly, under -o, all of the system-maintained * .env.cy are reprocessed. In short, under -o, all of a project's and/or application sequence's derived code files are rederived. The -cyd (for Cymbal description) option causes the modification times of all pjds, apds and rcds to be made equal to the current time. Any -create, -truncate, or -clean_slate options are passed on to any Sizup call generated by Resync where they appear after $DS_FLAGS $DS_ZFLAGS. DS Resync is a good thing to do in response to hearing that a new Daytona release has been installed:

Caveat: The most common way by far for users to cause Daytona to generate error messages is to attempt to work with a new Daytona release in an environment containing files generated by a previous release of Daytona. So, whenever a new release of Daytona is installed on your system, please run DS Resync on all of your applications. Usually, you will not have to rebuild the indices and so usually, running `DS Resync -obj -' will be fine. Check the release notification message you receive from the Daytona support team to see if index rebuilding is necessary.

Application Derived-file Cleanup

To simply remove all of the index files and RECORD_CLASS I/O files for an application, execute "DS Clean <app>". In general, DS Clean usage is:

	  DS Clean  [ -i{ndices} | -o{bjects} ]   [ <app_seq> | - ]

DATE_CLOCK FUN( DATE_CLOCK .utc_dc, STR .tz = _this_tz_ ) local_date_clock_for

The first argument is a DATE_CLOCK that is taken to be a UTC time point, where UTC is the (surprising) acronym for Universal Coordinated Time, formerly known as Greenwich Mean Time. If the second argument is the default _this_tz_, then the function returns the corresponding DATE_CLOCK for the timezone corresponding to the machine that the executable is running on. More precisely, it corresponds to the localtime associated with the value of the TZ variable in the shell environment that the executable is being run in. Optionally, the user can provide a TZ value as the second argument to the function at which point the function will return the local DATE_CLOCK corresponding to the UTC DATE_CLOCK and the TZ value offered as the second argument.

The official documentation for acceptable TZ values for your platform can be found in the man pages for tzset, localtime, or environ. Pretty much, the different platforms conform to the POSIX standard and will be consistent with the following description. If the first character of the TZ string is a colon, then the interpretation is implementation or system dependent. On Sun Solaris, this means that the value can be any path found in /usr/share/lib/zoneinfo. For Linux, it can be any path under /usr/share/zoneinfo or /usr/lib/zoneinfo. SGI does not apparently provide any implementation meaning for TZ values beginning with colon. As an example, a Solaris TZ value of US/Eastern corresponds to the Eastern timezone of the United States. Of more general utility is the case where the user themselves create their own timezone specifications as values for TZ (or for the second argument of local_date_clock_for). Quoting from the Linux manual,

The  value  of TZ can be one of three formats.  The first format is used when there
is no daylight saving time in the local time zone:

	  std offset

The std string specifies the name of the time zone and must be three or more alpha-
betic characters.  The offset string immediately follows std and specifies the time
value to be added to the local time to get Coordinated Universal Time  (UTC).   The
offset  is  positive if the local time zone is west of the Prime Meridian and nega-
tive if it is east.  The hour must be between 0 and 24, and the minutes and seconds
0 and 59.

The second format is used when there is daylight saving time:

	  std offset dst [offset],start[/time],end[/time]

There  are  no spaces in the specification.  The initial std and offset specify the
standard time zone, as described above.  The dst string and offset specify the name
and  offset  for  the  corresponding  daylight savings time zone.  If the offset is
omitted, it defaults  to one hour ahead of standard time.

The start field specifies when daylight savings time goes into effect and  the  end
field  specifies  when  the change is made back to standard time.  These fields may
have the following formats:

Jn     This specifies the Julian day with n between 1  and  365.   February  29  is
	  never counted even in leap years.

n      This  specifies  the  Julian  day  with n between 1 and 365.  February 29 is
	  counted in leap years.

Mm.w.d This specifies day d (0 <= d <= 6) of week w (1 <= w <= 5) of month m (1  <=
	  m  <= 12).  Week 1 is the first week in which day d occurs and week 5 is the
	  last week in which day d occurs.  Day 0 is a Sunday.

The time fields specify when, in the local time currently in effect, the change  to
the other time occurs.  If omitted, the default is 02:00:00.
For example, the most complete setting for New Jersey in 1986 could be
    EST5EDT4,116/2:00:00,298/2:00:00
or simply
    EST5EDT .
An example of a southern hemisphere setting such as the Cook Islands could be
    KDT9:30KST10:00,63/5:00,302/20:00 .

The INT(_huge_) type implements 64-bit integers. When summing integer quantities over gigabytes, 32 bits is sometimes not enough. Likewise, UINT(_huge_) and HEKINT(_huge_) are available.

For the INT type, Cymbal now supports:

--  one's complement (unary) and relative complement (binary)
++  bitwise or
**  bitwise and
%%  bitwise exclusive or
<<  left shift
>>  right shift

Here is how to define a variable to have the same type as the Number FIELD of a SUPPLIER RECORD, whatever that may be.

define CLASS SUPPLIER subclass_of RECORD
local: typed_like SUPPLIER.Number  .x

The following can appear in regular expressions now:

\d     shorthand for a decimal digit between 0 and 9
\D     shorthand for anything but a decimal digit between 0 and 9
\l     shorthand for a lower- or upper-case letter.
\L     shorthand for anything but a lower- or upper-case letter.
\s     shorthand for a space, \t, \n, \f, \r, \b.
\S     shorthand for anything but a space, \t, \n, \f, \r, \b.
\w     shorthand for a lower- or upper-case letter, digit or underscore.
\W     shorthand for anything but a lower- or upper-case letter, digit or underscore.

The first step on the way to views is the declaratively-defined predicate, as illustrated by

define PRED: Supplies[ .x, .y ]
    iff(
        there_is_a  SUPPLIER named .x where( Number = .x_nbr )
        and there_is_an  ORDER where( Supp_Nbr = .x_nbr and Part_Nbr = .y_nbr )
        and there_is_a  PART named .y where( Number = .y_nbr )
    )