section p of routines in std.i

functions in std.i - p

pc_primitives


    pc_primitives, file  


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


    pi  


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

plug_dir


    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


    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 pkgname.so.  On MS Windows systems, the  
binary file is named pkgname.dll.  On HPUX systems, the name is  
pkgname.sl.  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


    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

popen


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


    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