functions in std.i - p


    pc_primitives, file  

sets FILE primitive data types to be native to IBM PC.  
Interpreted function, defined at i0/std.i   line 2937  




roughly 3.14159265358979323846264338327950288  
Keyword,  defined at i0/std.i   line 598  



    plug_dir, dirname  

causes plug_in to look in DIRNAME for dynamic library files, in  
addition to Y_HOME/lib.  DIRNAME may be an array of strings to  
search multiple directories.  
Builtin function, documented at i0/std.i   line 2391  

SEE ALSO: plug_in  


    plug_in, "pkgname"  

Dynamically link to yorick package "pkgname".  The compiled  
functions of the package are in a shared object file; these  
files have a naming convention which differs slightly on different  
platforms.  On most UNIX systems (including Mac OS X), the  
binary file is named  On MS Windows systems, the  
binary file is named pkgname.dll.  On HPUX systems, the name is  The "pkgname" argument to plug_in does not include  
this platform-dependent file extension, so that the yorick code  
containing the plug_in command will be portable.  
After dynamically linking the compiled routines in the pkgname  
shared object binary, yorick runs the function (which must be  
present) yk_pkgname in order to initialize the package.  At  
minimum yk_pkgname returns lists of the new compiled (builtin)  
functions defined by the package and the names by which they  
may be invoked by interpreted code.  
Additionally, yk_pkgname returns a list of files to be included  
containing interpreted wrapper functions for the compiled routines  
and DOCUMENT comments for the help system.  Conventionally, these  
include files are located in the Y_SITE/i0 or Y_HOME/lib directories,  
and the name (of one) of the file(s) is pkgname.i.  If the package  
has been statically linked (i.e.- not by plug_in), these .i files  
are automatically included when yorick starts.  However, if the  
package is loaded dynamically by plug_in, you must arrange to  
include one or all of these .i files as you would any interpreted  
package (e.g.- by the autoload or require functions, or manually).  
The upshot of all this is that the plug_in function is designed  
to be placed at the top of the .i files associated with the  
package.  You are not supposed to call plug_in manually, rather  
when you #include (or autoload) a .i file which needs compiled  
functions, that .i file invokes plug_in to perform any required  
dynamic linking to compiled code.  Thus, the end user does not  
do anything differently for a package that uses dynamically loaded  
compiled code, than for a purely interpreted package.  
Yorick dynamic library support solves a distribution problem.  For  
debugging and creating compiled packages for your own use, you want  
to build special versions of yorick with your compiled routines  
statically linked.  In order to support platforms on which there  
is no dynamic linking, if you call the plug_in function for a  
package that is statically linked (e.g.- plug_in,"yor"), the  
function will silently become a no-op when it notices that the  
"pkgname" package was already loaded at startup.  
Builtin function, documented at i0/std.i   line 2339  

SEE ALSO: plug_dir,   include,   require,   autoload  


    poly(x, a0, a1, a2, ..., aN)  

returns the polynomial  A0 + A1*x + A2*x^2 + ... + AN*X^N  
The data type and dimensions of the result, and conformability rules  
for the inputs are identical to those for the expression.  
Builtin function, documented at i0/std.i   line 702  



    f= popen(command, mode)  

opens a pipe to COMMAND, which is executed as with the system  
function.  If MODE is 0, the returned file handle is open for  
reading, and you are reading the stdout produced by COMMAND.  
If MODE is 1, f is opened for writing and you are writing to  
the stdin read by COMMAND.  
Builtin function, documented at i0/std.i   line 1946  

SEE ALSO: open,   system  



returns text representing expression X, equivalent to print(X)(1).  
Interpreted function, defined at i0/std.i   line 480  

SEE ALSO: print,   swrite  


    print, object1, object2, object3, ...  
 or print(object1, object2, object3, ...)  

prints an ASCII representation of the OBJECTs, in roughly the format  
they could appear in Yorick source code.  When invoked as a subroutine  
(in the first form), output is to the terminal.  When invoked as a  
function (int the second form), the output is stored as a vector of  
strings, one string per line that would have been output.  
Printing a structure definition prints the structure definition;  
printing a function prints its "func" definition; printing files,  
bookmarks, and other objects generally provides some sort of  
useful description of the object.  
Builtin function, documented at i0/std.i   line 465  

SEE ALSO: pr1,   print_format,   write,   exit,   error,   nameof,   typeof  


    print_format, line_length, char=, short=, int=, float=,  
    double=, complex=, pointer=  

sets the format string the print function will use for each of  
the basic data types.  Yorick format strings are the same as the  
format strings for the printf function defined in the ANSI C standard.  
The default strings may be restored individually by setting the  
associated format string to ""; all defaults are restored if  
print_format is invoked with no arguments.  The default format strings  
are:  "0x%02x", "%d", "%d", "%ld", "%g", "%g", and "%g%+gi".  
Note that char and short values are converted to int before being  
passed to printf, and that float is converted to double.  
If present, an integer positional argument is taken as the line  
length; <=0 restores the default line length of 80 characters.  
Builtin function, documented at i0/std.i   line 487  

SEE ALSO: print,   write,   nameof,   typeof  


    remaining= process_argv()  

  -or- remaining= process_argv("your startup message")  
Performs standard command line processing.  This function is  
invoked by the default custom.i file (in $Y_SITE/i); you  
can also invoke it from your personal ~/yorick/custom.i file.  
The process_argv calls get_argv, removes any arguments of  
the form "-ifilename" or "-i filename" (the latter is a pair of  
arguments.  It returns any arguments not of this form as its  
result, after including any filenames it found in the order  
they appeared on the command line.  
The optional string argument may be an array of strings to print  
a multi-line message.  
A Yorick package may define the function get_command_line in  
order to feed process_argv something other than get_argv.  
Interpreted function, defined at i0/std.i   line 2510  

SEE ALSO: batch  


 or ptcen(zncen, ireg)  

returns point centered version of the 2-D zone centered array ZNCEN.  
The result is imax-by-jmax if ZNCEN is (imax-1)-by-(jmax-1).  
If the region number array IREG is specified, zones with region  
number 0 are not included in the point centering operation.  
Note that IREG should have dimensions imax-by-jmax; the first  
row and column of IREG are ignored.  
Without IREG, ptcen(zncen) is equivalent to zncen(pcen,pcen).  
Interpreted function, defined at i0/std.i   line 3643  

SEE ALSO: zncen,   uncen