tepam::procedure - TEPAM procedure, reference manual
This package provides an alternative way to declare Tcl procedures and to manage its arguments. There is a lot of benefit to declare a procedure with TEPAM rather than with the Tcl standard command proc: TEPAM allows specifying inside the procedure declaration all information that is required to generate comprehensive documentations and help support. The information is also used by an automatically invoked argument checker that validates the provided procedure arguments before the procedure body is executed. Finally, a procedure can be called interactively which will open a graphical form that allows specifying the procedure arguments.
TEPAM simplifies also the handling of the different types of argument, like the named arguments (often also called options) and the unnamed arguments. TEPAM supports the named first, unnamed later style (typical Tcl command style) as well as also the unnamed first, named later style (typical Tk command style). TEPAM takes care about default values for arguments, optional arguments, multiple applicable arguments, etc. and eliminates the need to check the validity of the argument inside the procedure bodies.
An informal overview of all the TEPAM procedure declaration and calling features as well as a short introduction into TEPAM is provided by tepam(n).
The exact meaning of several terms that are used in this document will be shortly explained to avoid any ambiguities and misunderstandings.
The usage of subcommands is heavily used in the Tcl language. Several commands are incorporated into a single main command and are selectable via the first argument.
The string command is an example of such a command that implements for example subcommands to check a character string length, to compare strings, to extract substrings, etc:
string length string string compare string string string range string first last ...
TEPAM provides a framework that allows implementing easily such subcommands in form of Tcl procedures. It allows not only defining a first level of subcommands, but also a higher level of subcommands. The string command class check could be implemented as independent sub-sub-commands of the string command:
string is alnum string string is integer string string is double string ...
TEPAM allows attaching to a declared procedure different kind of attributes. Some of these attributes are just used for documentation purposes, but other attributes specify the way how the procedure has to be called. Also the procedure arguments are defined in form of a procedure attribute.
TEPAM uses the term argument for the parameters of a procedure.
The following example calls the subcommand string compare with several arguments:
string compare -nocase -length 3 "emphasized" "emphasised"
The following paragraphs discuss these different argument types.
Some parameters, as -length 3 of the subcommand string compare have to be provided as pairs of argument names and argument values. This parameter type is often also called option.
TEPAM uses the term named argument for such options as well as for the flags (see next item).
Another parameter type is the flag or the switch. Flags are provided simply by naming the flag leading with the '-' character. The -nocase of the previous string compare example is such a flag.
Flags are considered by TEPAM like a special form of named arguments.
For the other parameters, e.g. the ones for which the argument name has not to be mentioned, TEPAM uses the term unnamed argument. The previous string compare example uses for the two provided character strings two unnamed arguments.
TEPAM allows describing the purpose of each procedure argument with argument attributes. While some of them are just documenting the attributes, most attributes are used by an argument manager to control and validate the arguments that are provided during a procedure call. Argument attributes are used to specify default values, parameter classes (integer, xdigit, font, ...), choice validation lists, value ranges, etc.
The string compare command of the previous example requires that the named arguments (options, flags) are provided first. The two mandatory (unnamed) arguments have to be provided as last argument.
string compare -nocase -length 3 Water $Text
This is the usual Tcl style (exceptions exist) which is referred in the TEPAM documentation as named arguments first, unnamed arguments later style.
In contrast to most Tcl commands, Tk uses generally (exceptions exist also here) a different calling style where the unnamed arguments have to be provided first, before the named arguments have to be provided:
pack .ent1 .ent2 -fill x -expand yes -side left
This style is referred in the TEPAM documentation as unnamed arguments first, named arguments later style.
TEPAM allows declaring new Tcl procedures with the command tepam::procedure that has similar to the standard Tcl command proc also 3 arguments:
The TEPAM procedure declaration syntax is demonstrated by the following example:
tepam::procedure {display message} { -short_description "Displays a simple message box" -description "This procedure allows displaying a configurable\ message box. The default message type that is\ created is a warning, but also errors and info can\ be generated. The procedure accepts multiple text lines." -example {display message -mtype Warning "Save first your job"} -args { {-mtype -choices {Info Warning Error} \ -default Warning -description "Message type"} {text -type string -multiple \ -description "Multiple text lines to display"} } } { puts "Message type: $mtype" puts "Message: $text" }
The 3 arguments of procedure are:
The procedure name can be used in very flexible ways. Procedure names can have namespace qualifiers. By providing a two element name list as procedure name, a subcommand of a procedure will be declared. It is even possible to declare sub-sub-commands of a procedure by providing name lists with three elements.
Here are some valid procedure declarations using different procedure names (the attribute and body arguments are empty for simplicity):
# Simple procedure name: tepam::procedure display_message {} {} # Procedure declared in the main namespace: tepam::procedure ::display_message {} {} # Procedure in the namespace ::ns: tepam::procedure ::ns::display_message {} {} # Declaration of the subcommand message of the procedure display: tepam::procedure {display message} {} {}
All procedure attributes are provided in form of an option list that contains pairs of option names and option values. The example above has as procedure attribute a short and a normal description, but also the procedure arguments are defined in form of a procedure attribute.
Most procedure attributes are providing information for documentation purposes. But some of them affect also the way how the procedure can be called. The section Procedure Attributes discusses in detail the available procedure attributes.
The procedure arguments are defined in form of a special procedure attribute. Most of the information provided in the argument definition is not just used for documentation purposes. This information is in fact used by the TEPAM argument manager to handle and validate the various forms of arguments that are provided during the procedure calls. The section Argument Declaration discusses in detail all the argument definition attributes.
This is the normal procedure body. The declared arguments will be available to the procedure body in form of variables.
The procedure body will only be executed if the provided set of arguments could be validated by the TEPAM argument manager.
tepam::procedure {display_message} { -args { {-mtype -default Warning -choices {Warning Error}} {text -type string} } } { puts "Message type: $mtype" puts "Message: $text" }
The commands procedure as well as argument_dialogbox are exported from the namespace tepam. To use these commands without the tepam:: namespace prefix, it is sufficient to import them into the main namespace:
namespace import tepam::* procedure {display_message} { -args { ...
The first group of attributes affect the behavior of the declared procedure:
This attribute defines the calling style of a procedure. TEPAM uses by default the named arguments first, unnamed arguments later style (Tcl). This default behavior can globally be changed by setting the variable tepam::named_arguments_first to 0. This global calling style can be changed individually for a procedure with the -named_arguments_first attribute.
The declared procedures will by default automatically try to match eventually abbreviated argument names to the defined arguments names. This default behavior can globally be changed by setting the variable tepam::auto_argument_name_completion to 0. This global setting of the automatic argument name completion can be changed individually for a procedure with the -auto_argument_name_completion procedure attribute.
A procedure declared with the TEPAM procedure command can always be called with the -interactive option. By doing so, a graphical form will be generated that allows specifying all procedure argument values. There are two display modes for these interactive forms. While the extended mode is more adapted for small procedure argument sets, the short form is more adequate for huge procedure argument sets.
The choice to use short or extended forms can be globally configured via the variable tepam::interactive_display_format. This global setting can then be changed individually for a procedure with the -interactive_display_format procedure attribute.
The procedure arguments are declared via the -args attribute. An argument is defined via a list having as first element the argument name, followed by eventual argument attributes. All these argument definition lists are packaged themselves into a global list that is assigned to the -args attribute.
The argument definition syntax will be described more in detail in the following sub section.
The next attributes allow specifying custom argument checks as well as custom error messages in case these checks are failing:
Custom argument validations can be performed via specific validation commands that are defined with the -validatecommand attribute.
Validation command declaration example:
tepam::procedure {display_message} { -args { {text -type string -description "Message text"} } -validatecommand {IllegalWordDetector $text} } { }
The validation command is executed in the context of the declared procedure body. The different argument values are accessed via the argument names. Note there is also an argument attribute -validatecommand that allows declaring custom checks for specific arguments.
The attribute -validatecommand can be repeated to declare multiple custom checks.
This attribute allows overriding the default error message for a custom argument validation (defined by -validatecommand). Also this attribute can be repeated in case multiple argument checks are declared.
The following attribute allows controlling the logging settings for an individual procedure:
This argument configures the logging of the procedure calls into the list variable tepam::ProcedureCallLogList. The default configuration defined by the variable tepam::command_log will be used if this argument is not defined in a procedure declaration.
Setting this argument to 0 will disable any procedure call loggings, setting it to 1 will log any procedure calls and setting it to interactive will log just the procedures that are called interactively (procedures called with the -interactive flag).
The next group of procedure attributes is just used for the purpose of documentation and help text generation:
A category can be assigned to a procedure for documentation purposes. Any string is accepted as category.
The short description of a procedure is used in the documentation summary of a generated procedure list as well as in the NAME section of a generated procedure manual page.
The (full) description assigned to a procedure is used to create user manual and help pages.
The -return attribute allows defining the expected return value of a procedure (used for documentation purposes).
A help text or manual page of a procedure can be enriched with eventual examples, using the -example attribute.
The following example shows the structure that is used for the argument definitions in the context of a procedure declaration:
tepam::procedure {display_message} { -args { {-mtype -default Warning -choices {Info Warning Error} -description "Message type"} {-font -type font -default {Arial 10 italic} -description "Message text font"} {-level -type integer -optional -range {1 10} -description "Message level"} {-fg -type color -optional -description "Message color"} {-log_file -type file -optional -description "Optional message log file"} {text -type string -multiple -description "Multiple text lines to display"} } } { }
Each of the procedure arguments is declared with a list that has as first element the argument name, followed by eventual attributes. The argument definition syntax can be formalized in the following way:
tepam::procedure <name> { -args { {<argument_name_1> <arg_attr_name_1a> <arg_attr_value_1a> <arg_attr_name_1b> <arg_attr_value_1b> ...} {<argument_name_2> <arg_attr_name_2a> <arg_attr_value_2a> <arg_attr_name_2b> <arg_attr_value_2b> ...} ... } } <body>
The argument names and attributes have to be used in the following way:
The provided argument name specifies whether the argument is an unnamed argument or a named argument. In addition to this, an argument name can also be blank to indicate an argument comment, or it can start with # to indicate a section comment.
This is the simplest form of an argument name: An argument whose name is not starting with '-' is an unnamed argument. The parameter provided during a procedure call will be assigned to a variable with the name <Name>.
tepam::procedure {print_string} { -args { {text -type string -description "This is an unnamed argument"} } } { puts $text } print_string "Hello" -> Hello
An argument whose name starts with '-' is a named argument (also called option). The parameter provided during a procedure call will be assigned to a variable with the name <Name> (not -<Name>).
tepam::procedure {print_string} { -args { {-text -type string -description "This is a named argument"} } } { puts $text } print_string -text "Hello" -> Hello
This flag allows clearly specifying the end of the named arguments and the beginning of the unnamed arguments, in case the named arguments first, unnamed arguments later style (Tcl) has been selected.
If the unnamed arguments first, named arguments later style (Tk) style is selected, this flag is ignored if the unnamed arguments have already been parsed. Otherwise it will be assigned to the corresponding unnamed argument.
A blank argument name (either '-' or '') starts a comment for the following arguments.
tepam::procedure {print_time} { -interactive_display_format short -args { {hours -type integer -description "Hour"} {minutes -type integer -description "Minute"} {- The following arguments are optional:} {seconds -type integer -default 0 -description "Seconds"} {milliseconds -type integer -default 0 -description "Milliseconds"} } } { puts "${hour}h${minutes}:[expr $seconds+0.001*$milliseconds]" }
Argument comments are basically used in the graphical argument definition forms that are created if a procedure is called interactively.
An argument definition list that starts with '#' is considered as a section comment. The argument definition list will be trimmed from the '#' characters and the remaining string will be used as section comment.
Section comments can be used to structure visually the argument definition code. Section comments are also used to structure the generated help texts and the interactive argument definition forms.
tepam::procedure {complex_multiply} { -description "This function perform a complex multiplication" -args { {#### First complex number ####} {-r0 -type double -description "First number real part"} {-i0 -type double -description "First number imaginary part"} {#### Second complex number ####} {-r1 -type double -description "Second number real part"} {-i1 -type double -description "Second number imaginary part"} } } { return [expr $r0*$r1 - $i0*$i1] }
The following argument attributes are supported:
The description argument attribute is used for documentation purpose. Interactive argument definition forms use this attribute to provide explanations for an argument.
The type argument attribute allows assigning the argument either to a predefined data type, or to an application specific data type. The argument values that are provided during a procedure call are automatically checked with respect to the defined argument type.
The section ARGUMENT TYPES provides a list of predefined data types and explains how application specific types can be specified.
The argument type none has a special meaning. An argument that has the type none is handled as a flag. A flag is always optional and its related variable contains the logical value 1 if the flag has been defined during the procedure call, or otherwise 0.
Eventual default values can be defined with the -default argument attribute. Arguments with default values are automatically optional arguments.
Arguments are by default mandatory, unless a default value is defined. The flag -optional transforms an argument into an optional argument.
In case an optional argument is not defined during a procedure call, the corresponding variable will not be defined. The flag -mandatory is the opposite to -optional. This flag exists only for completion reason, since an argument is anyway mandatory by default.
Arguments that have the -multiple attribute can be defined multiple times during a procedure call. The values that are provided during a procedure call for such an argument are stored in a list variable. This is even the case if such an argument is only defined once during a procedure call.
The -multiple attribute can be attributed to unnamed arguments and to named arguments. The pair of argument name/argument value has to be repeated for each provided value in case of a named argument. In case the argument with the -multiple attribute is an unnamed argument, this one has to be the absolute last one of all unnamed arguments.
A possible set of valid argument values can be attributed to an argument via the -choices attribute. The argument value provided during a procedure call will be checked against the provided choice values.
An eventual short description can be attributed to each choice option with the -choicelabels attribute. These descriptions will be used in the generated help texts and as radio and check box labels for the interactive calls.
The -choicelabels attribute is optional, but if it is defined, its list needs to have the identical size as the -choices argument list.
Another argument constraint can be defined with the -range attribute. The valid range is defined with a list containing the minimum valid value and a maximum valid value. The -range attribute has to be used only for numerical arguments, like integers and doubles.
Custom argument value validations can be performed via specific validation commands that are defined with the -validatecommand attribute. The provided validation command can be a complete script in which the pattern %P is replaced by the argument value that has to be validated.
Validation command declaration example:
tepam::procedure {display_message} { -args { {text -type string -description "Message text" \ -validatecommand {IllegalWordDetector %P}} } { }
While the purpose of this custom argument validation attribute is the validation of a specific argument, there is also a global attribute -validatecommand that allows performing validation that involves multiple arguments.
This attribute allows overriding the default error message for a custom argument validation (defined by -validatecommand).
The widgets that allow defining the different arguments in case of an interactive procedure call are normally selected automatically in function of the argument type. The -widget attribute allows specifying explicitly a certain widget type for an argument.
In case a procedure is called interactively, additional argument attributes can be provided to the interactive argument definition form via the -auxargs attribute that is itself a list of attribute name/attribute value pairs:
-auxargs {-<arg_attr_name_1a> <arg_attr_value_1a> \ -<arg_attr_name_1b> <arg_attr_value_1b> ... }
For example, if a procedure takes as argument a file name it may be beneficial to specify the required file type for the interactive argument definition form. This information can be provided via the -auxargs attribute to the argument definition form:
tepam::procedure LoadPicture { -args { {FileName -type existingfile -description "Picture file" \ -auxargs {-filetypes {{"GIF" {*.gif}} {"JPG" {*.jpg}} }}} } } { }
If the auxiliary argument attributes are not static but have to be dynamically adaptable, the -auxargs_commands allows defining them via commands that are executed during a procedure call. A list of pairs of auxiliary attribute names and commands has to be provided to the -auxargs_commands attribute. The provided commands are executed in the context of the calling procedure.
-auxargs_commands {-<arg_attr_name_1a> <arg_attr_command_1a> \ -<arg_attr_name_1b> <arg_attr_command_1b> ... }
Several variables defined inside the ::tepam namespace impact the mode of operation of the procedures that have been declared with the TEPAM procedure command.
This variable defines the general calling style of the procedures. It is by default set to 1 which selects the named arguments first, unnamed arguments later style (Tcl style).
By setting this variable to 0, the named arguments first, unnamed arguments later style is globally selected (Tk style):
set tepam::named_arguments_first 0
While this variable defines the general calling style, the procedure attribute -named_arguments_first can adapt this style individually for each declared procedure.
This variable controls the general automatic argument name matching mode. By default it is set to 1, meaning that the called procedures are trying to match eventually abbreviated argument names with the declared argument names.
By setting this variable to 0 the automatic argument name matching mode is disabled:
set tepam::auto_argument_name_completion 0
While this variable defines the general matching mode, the procedure attribute -auto_argument_name_completion can adapt this mode individually for each declared procedure.
A procedure declared via the TEPAM procedure command can always be called with the -interactive switch. By doing so, a graphical form will be generated that allows entering interactively all procedure arguments.
There are two display modes for these interactive forms. The extended mode which is the default mode is more adapted for small procedure argument sets. The short form is more adequate for huge procedure argument sets:
set tepam::interactive_display_format "short"
The choice to use short or extended forms can be globally configured via the variable interactive_display_format. This global setting can be changed individually for a procedure with the procedure attribute -interactive_display_format.
The maximum line length used by the procedure help text generator can be specified with this variable. The default length which is set to 80 (characters) can easily be adapted to the need of an application:
set tepam::help_line_length 120
Since this variable is applied directly during the help text generation, its value can continuously be adapted to the current need.
Procedure calls can be logged inside the list variable tepam::ProcedureCallLogList. The variable tepam::command_log controls the default logging settings for any procedures. The following configurations are supported:
0: Disables any procedure call loggings
1: Enables any procedure call loggings
"interactive": Will log any procedures called interactively (e.g. procedures called with the -interactive flag). This is the default configuration.
This default logging configuration can be changed individually for each procedure with the -command_log attribute.
TEPAM provides a comprehensive set of procedure argument types. They can easily be completed with application specific types if necessary.
To remember, a type can be assigned to each specified procedure argument:
tepam::procedure {warning} { -args { {-font -type font -default {Arial 10 italic}} {-severity_level -type integer -optional -range {1 10}} {-fg -type color -optional -description "Message color"} {text -type string -multiple -description "Multiple text lines to display"} } } { ... }
There are some special purpose types that are building the first category of predefined argument types:
none
A flag, also called switch, is defined as a named argument that has the type none. Flags are always optional and the default value of the assigned variable is set to 0. In contrast to the (normal) named arguments, no argument value has to be provided to a flag.
tepam::procedure flag_test { -args { {-flag -type none -description "This is a flag"} } } { puts $flag } flag_test -> 0 flag_test -flag -> 1
Since no argument value has to be provided to a flag, also no data check is performed for this argument type.
string
String is a generic argument data type. Any data string can be provided to a string type argument and no data type checks are therefore performed. The string type allows defining single line strings during the interactive procedure calls.
text
Text is identical to string with the only difference that it allows entering multi line strings during interactive procedure calls.
{}
A blank argument type signifies an undefined argument type. This is the default argument type that will be used if no type has been explicitly specified. An argument that has a blank type behaves identically than an argument that has a string type, e.g. no argument data checks are performed. The only difference is that the data type string is mentioned in the generated help documentation, while this is not the case for the blank type.
Several numerical types are defined by TEPAM. The type validation procedures are using the string is <type> -strict commands to check the validity of the provided arguments, which assures that no empty strings are accepted as argument value. The type validation expression for the numerical types and the argument types to which this expression is applied are:
string is <type_to_check> -strict <argument_value>
boolean
integer
double
Empty strings are accepted as argument value for all the alpha numeric argument types. The argument types that are falling into this category and validation expression used for them are:
string is <type_to_check> <argument_value>
alnum
alpha
ascii
control
digit
graph
lower
punct
space
upper
wordchar
xdigit
In addition to the data types checked with the string is <type> commands, TEPAM specifies some other useful data types:
char
Each string that has a length of 1 character meets the character type. The type check is made with the following expression:
expr [string length <argument_value>]==1
color
Any character strings that are accepted by Tk as a color are considered as valid color argument. Please note that the Tk package has to be loaded to use the type color. TEPAM is using the following command to validate the color type:
expr ![catch {winfo rgb . <argument_value>}]
font
Any character strings that are accepted by Tk as a font are considered as valid font argument. Please note that the Tk package has to be loaded to use the font type. TEPAM is using the following command to validate the color type:
expr ![catch {font measure <argument_value> ""}]
file
Any strings that are not containing one of the following characters are considered as valid file names: * ? " < >. It is not necessary that the file and its containing directory exist. Zero-length strings are not considered as valid file names.
The following expression is used to validate the file names:
expr [string length <argument_value>]>0 && ![regexp {[\"*?<>:]} <argument_value>]
existingfile
The argument is valid if it matches with an existing file. The following check is performed to validate the arguments of this type:
file exists <argument_value>
directory
The directory argument is validated exactly in the same way as the file arguments.
existingdirectory
The argument is valid if it matches with an existing directory. The following check is performed to validate the arguments of this type:
file isdirectory <argument_value>
To add support for a new application specific argument type it is just necessary to add into the namespace tepam a validation function Validation(<type>). This function requires one argument. It has to returns 1 if the provided argument matches with the relevant data type. The function has to return otherwise 0.
The validation command section of the "tepam.tcl" package provides sufficient examples of validation functions, since it implements the ones for the standard TEPAM types.
The following additional code snippet shows the validation function for a custom argument type that requires values that have a character string length of exactly 2:
proc tepam::Validate(two_char) {v} {expr {[string length $v]==2}}
Each procedure can be called with the -help flag. The procedure will then print a generated help text to stdout and will then return without performing any additional actions.
Taking the first procedure declared in PROCEDURE CALLS, the help request and the printed help text would be:
display message -help -> NAME display message - Displays a simple message box SYNOPSIS display message [-mtype <mtype>] Message type, default: "Warning", choices: {Info, Warning, Error} <text> Multiple text lines to display, type: string DESCRIPTION This procedure allows displaying a configurable message box. The default message type that is created is a warning, but also errors and info can be generated. The procedure accepts multiple text lines. EXAMPLE display message -mtype Warning "Save first your job"
The argument manager is checking if the last provided argument is -help and generates the requested help message if this is the case. So, also the following example will print the help message:
display message -mtype Info "It is 7:00" -help
On the other hand, the following call will result in an error:
display message -help -mtype Info "It is 7:00" -> display message: Argument '-help' not known
If Tk has been loaded a procedure can be called with the -interactive flag to open a graphical form that allows specifying interactively all procedure arguments. The following example assures that the Tk library is loaded and shows the command line to call interactively the procedure declared in PROCEDURE CALLS:
package require Tk display message -interactive
Also the -interactive flag has to be placed at the last argument position as this is also required for the -help flag. Arguments defined before the -interactive flag will be ignored. The following example is therefore also a valid interactive procedure call:
display message -mtype Info "It is 7:00" -interactive
Unnamed arguments are typically provided to the called procedure as simple parameters. This procedure calling form requires that the provided arguments are strictly following the order of the specified arguments. Several parameters can be assigned to the last argument if this one has the -multiple attribute. So, the following declared procedure ...
tepam::procedure {display_message} { -args { {mtype -choices {Info Warning Error}} {text -type string -multiple} } } { puts "$mtype: [join $text]" }
... can for example be called in the following ways:
display_message Info "It is PM 7:00." -> Info: It is PM 7:00. display_message Info "It is PM 7:00." "You should go home." -> Info: It is PM 7:00. You should go home.
The nice thing is that unnamed arguments can also be called as named arguments, which can be handy, for example if the exact specified argument order is not known to a user:
display_message -mtype Info -text "It is PM 7:00." -> Info: It is PM 7:00. display_message -text "It is PM 7:00." -mtype Info -> Info: It is PM 7:00. display_message -mtype Info -text "It is PM 7:00." -text "You should go home." -> Info: It is PM 7:00. You should go home. display_message -text "It is PM 7:00." -text "You should go home." -mtype Info -> Info: It is PM 7:00. You should go home.
Named arguments have to be provided to a procedure in form of a parameter pairs composed by the argument names and the argument values. The order how they are provided during a procedure call is irrelevant and has not to match with the argument specification order.
The following declared procedure ...
tepam::procedure {display_message} { -args { {-mtype -choices {Info Warning Error}} {-text -type string -multiple} } } { puts "$mtype: [join $text]" }
... can be called in the following ways:
display_message -mtype Info -text "It is PM 7:00." -> Info: It is PM 7:00. display_message -text "It is PM 7:00." -mtype Info -> Info: It is PM 7:00. display_message -mtype Info -text "It is PM 7:00." -text "You should go home." -> Info: It is PM 7:00. You should go home. display_message -text "It is PM 7:00." -text "You should go home." -mtype Info -> Info: It is PM 7:00. You should go home.
Also named arguments that have not the -multiple attribute can be provided multiple times. Only the last provided argument will be retained in such a case:
display_message -mtype Info -text "It is PM 7:00." -mtype Warning -> Warning: It is PM 7:00.
A procedure that has been defined while the variable tepam::named_arguments_first was set to 1, or with the procedure attribute -named_arguments_first set to 1 has to be called in the Tcl style. The following procedure declaration will be used in this section to illustrate the meaning of this calling style:
set tepam::named_arguments_first 1 tepam::procedure my_proc { -args { {-n1 -default ""} {-n2 -default ""} {u1 -default ""} {u2 -default ""} } } { puts "n1:'$n1', n2:'$n2', u1:'$u1', u2:'$u2'" }
The unnamed arguments are placed at the end of procedure call, after the named arguments:
my_proc -n1 N1 -n2 N2 U1 U2 -> n1:'N1', n2:'N2', u1:'U1', u2:'U2'
The argument parser considers the first argument that doesn't start with the '-' character as well as all following arguments as unnamed argument:
my_proc U1 U2 -> n1:'', n2:'', u1:'U1', u2:'U2'
Named arguments can be defined multiple times. If the named argument has the -multiply attribute, all argument values will be collected in a list. Otherwise, only the last provided attribute value will be retained:
my_proc -n1 N1 -n2 N2 -n1 M1 U1 U2 -> n1:'M1', n2:'N2', u1:'U1', u2:'U2'
The name of the first unnamed argument has therefore not to start with the '-' character. The unnamed argument is otherwise considered as name of another named argument. This is especially important if the first unnamed argument is given by a variable that can contain any character strings:
my_proc -n1 N1 -n2 N2 "->" "<-" -> my_proc: Argument '->' not known set U1 "->" my_proc -n1 N1 -n2 N2 $U1 U2 my_proc: Argument '->' not known
The '--' flag allows separating unambiguously the unnamed arguments from the named arguments. All data after the '--' flag will be considered as unnamed argument:
my_proc -n1 N1 -n2 N2 -- "->" "<-" -> n1:'N1', n2:'N2', u1:'->', u2:'<-' set U1 "->" my_proc -n1 N1 -n2 N2 -- $U1 U2 -> n1:'N1', n2:'N2', u1:'->', u2:'<-'
The Tk calling style will be chosen if a procedure is defined while the variable tepam::named_arguments_first is set to 0, or if the procedure attribute -named_arguments_first has been set to 0. The following procedure will be used in this section to illustrate this calling style:
set tepam::named_arguments_first 0 tepam::procedure my_proc { -args { {-n1 -default ""} {-n2 -default ""} {u1} {u2 -default "" -multiple} } } { puts "n1:'$n1', n2:'$n2', u1:'$u1', u2:'$u2'" }
The unnamed arguments have to be provided first in this case. The named arguments are provided afterwards:
my_proc U1 U2 -n1 N1 -n2 N2 -> n1:'N1', n1:'N1', u1:'U1', u2:'U2'
The argument parser will assign to each defined unnamed argument a value before it switches to read the named arguments. This default behavior changes a bit if there are unnamed arguments that are optional or that can take multiple values.
An argument value will only be assigned to an unnamed argument that is optional (that has either the -optional attribute or that has a default value), if the value is not beginning with the '-' character or if no named arguments are defined. The value that starts with '-' is otherwise considered as the name of a named argument.
Argument values are assigned to an argument that has the -multiple attribute as long as the parameter value doesn't starts with the '-' character.
Values that start with the '-' character can therefore not be assigned to optional unnamed arguments, which restricts the usage of the Tcl procedure calling style. The Tk style may be preferable in some cases, since it allows separating unambiguously the named arguments from the unnamed ones with the '--' flag.
Let's explore in a bit less theoretically the ways how the previously defined procedure can be called: The first example calls the procedure without any parameters, which leads to an error since u1 is a mandatory argument:
my_proc -> my_proc: Required argument is missing: u1
The procedure call is valid if one parameter is provided for u1:
my_proc U1 -> n1:'', n2:'', u1:'U1', u2:''
If more parameters are provided that are not starting with the '-' character, they will be attributed to the unnamed arguments. U2 will receive 3 of these parameters, since it accepts multiple values:
my_proc U1 U2 U3 U4 -> n1:'', n2:'', u1:'U1', u2:'U2 U3 U4'
As soon as one parameter starts with '-' and all unnamed arguments have been assigned, the argument manager tries to interpret the parameter as name of a named argument. The procedure call will fail if a value beginning with '-' is assigned to an unnamed argument:
my_proc U1 U2 U3 U4 -U5 -> my_proc: Argument '-U5' not known
The attribution of a parameter to a named argument will fail if there are undefined unnamed (non optional) arguments. The name specification will in this case simply be considered as a parameter value that is attributed to the next unnamed argument. This was certainly not the intention in the following example:
my_proc -n1 N1 -> n1:'', n2:'', u1:'-n1', u2:'N1'
The situation is completely different if values have already been assigned to all mandatory unnamed arguments. A parameter beginning with the '-' character will in this case be considered as a name identifier for a named argument:
my_proc U1 -n1 N1 -> n1:'N1', n2:'', u1:'U1', u2:''
No unnamed arguments are allowed behind the named arguments:
my_proc U1 -n1 N1 U2 -> my_proc: Argument 'U2' is not an option
The '--' flag has no special meaning if not all mandatory arguments have got assigned a value. This flag will simply be attributed to one of the unnamed arguments:
my_proc -- -n1 N1 -> n1:'N1', n2:'', u1:'--', u2:''
But the '--' flag is simply ignored if the argument parser has started to handle the named arguments:
my_proc U1 -- -n1 N1 -> n1:'N1', n2:'', u1:'U1', u2:'' my_proc U1 -n1 N1 -- -n2 N2 -> n1:'N1', n2:'N2', u1:'U1', u2:''
It may be necessary sometimes that the procedure body is able to access the entire list of arguments provided during a procedure call. This can happen via the args variable that contains always the unprocessed argument list:
tepam::procedure {display_message} { -args { {-mtype -choices {Warning Error} -default Warning} {text -type string -multiple} } } { puts "args: $args" } display_message -mtype Warning "It is 7:00" -> args: -mtype Warning {It is 7:00}
Procedures, arguments, parameters, options
Copyright © 2009-2013, Andreas Drollinger


Base Tests
DOM Interaction Tests
AJAX Interaction Tests (requires webserver)
Form Interaction Tests (requires webserver)
Selector Interaction Tests
Layout Tests
Here's
a link
.
And here's another paragraph.
One two three
four
test
test


|
CompactStar SDK 1.08
|
Cuts box on the longest axis
| pBox | - box to cut | |
| [out] | pLeftBox | - resulting left box |
| [out] | pRightBox | - resulting right box |
| void csrBoxExtendToPolygon | ( | const CSR_Polygon3 * | pPolygon, |
| CSR_Box * | pBox, | ||
| int * | pEmpty | ||
| ) |
Extends a box to encompass a polygon
| pPolygon | - polygon to encompass in the box | |
| [in,out] | pBox | - bounding box that will encompass the polygon |
| [in,out] | pEmpty | - if 1, box is empty and still not contains any polygon |
| int csrInsideBox | ( | const CSR_Vector3 * | pP, |
| const CSR_Box * | pB | ||
| ) |
Checks if a point is inside a box
| pP | - point to check |
| pB | - box to check against |
| int csrInsideCapsule | ( | const CSR_Vector3 * | pP, |
| const CSR_Capsule * | pC | ||
| ) |
Checks if a point is inside a capsule
| pP | - point to check |
| pC | - capsule to check against |
| int csrInsideCircle | ( | const CSR_Vector2 * | pP, |
| const CSR_Circle * | pC | ||
| ) |
Checks if a point is inside a circle
| pP | - point to check |
| pC | - circle to check against |
| int csrInsidePolygon2 | ( | const CSR_Vector2 * | pP, |
| const CSR_Polygon2 * | pPo | ||
| ) |
Checks if a point is inside a 2D polygon
| pP | - point to check |
| pPo | - polygon to check against |
| int csrInsidePolygon3 | ( | const CSR_Vector3 * | pP, |
| const CSR_Polygon3 * | pPo | ||
| ) |
Checks if a point is inside a polygon
| pP | - point to check |
| pPo | - polygon to check against |
| int csrInsideRect | ( | const CSR_Vector2 * | pP, |
| const CSR_Rect * | pR | ||
| ) |
Checks if a point is inside a rectangle
| pP | - point to check |
| pR | - rectangle to check against |
| int csrInsideSphere | ( | const CSR_Vector3 * | pP, |
| const CSR_Sphere * | pS | ||
| ) |
Checks if a point is inside a sphere
| pP | - point to check |
| pS | - sphere to check against |
| int csrIntersect2 | ( | const CSR_Figure2 * | pFigure1, |
| const CSR_Figure2 * | pFigure2, | ||
| CSR_Vector2 * | pR1, | ||
| CSR_Vector2 * | pR2 | ||
| ) |
Checks if a geometric 2D figure intersects another geometric 2D figure
| pFigure1 | - first geometric figure to check | |
| pFigure2 | - second geometric figure to check against | |
| [out] | pR1 | - first resulting point where the figures intersect (if any), ignored if 0 |
| [out] | pR2 | - second resulting point where the figures intersect (if any), ignored if 0 |
| int csrIntersect3 | ( | const CSR_Figure3 * | pFigure1, |
| const CSR_Figure3 * | pFigure2, | ||
| CSR_Vector3 * | pR1, | ||
| CSR_Vector3 * | pR2, | ||
| CSR_Plane * | pR3 | ||
| ) |
Checks if a geometric 3D figure intersects another geometric 3D figure
| pFigure1 | - first geometric figure to check | |
| pFigure2 | - second geometric figure to check against | |
| [out] | pR1 | - first resulting point where the figures intersect (if any), ignored if 0 |
| [out] | pR2 | - second resulting point where the figures intersect (if any), ignored if 0 |
| [out] | pR3 | - plane resulting from intersection (if any), ignored if 0 |
| void csrMat4ApplyToNormal | ( | const CSR_Matrix4 * | pM, |
| const CSR_Vector3 * | pN, | ||
| CSR_Vector3 * | pR | ||
| ) |
Applies a matrix to a normal
| pM | - matrix to apply | |
| pN | - normal on which matrix should be applied | |
| [out] | pR | - resulting normal |
| void csrMat4ApplyToVector | ( | const CSR_Matrix4 * | pM, |
| const CSR_Vector3 * | pV, | ||
| CSR_Vector3 * | pR | ||
| ) |
Applies a matrix to a vector
| pM | - matrix to apply | |
| pV | - vector on which matrix should be applied | |
| [out] | pR | - resulting vector |
| void csrMat4Frustum | ( | float | left, |
| float | right, | ||
| float | bottom, | ||
| float | top, | ||
| float | zNear, | ||
| float | zFar, | ||
| CSR_Matrix4 * | pR | ||
| ) |
Gets frustrum matrix
| left | - left view rect edge | |
| right | - right view rect edge | |
| bottom | - bottom view rect edge | |
| top | - top view rect edge | |
| zNear | - z near clipping value | |
| zFar | - z far clipping value | |
| [out] | pR | - frustrum matrix |
| void csrMat4Identity | ( | CSR_Matrix4 * | pR | ) |
Gets matrix identity
| [out] | pR | - identity matrix |
| void csrMat4Inverse | ( | const CSR_Matrix4 * | pM, |
| CSR_Matrix4 * | pR, | ||
| float * | pDeterminant | ||
| ) |
Inverses a matrix
| pM | - matrix to inverse | |
| [out] | pR | - inversed matrix |
| [out] | pDeterminant | - matrix determinant |
| void csrMat4LookAtLH | ( | const CSR_Vector3 * | pPos, |
| const CSR_Vector3 * | pDir, | ||
| const CSR_Vector3 * | pUp, | ||
| CSR_Matrix4 * | pR | ||
| ) |
Creates combined look at matrix (left hand system)
| pPos | - eye (or camera) target position | |
| pDir | - eye (or camera) direction vector | |
| pUp | - up vector direction | |
| [out] | pR | - left-hand look at matrix |
| void csrMat4LookAtRH | ( | const CSR_Vector3 * | pPos, |
| const CSR_Vector3 * | pDir, | ||
| const CSR_Vector3 * | pUp, | ||
| CSR_Matrix4 * | pR | ||
| ) |
Creates combined look at matrix (right hand system)
| pPos | - eye (or camera) target position | |
| pDir | - eye (or camera) direction vector | |
| pUp | - up vector direction | |
| [out] | pR | - right-hand look at matrix |
| void csrMat4Multiply | ( | const CSR_Matrix4 * | pM1, |
| const CSR_Matrix4 * | pM2, | ||
| CSR_Matrix4 * | pR | ||
| ) |
Multiplies matrix by another matrix
| pM1 | - first matrix to multiply | |
| pM2 | - second matrix to multiply with | |
| [out] | pR | - multiplied matrix |
| void csrMat4Ortho | ( | float | left, |
| float | right, | ||
| float | bottom, | ||
| float | top, | ||
| float | zNear, | ||
| float | zFar, | ||
| CSR_Matrix4 * | pR | ||
| ) |
Gets orthogonal matrix
| left | - left view rect edge | |
| right | - right view rect edge | |
| bottom | - bottom view rect edge | |
| top | - top view rect edge | |
| zNear | - z near clipping value | |
| zFar | - z far clipping value | |
| [out] | pR | - orthogonal matrix |
| void csrMat4Perspective | ( | float | fovyDeg, |
| float | aspect, | ||
| float | zNear, | ||
| float | zFar, | ||
| CSR_Matrix4 * | pR | ||
| ) |
Gets perspective matrix
| fovyDeg | - field of view angle in radian | |
| aspect | - aspect ratio | |
| zNear | - z near clipping value | |
| zFar | - z far clipping value | |
| [out] | pR | - perspective matrix |
| void csrMat4Rotate | ( | float | angle, |
| const CSR_Vector3 * | pAxis, | ||
| CSR_Matrix4 * | pR | ||
| ) |
Gets rotation matrix
| angle | - rotation angle, in radians | |
| pAxis | - rotation axis | |
| [out] | pR | - rotation matrix |
| void csrMat4RotationFrom | ( | const CSR_Matrix4 * | pM, |
| float * | pX, | ||
| float * | pY, | ||
| float * | pZ | ||
| ) |
Gets the x, y and z rotation angles from a matrix
| pM | - matrix | |
| [out] | pX | - angle on x axis in radian |
| [out] | pY | - angle on y axis in radian |
| [out] | pZ | - angle on z axis in radian |
| void csrMat4Scale | ( | const CSR_Vector3 * | pFactor, |
| CSR_Matrix4 * | pR | ||
| ) |
Gets scale matrix
| pFactor | - scale factor | |
| [out] | pR | - scale matrix |
| void csrMat4ScalingFrom | ( | const CSR_Matrix4 * | pM, |
| float * | pX, | ||
| float * | pY, | ||
| float * | pZ | ||
| ) |
Gets the x, y and z scaling factor from a matrix
| pM | - matrix | |
| [out] | pX | - factor on x axis |
| [out] | pY | - factor on y axis |
| [out] | pZ | - factor on z axis |
| void csrMat4Transform | ( | const CSR_Matrix4 * | pM, |
| const CSR_Vector3 * | pV, | ||
| CSR_Vector3 * | pR | ||
| ) |
Transforms a vector by a matrix
| pM | - transform matrix | |
| pV | - vector to transform | |
| [out] | pR | - transformed vector |
| void csrMat4Translate | ( | const CSR_Vector3 * | pT, |
| CSR_Matrix4 * | pR | ||
| ) |
Gets translation matrix
| pT | - translation vector | |
| [out] | pR | - translation matrix |
| void csrMat4TranslationFrom | ( | const CSR_Matrix4 * | pM, |
| float * | pX, | ||
| float * | pY, | ||
| float * | pZ | ||
| ) |
Gets the x, y and z translation from a matrix
| pM | - matrix | |
| [out] | pX | - translation on x axis |
| [out] | pY | - translation on y axis |
| [out] | pZ | - translation on z axis |
| void csrMat4Transpose | ( | const CSR_Matrix4 * | pM, |
| CSR_Matrix4 * | pR | ||
| ) |
Transposes a matrix
| pM | - matrix to transpose | |
| [out] | pR | - transposed matrix |
| void csrMat4Unproject | ( | const CSR_Matrix4 * | pP, |
| const CSR_Matrix4 * | pV, | ||
| CSR_Ray3 * | pR | ||
| ) |
Unprojects a ray (i.e. transforms it in viewport coordinates)
| pP | - projection matrix | |
| pV | - view matrix, ignored if 0 | |
| [in,out] | pR | - ray to unproject, unprojected ray on function ends |
| void csrPlaneDistanceTo | ( | const CSR_Vector3 * | pP, |
| const CSR_Plane * | pPl, | ||
| float * | pR | ||
| ) |
Calculates a distance between a point and a plane
| pP | - point | |
| pPl | - plane | |
| [out] | pR | - distance between the point and the plane |
| void csrPlaneFromPointNormal | ( | const CSR_Vector3 * | pP, |
| const CSR_Vector3 * | pN, | ||
| CSR_Plane * | pR | ||
| ) |
Creates a plane from a point and a normal
| pP | - point | |
| pN | - normal | |
| [out] | pR | - resulting plane |
| void csrPlaneFromPoints | ( | const CSR_Vector3 * | pV1, |
| const CSR_Vector3 * | pV2, | ||
| const CSR_Vector3 * | pV3, | ||
| CSR_Plane * | pR | ||
| ) |
Creates a plane from 3 vertex
| pV1 | - first vector | |
| pV2 | - second vector | |
| pV3 | - third vector | |
| [out] | pR | - resulting plane |
| void csrPlaneTransform | ( | const CSR_Plane * | pPlane, |
| const CSR_Matrix4 * | pM, | ||
| CSR_Plane * | pR | ||
| ) |
Transforms a plane by a matrix
| pPlane | - plane to transform | |
| pM | - the inverse transpose of the transformation matrix | |
| [out] | pR | - transformed plane |
| void csrPolygon3ClosestPoint | ( | const CSR_Vector3 * | pP, |
| const CSR_Polygon3 * | pPo, | ||
| CSR_Vector3 * | pR | ||
| ) |
Calculates and gets the closest point on a polygon edge from a point
| pP | - point | |
| pPo | - polygon | |
| [out] | pR | - closest point on the polygon edge |
| void csrQuatConjugate | ( | const CSR_Quaternion * | pQ, |
| CSR_Quaternion * | pR | ||
| ) |
Conjugates the quaternion
| pQ | - quaternion to conjugate | |
| [out] | pR | - conjugated quaternion |
| void csrQuatDot | ( | const CSR_Quaternion * | pQ1, |
| const CSR_Quaternion * | pQ2, | ||
| float * | pR | ||
| ) |
Calculates dot product between 2 quaternions
| pQ1 | - first quaternion | |
| pQ2 | - second quaternion | |
| [out] | pR | - resulting angle |
| void csrQuatFromAxis | ( | float | angle, |
| const CSR_Vector3 * | pAxis, | ||
| CSR_Quaternion * | pR | ||
| ) |
Gets a quaternion from an angle and a vector representing a rotation axis
| angle | - rotation angle | |
| pAxis | - rotation axis | |
| [out] | pR | - resulting quaternion |
| void csrQuatFromEuler | ( | float | angleX, |
| float | angleY, | ||
| float | angleZ, | ||
| CSR_Quaternion * | pR | ||
| ) |
Gets a quaternion from Euler angles
| angleX | - rotation angle on x axis | |
| angleY | - rotation angle on y axis | |
| angleZ | - rotation angle on z axis | |
| [out] | pR | - resulting quaternion |
| int csrQuatFromMatrix | ( | const CSR_Matrix4 * | pM, |
| CSR_Quaternion * | pR | ||
| ) |
Gets a quaternion from a matrix
| pM | - rotation matrix | |
| [out] | pR | - quaternion |
| void csrQuatFromPYR | ( | float | pitch, |
| float | yaw, | ||
| float | roll, | ||
| CSR_Quaternion * | pR | ||
| ) |
Gets a quaternion from a pitch, yaw and roll angles
| pitch | - the pitch angle in radians, pitch is comparable to a head up/down movement | |
| yaw | - the yaw angle in radians, yaw is comparable to a head left/right movement | |
| roll | - the roll angle in radians, roll is comparable to an aircraft rolling movement | |
| [out] | pR | - resulting quaternion |
| void csrQuatIdentity | ( | CSR_Quaternion * | pQ | ) |
Initializes a quaternion to its identity value
| pQ | - quaternion to initialize, initialized quaternion on function ends |
| void csrQuatInverse | ( | const CSR_Quaternion * | pQ, |
| CSR_Quaternion * | pR | ||
| ) |
Inverses the quaternion
| pQ | - quaternion to inverse | |
| [out] | pR | - inverted quaternion |
| void csrQuatLength | ( | const CSR_Quaternion * | pQ, |
| float * | pR | ||
| ) |
Gets the quaternion length
| pQ | - quaternion for which the length should be get | |
| [out] | pR | - the resulting length |
| void csrQuatLengthSquared | ( | const CSR_Quaternion * | pQ, |
| float * | pR | ||
| ) |
Gets the squared length of a quaternion
| pQ | - quaternion for which the squared length should be get | |
| [out] | pR | - the resulting squared length |
| void csrQuatMultiply | ( | const CSR_Quaternion * | pQ1, |
| const CSR_Quaternion * | pQ2, | ||
| CSR_Quaternion * | pR | ||
| ) |
Multiplies a quaternion by another
| pQ1 | - first quaternion to multiply | |
| pQ2 | - second quaternion to multiply with | |
| [out] | pR | - multiplied quaternion |
| void csrQuatNormalize | ( | const CSR_Quaternion * | pQ, |
| CSR_Quaternion * | pR | ||
| ) |
Normalizes the quaternion
| pQ | - quaternion to normalize | |
| [out] | pR | - normailzed quaternion |
| void csrQuatRotate | ( | const CSR_Quaternion * | pQ, |
| const CSR_Vector3 * | pV, | ||
| CSR_Vector3 * | pR | ||
| ) |
Rotates a vector by a quaternion
| pQ | - quaternion by which the vector will be rotated | |
| pV | - vector to rotate | |
| [out] | pR | - rotated vector |
| void csrQuatScale | ( | const CSR_Quaternion * | pQ, |
| float | s, | ||
| CSR_Quaternion * | pR | ||
| ) |
Scales a quaternion
| pQ | - quaternion to scale | |
| s | - scale factor | |
| [out] | pR | - scaled quaternion |
| int csrQuatSlerp | ( | const CSR_Quaternion * | pQ1, |
| const CSR_Quaternion * | pQ2, | ||
| float | p, | ||
| CSR_Quaternion * | pR | ||
| ) |
Gets the spherical linear interpolated quaternion between 2 quaternions
| pQ1 | - quaternion to interpolate | |
| pQ2 | - quaternion to interpolate with | |
| p | - interpolation position, in percent (between 0.0f and 1.0f) | |
| [out] | pR | - the resulting spherical linear interpolated quaternion |
| void csrQuatToMatrix | ( | const CSR_Quaternion * | pQ, |
| CSR_Matrix4 * | pR | ||
| ) |
Gets a rotation matrix from a quaternion
| pQ | - quaternion from which the matrix should be get | |
| [out] | pR | - rotation matrix |
| void csrRay2FromPointDir | ( | const CSR_Vector2 * | pP, |
| const CSR_Vector2 * | pD, | ||
| CSR_Ray2 * | pR | ||
| ) |
Calculates a ray from a point and a direction
| pP | - point | |
| pD | - direction | |
| [out] | pR | - ray |
| void csrRay3FromPointDir | ( | const CSR_Vector3 * | pP, |
| const CSR_Vector3 * | pD, | ||
| CSR_Ray3 * | pR | ||
| ) |
Calculates a ray from a point and a direction
| pP | - point | |
| pD | - direction | |
| [out] | pR | - ray |
| void csrRectEdge | ( | const CSR_Vector2 * | pPoint, |
| const CSR_Rect * | pRect, | ||
| CSR_ERect2DEdge * | pEdge | ||
| ) |
Gets on which edge of a rectangle a point is hitting
| pPoint | - point to check | |
| pRect | - rectangle to check against | |
| [out] | pEdge | - edge on which the point hit the rectangle |
| void csrSeg3ClosestPoint | ( | const CSR_Segment3 * | pS, |
| const CSR_Vector3 * | pP, | ||
| CSR_Vector3 * | pR | ||
| ) |
Calculates and gets the closest point on a line segment from a point
| pS | - line segment | |
| pP | - point | |
| [out] | pR | - closest point on the line segment |
| void csrSeg3DistanceBetween | ( | const CSR_Segment3 * | pS1, |
| const CSR_Segment3 * | pS2, | ||
| float | tolerance, | ||
| float * | pR | ||
| ) |
Gets the shortest distance between 2 line segments
| pS1 | - first line segment | |
| pS2 | - second line segment from which distance should be calculated | |
| tolerance | - tolerance for calculation | |
| [out] | pR | - resulting distance |
| void csrVec2Add | ( | const CSR_Vector2 * | pV1, |
| const CSR_Vector2 * | pV2, | ||
| CSR_Vector2 * | pR | ||
| ) |
Adds vector contents
| pV1 | - vector that contains values to be added | |
| pV2 | - vector to add to | |
| [out] | pR | - resulting vector |
| void csrVec2AddVal | ( | const CSR_Vector2 * | pV, |
| float | val, | ||
| CSR_Vector2 * | pR | ||
| ) |
Adds vector by a value
| pV | - vector that contains values to be added | |
| val | - value to add to | |
| [out] | pR | - resulting vector |
| int csrVec2BetweenRange | ( | const CSR_Vector2 * | pV, |
| const CSR_Vector2 * | pRS, | ||
| const CSR_Vector2 * | pRE, | ||
| float | tolerance | ||
| ) |
Checks if a vector is between a range of values
| pV | - vector to test |
| pRS | - range start |
| pRE | - range end |
| tolerance | - tolerance for calculation |
| void csrVec2Cross | ( | const CSR_Vector2 * | pV1, |
| const CSR_Vector2 * | pV2, | ||
| CSR_Vector2 * | pR | ||
| ) |
Calculates cross product between 2 vectors
| pV1 | - first vector | |
| pV2 | - second vector | |
| [out] | pR | - resulting vector |
| void csrVec2Div | ( | const CSR_Vector2 * | pV1, |
| const CSR_Vector2 * | pV2, | ||
| CSR_Vector2 * | pR | ||
| ) |
Divides vector contents
| pV1 | - vector that contains values to be divided | |
| pV2 | - vector to divide by | |
| [out] | pR | - resulting vector |
| void csrVec2DivVal | ( | const CSR_Vector2 * | pV, |
| float | val, | ||
| CSR_Vector2 * | pR | ||
| ) |
Divides vector by a value
| pV | - vector that contains values to be divided | |
| val | - value to divide by | |
| [out] | pR | - resulting vector |
| void csrVec2Dot | ( | const CSR_Vector2 * | pV1, |
| const CSR_Vector2 * | pV2, | ||
| float * | pR | ||
| ) |
Calculates dot product between 2 vectors
| pV1 | - first vector | |
| pV2 | - second vector | |
| [out] | pR | - resulting angle |
| void csrVec2Length | ( | const CSR_Vector2 * | pV, |
| float * | pR | ||
| ) |
Calculates vector length
| pV | - vector to calculate length | |
| [out] | pR | - vector length |
| void csrVec2Mul | ( | const CSR_Vector2 * | pV1, |
| const CSR_Vector2 * | pV2, | ||
| CSR_Vector2 * | pR | ||
| ) |
Multiplies vector contents
| pV1 | - vector that contains values to be multiplied | |
| pV2 | - vector to multiply by | |
| [out] | pR | - resulting vector |
| void csrVec2MulVal | ( | const CSR_Vector2 * | pV, |
| float | val, | ||
| CSR_Vector2 * | pR | ||
| ) |
Multiplies vector by a value
| pV | - vector that contains values to be multiplied | |
| val | - value to multiply by | |
| [out] | pR | - resulting vector |
| void csrVec2Normalize | ( | const CSR_Vector2 * | pV, |
| CSR_Vector2 * | pR | ||
| ) |
Normalizes the vector
| pV | - vector to normalize | |
| [out] | pR | - normailzed vector |
| void csrVec2Sub | ( | const CSR_Vector2 * | pV1, |
| const CSR_Vector2 * | pV2, | ||
| CSR_Vector2 * | pR | ||
| ) |
Subtracts vector contents
| pV1 | - vector that contains values to be subtracted | |
| pV2 | - vector to subtract by | |
| [out] | pR | - resulting vector |
| void csrVec2SubVal | ( | const CSR_Vector2 * | pV, |
| float | val, | ||
| CSR_Vector2 * | pR | ||
| ) |
Subtracts vector by a value
| pV | - vector that contains values to be subtracted | |
| val | - value to subtract by | |
| [out] | pR | - resulting vector |
| void csrVec3Add | ( | const CSR_Vector3 * | pV1, |
| const CSR_Vector3 * | pV2, | ||
| CSR_Vector3 * | pR | ||
| ) |
Adds vector contents
| pV1 | - vector that contains values to be added | |
| pV2 | - vector to add to | |
| [out] | pR | - resulting vector |
| void csrVec3AddVal | ( | const CSR_Vector3 * | pV, |
| float | val, | ||
| CSR_Vector3 * | pR | ||
| ) |
Adds vector by a value
| pV | - vector that contains values to be added | |
| val | - value to add to | |
| [out] | pR | - resulting vector |
| int csrVec3BetweenRange | ( | const CSR_Vector3 * | pV, |
| const CSR_Vector3 * | pRS, | ||
| const CSR_Vector3 * | pRE, | ||
| float | tolerance | ||
| ) |
Checks if a vector is between a range of values
| pV | - vector to test |
| pRS | - range start |
| pRE | - range end |
| tolerance | - tolerance for calculation |
| void csrVec3Cross | ( | const CSR_Vector3 * | pV1, |
| const CSR_Vector3 * | pV2, | ||
| CSR_Vector3 * | pR | ||
| ) |
Calculates cross product between 2 vectors
| pV1 | - first vector | |
| pV2 | - second vector | |
| [out] | pR | - resulting vector |
| void csrVec3Div | ( | const CSR_Vector3 * | pV1, |
| const CSR_Vector3 * | pV2, | ||
| CSR_Vector3 * | pR | ||
| ) |
Divides vector contents
| pV1 | - vector that contains values to be divided | |
| pV2 | - vector to divide by | |
| [out] | pR | - resulting vector |
| void csrVec3DivVal | ( | const CSR_Vector3 * | pV, |
| float | val, | ||
| CSR_Vector3 * | pR | ||
| ) |
Divides vector by a value
| pV | - vector that contains values to be divided | |
| val | - value to divide by | |
| [out] | pR | - resulting vector |
| void csrVec3Dot | ( | const CSR_Vector3 * | pV1, |
| const CSR_Vector3 * | pV2, | ||
| float * | pR | ||
| ) |
Calculates dot product between 2 vectors
| pV1 | - first vector | |
| pV2 | - second vector | |
| [out] | pR | - resulting angle |
| void csrVec3Length | ( | const CSR_Vector3 * | pV, |
| float * | pR | ||
| ) |
Calculates vector length
| pV | - vector to calculate length | |
| [out] | pR | - vector length |
| void csrVec3Mul | ( | const CSR_Vector3 * | pV1, |
| const CSR_Vector3 * | pV2, | ||
| CSR_Vector3 * | pR | ||
| ) |
Multiplies vector contents
| pV1 | - vector that contains values to be multiplied | |
| pV2 | - vector to multiply by | |
| [out] | pR | - resulting vector |
| void csrVec3MulVal | ( | const CSR_Vector3 * | pV, |
| float | val, | ||
| CSR_Vector3 * | pR | ||
| ) |
Multiplies vector by a value
| pV | - vector that contains values to be multiplied | |
| val | - value to multiply by | |
| [out] | pR | - resulting vector |
| void csrVec3Normalize | ( | const CSR_Vector3 * | pV, |
| CSR_Vector3 * | pR | ||
| ) |
Normalizes the vector
| pV | - vector to normalize | |
| [out] | pR | - normailzed vector |
| void csrVec3Sub | ( | const CSR_Vector3 * | pV1, |
| const CSR_Vector3 * | pV2, | ||
| CSR_Vector3 * | pR | ||
| ) |
Subtracts vector contents
| pV1 | - vector that contains values to be subtracted | |
| pV2 | - vector to subtract by | |
| [out] | pR | - resulting vector |
| void csrVec3SubVal | ( | const CSR_Vector3 * | pV, |
| float | val, | ||
| CSR_Vector3 * | pR | ||
| ) |
Subtracts vector by a value
| pV | - vector that contains values to be subtracted | |
| val | - value to subtract by | |
| [out] | pR | - resulting vector |


Blue
Star
Toggle navigation
Home
Rooms
W-Hall
Bar
Careers
Check available days
available
Upload Paymentslip
Enter Your email Adress
Select Your File
Submit
Weeding hall Booking
Date
Email:
Contact Number:
Number Of Clients:
NIC:
AC OR Non-AC:
Select Option
AC
NON-AC
Save
Details about hall
Price details
Normally 75000/=
Some changes according to the number of guests
Amount of guests
Maximum 500 guests
Facilities
Two rooms attached
AC or Non- AC
Best Quality background decrations


Timeseries with pan and zoom
Timeseries by second
Timeseries by minute
Timeseries by hour
Timeseries by day
Timeseries by month


WAG THE DOG (1997) a review by Christian Pyle
WAG THE DOG is a sharp satire on the manipulation of public opinion through the creation of "news." Like DR. STRANGELOVE (1964), WAG will likely be referenced by political commentators for decades to come.
Conrad Brean (Robert DeNiro), a professional problem solver, has been called in by the White House to defuse a scandal-the President, nearing reelection, has been accused of molesting a teenager. Brean and White House staffer Winifred Ames (Anne Heche) enlist movie producer Stanley Motss (Dustin Hoffman) to create "a pageant"-a nonexistent war with Albania-to distract the media and the public from the sex scandal. Motss enthusiastically plots the storyline of the war and deftly keeps the story going as unexpected events block their plans.
One of WAG's points is that the experience of war for those not actually fighting it is a collage of stirring images, patriotic songs, and memorials for heroes. Therefore, Brean and Motss give America a clip of an Albanian waif (actually an actress played by Kirsten Dunst) fleeing explosions, numerous songs, and a heroic soldier (Woody Harrelson) captured by the enemy. The war must have happened because, as Brean says several times, "I saw it on TV."
WAG's most obvious target is the use of military action as a political smokescreen. When the movie was released, many called it prophetic because, around the same time, Clinton bombed Iraq in an obvious attempt to divert attention from his own sex scandal. However, Hilary Henkin and David Mamet's screenplay drops references to Reagan and Bush's use of the same tactic. In many ways, WAG presents a better world-their war is bloodless.
Another satire, Michael Moore's CANADIAN BACON (1994), explores similar territory. In that film, the White House creates a state of tension between the U.S. and Canada to replace the Cold War. The message is the same: having a common enemy stirs up and unites the populace, and the power to manipulate that effect has numerous political applications. WAG is the better film; where BACON descended into border-crossing hijinks and was weighed down by Moore's use of its script as a soapbox, WAG is wonderfully subtle and rich in satiric detail.
The relevance of WAG extends far beyond its parallels with recent history. Daniel Boorstin coined the term "pseudo-event" to describe an event which is planned "for the immediate purpose of being reported." With today's technology, WAG THE DOG tells us, the pseudo-events can be more pseudo than events. Brean convinces Motss that the fake war can work by claiming that the most famous image of the Gulf War was filmed on a sound stage with a small model made of Legos. Seeing may be believing, but can we believe what we see? As we are swept downstream in the constant rush of mass media, can we separate the genuine from the artificial? And, if documentary evidence is suspect, what is history? Brean adds a blues song to the 1930's by planting an album in the Library of Congress. Even history is suspect.
Grade: A-
Review © 1999 Christian Pyle
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


ledger
/
net.corda.v5.ledger.transactions
/
WireTransaction
/
privacySalt
privacySalt
abstract
val
privacySalt
:
PrivacySalt


Hello, Code School!
- Have time killer tasks
- Remind me what I forgot because I didn't use this technology for a while
- Learn what is the latest toys the cool kids playing with
- In some point, learn how to create an app I can install on my iPhone
- In addition, an app I can install on my Apple Watch


Akil Buggs Birmingham, AL
Director
Film and Video director specializing in short form narrative and documentary media production. Experienced in all stages of production from conception to post production, particularly audio field recording and post mixing.
- Over 10 years experience in writing, directing, and editing videos and films for online or theatrical release.
- Proven skills in resourcefulness, capable in learning new technology quickly, and working under pressure
Professional Experience
Photographer – Present
GradImages Birmingham, AL
- Capture graduation ceremony diploma presentations and group candid photographs using Nikon digital cameras.
- Manage students for pre-ceremony portrait sessions, outside venue direct graduates and guests for candid photos
Media Production Assistant –
DePaul University Chicago, IL
Conceptualized with DePaul clients to solve project objectives for short video advertisements or campus-wide event coverage, and planned strategies for content delivery either through video or photography.
- Edited videos and photos with Adobe Creative Suite, and audio editing through Pro Tools.
- Customized HD video through compression, transfer, color correction and grading, dynamic range enhancement, green screen video compositing, and on-line video streaming during and after events.
AmeriCorps VISTA Outreach and Engagement Fellow –
Designed the Department of Service Learning's YouTube page, planned and executed production of 12 videos in three months. University of Alabama-Birmingham Birmingham, AL
- Customized Dept. of Service Learning brand on the web.
- Guided student teams in the creation of service learning videos using smart phones and Final Cut Pro X.


Project Dashboard
{% include "dash_bar.html" %}
Project Analytics
Project List
| Project | Start Date | End Date | Owner | Status |
|---|---|---|---|---|
| {{data.project_name}} | {{data.project_start}} | {{data.project_end}} | {{data.project_owner}} | {{data.project_status}} |
- {{all_vuln}} All Vulnerability
- {{total_network}} Network Vulnerability
- {{total_web}} Web Vulnerability
- {{all_high}} Total High
- {{all_medium}} Total Medium
- {{all_low}} Total Low


{{addError.Message}}
What is this?
Here you can paste the address of an XML formatted RSS feed you want to subscribe to. If you are
having trouble finding RSS feeds, the following link is a good place to start. Click here to browse feeds.
{{removeError.Message}}


Collapsible Group Item #1
Some placeholder content for the first accordion panel. This panel is shown by default, thanks to the
.show
class.
Collapsible Group Item #2
Some placeholder content for the second accordion panel. This panel is hidden by default.
Collapsible Group Item #3
And lastly, the placeholder content for the third and final accordion panel. This panel is hidden by default.


Sydney based web developer—This current project is out of pure interest in learning GUI programming derived from Eugen Kiss' GUI programming benchmark 7GUIs.
All GUI functionality so far has been implemented in vanilla JavaScript, with the hope that I can keep it that way (for learning purposes).
Feedback and collaboration is very much appreciated, feel free to submit issues or pull requests!


bumble species bee at-risk bees Bombus Colla terricola plant foraging forage common bimaculatus impatiens conservation pollen {border-style Fig. data North px;} #ffffff;} pensylvanicus using griseocolis Conservation Ontario cracca habitat nectar sites used vagans Goulson Park Table Williams site southern Provincial protected research Bumble Ontario. areas borealis family species. surveyed Accessed American Available Ontario, correlated important including near open populations Conserv. Fabaceae Fabaceae, Supplementary associated diversity families fervidus provide px; restoration season short spp.) surrounded {font-family At-risk IUCN Red collab: collected decline font-size identified number positively recorded Canada Darvill Ecol. Hatfield March Packer Richardson Species Status Thorp University Vicia analysis cracca, double; ecological floral flowers foraged forest, host identification observed perplexus plants pollinator recent requirements results species, study terricola* use wild America April August Biol. Canada. Entomol. Forest, Insect Kearns Linnaeus Primack association border-color border-width collection difference different field function invasive late-summer long management pathogen potential sampling solid; survey variables various water, {font-style {font-weight (see Appendix Area Atkinson Beckham Bees Committee Common Dumesh Endangered Forest Grixti Guelph Hymenoptera: Inouye Jepsen Jha National Plants Press, Redundancy Shannon Site Soc. Wildlife abundance abundant agricultural agriculture areas. based beach, bold breadth considered corolla courier; declines determining differences documented em; ensure fervidus* flower grassland information late length managers methods mid-summer, natural particular pensylvanicus, pollinators population preference programs pt;} question redundancy rufocinctus scattered similar specialization specimens spillover surveys ternarius tongue tongues total trees, urban water work


Controller actions are protected from Cross-Site Request Forgery (CSRF) attacks by including a token in the rendered HTML for your application. This token is stored as a random string in the session, to which an attacker does not have access. When a request reaches your application, Rails verifies the received token with the token in the session. Only HTML and JavaScript requests are checked, so this will not protect your XML API (presumably you'll have a different authentication scheme there anyway).
GET requests are not protected since they don't have side effects like writing to the database and don't leak sensitive information. JavaScript requests are an exception: a third-party site can use a <script> tag to reference a JavaScript URL on your site. When your JavaScript response loads on their site, it executes. With carefully crafted JavaScript on their end, sensitive data in your JavaScript response may be extracted. To prevent this, only XmlHttpRequest (known as XHR or Ajax) requests are allowed to make GET requests for JavaScript responses.
It's important to remember that XML or JSON requests are also affected and if you're building an API you'll need something like:
class ApplicationController < ActionController::Base
protect_from_forgery
skip_before_action :verify_authenticity_token, if: :json_request?
protected
def json_request?
request.format.json?
end
end
CSRF protection is turned on with the protect_from_forgery
method, which checks the token and resets the session if it doesn't
match what was expected. A call to this method is generated for new Rails
applications by default.
The token parameter is named authenticity_token
by default.
The name and value of this token must be added to every layout that renders
forms by including csrf_meta_tags
in the HTML
head
.
Learn more about CSRF attacks and securing your application in the Ruby on Rails Security Guide.
- MODULE ActionController::RequestForgeryProtection::ClassMethods
- MODULE ActionController::RequestForgeryProtection::ProtectionMethods
Source: show
# File<EMAIL_ADDRESS>line 208 def handle_unverified_request forgery_protection_strategy.new(self).handle_unverified_request end
The actual before_action that is used to verify the CSRF token. Don't override this directly. Provide your own forgery protection strategy instead. If you override, you'll disable same-origin `<script>` verification.
Lean on the protect_from_forgery declaration to mark which actions are due for same-origin request verification. If protect_from_forgery is enabled on an action, this before_action flags its after_action to verify that JavaScript responses are for XHR requests, ensuring they follow the browser's same-origin policy.
Source: show
# File<EMAIL_ADDRESS>line 197 def verify_authenticity_token mark_for_same_origin_verification! if !verified_request? if logger && log_warning_on_csrf_failure logger.warn "Can't verify CSRF token authenticity" end handle_unverified_request end end


libexample
A library that solves some common problems.
Overview
The project solves lots of problems: * a * b * c * etc
Index
say-hello()
My super function. Not thread-safe.
Example
echo "test: $(say-hello World)"
Arguments
-
$1 (string): A value to print
Exit codes
-
0: If successful.
-
1: If an empty string passed.


Contribution Guidelines
Apache YuniKorn (Incubating) is an Apache2 License Software.
Contributing to Apache YuniKorn (Incubating) (Source code, Documents, Image, Website) means you agree to the Apache2 License.
- Ensure your issue is logged in the Jira issue tracker. If it does not exists create a new one.
- Fork the repository you want to contribute code to.
- Contribute your patch by creating a Pull Request in our Github repository
Before you start, please read the Code of Conduct carefully, familiarize yourself with it and refer to it whenever you need it.
For those of you who are not familiar with Apache project, understanding How it works would be quite helpful.
The Review Process
When a Pull Request is submitted, it is being merged or rejected by the following review process.
- Anybody can be a reviewer and may comment on the change or suggest modifications.
- Reviewer can indicate that a patch looks suitable for merging with a comment such as: "Looks good", "LGTM", "+1".
- At least one indication of suitability (e.g. "LGTM") from a committer is required to be merged.
- Pull request is open for 1 or 2 days for potential additional review, unless it's got enough indication of suitability.
- A committer can then initiate lazy consensus ("Merge if there is no more discussion") after what the code can be merged after a certain time (normally 24 hours) if there is no more reviews.
- Contributors can ping reviewers (including committers) by commenting 'Ready to review' or suitable indication.
Becoming a Committer
The PMC adds new committers from the active contributors, based on their contribution to Apache YuniKorn.
The qualifications for new committers include:
- Sustained contributions: Committers should have a history of constant contributions to Apache YuniKorn.
- Quality of contributions: Committers more than any other community member should submit simple, well-tested, and well-designed patches.
- Community involvement: Committers should have a constructive and friendly attitude in all community interactions. They should also be active on the dev, user list and reviewing patches. Also help new contributors and users.
Setting up
Here are some things you will need to build and test Apache YuniKorn.
Detailed build steps are here.
Source Code Management (SCM)
Apache YuniKorn uses Git for its SCM system. so you'll need git client installed in your development machine.
Integrated Development Environment (IDE)
You are free to use whatever IDE you prefer, or your favorite command line editor.
Code convention
We are following Coding Guidelines:
Follow the Guidelines to help to maintain the code quality.
Getting the source code
First of all, you need the Apache YuniKorn source code from repsctive repo which you are planning to work on.
The official location for Apache YuniKorn is in the 4 repos.
git access
Get the source code on your development machine using git.
The same clone can be used for read and write (committers only) access.
Fork repository
If you want not only build Apache YuniKorn but also make change, then you need fork one or more of our 4 repositories and make a pull request.
Build
Build Tools
To build the code, install
- Go 1.11+
Building the code
Generic build (action depends on the repository)
Building the image
Tests
Each new file should have its own accompanying unit tests. Each new function should come with its own test unless it is part of a combined test.
Apache YuniKorn has tests in the following two categories:
- Unit Tests: The unit tests run as part of each package's build testing functions or behaviour of one part.
- Smoke Tests: The smoke tests run as part of each package's build and test the integrated behaviour of the packages.
Running the tests
As part of the testing of the core and the shim repositories you should also run the lint tool for the code layout and simple static code analysis. Running the lint check for a repository can be done via:


This is the normal webpage. A/B Street is being loaded in the background.
Can you feel the lag?
Switch to WASM app
Loading...


My Blog Homepage
Week-8 technical blog explaining basic usage of regular expressions.
Week-7 technical blog explaining the differences in how Ruby and JavaScript treat the concept of looping.
Week-6 technical blog explaining the basics of Ruby classes
Week-5 technical blog explaining group_by, enumerators, and Enumerable
Week-4 cultural blog pondering the aspects of tech accessibility.
Week-4 technical blog about the differences between arrays and hashes.
Week-3 technical blog post about CSS display properties
Week-1 blog post introducing git concepts


--- title: impressive concurrency benchmark for redis layout: post ---
Here is a graph of the concurrency from 1-10 requests
Concurrency of one is bad, but by 10 concurrent connections we have
already peaked at 107K GET/sHere is the graph of concurrency from 1-27000 requests
This blew my mind, there is minimal performance degradation starting
at 4000 concurrent requests and at 26000 concurrent requests the
performance is 87.6K/s .. unbelievably good
Wow, these are some really strong results. @antirez kicks some major ass!


About
About Pets Salon
Our passion for pet care is our core driving spirit that enables us to provide a high-class pet grooming service at your doorstep. We care for your pets just as we would care for our pets. Our mission at Pawsh is to disrupt the pet care delivery system and make it very friendly and transparent.
The objective is to allow you to witness the grooming process from start to finish and be satisfied with the way we perform the grooming services.
As we are gestating and rapidly growing, we are proud to state that Pawsh has been chartered to change the world of the grooming service delivery system, and we are working tirelessly to bring you a different experience. Try us once, and you will never like to go anywhere else! We promise you that!
About Me
My name is Paola Cortes I'm a Full Stack Developer based in Tijuana México.
I describe myself as a passionate developer who loves coding, open source, and the web platform.
Aside from my job, I like to create and contribute to develop web sites for small business like Pet Salon that helps me to provide a better user experience.
Business Hours
| Mon | 10:00 am - 7:00 pm |
| Tue | 10:00 am - 7:00 pm |
| Wed | 9:00 am - 5:00 pm |
| Thu | 9:00 am - 5:00 pm |
| Fri | 9:00 am - 5:00 pm |
| Sat | 9:00 am - 5:00 pm |
| Sun | Closed |


quantifiers
`Prev `__
Q
`Next `__
--------------
**quantifiers**
In techspeak and jargon, the standard metric prefixes used in the SI
(Système International) conventions for scientific measurement have dual
uses. With units of time or things that come in powers of 10, such as
money, they retain their usual meanings of multiplication by powers of
``1000 = 10^3``. But when used with bytes or other things that naturally
come in powers of 2, they usually denote multiplication by powers of
``1024 = 2^10``.
Here are the SI magnifying prefixes, along with the corresponding binary
interpretations in common use:
|
| prefix decimal binary
| kilo- 1000^1 1024^1 = 2^10 = 1,024
| mega- 1000^2 1024^2 = 2^20 = 1,048,576
| giga- 1000^3 1024^3 = 2^30 = 1,073,741,824
| tera- 1000^4 1024^4 = 2^40 = 1,099,511,627,776
| peta- 1000^5 1024^5 = 2^50 = 1,125,899,906,842,624
| exa- 1000^6 1024^6 = 2^60 = 1,152,921,504,606,846,976
| zetta- 1000^7 1024^7 = 2^70 = 1,180,591,620,717,411,303,424
| yotta- 1000^8 1024^8 = 2^80 = 1,208,925,819,614,629,174,706,176
Here are the SI fractional prefixes:
|
| prefix decimal jargon usage
| milli- 1000^-1 (seldom used in jargon)
|
micro- 1000^-2 small or human-scale (see \ `*micro-* <../M/micro-.html>`__)
|
nano- 1000^-3 even smaller (see \ `*nano-* <../N/nano-.html>`__)
|
pico- 1000^-4 even smaller yet (see \ `*pico-* <../P/pico-.html>`__)
| femto- 1000^-5 (not used in jargon—yet)
| atto- 1000^-6 (not used in jargon—yet)
| zepto- 1000^-7 (not used in jargon—yet)
| yocto- 1000^-8 (not used in jargon—yet)
The prefixes zetta-, yotta-, zepto-, and yocto- have been included in
these tables purely for completeness and giggle value; they were adopted
in 1990 by the *19th Conference Generale des Poids et Mesures*. The
binary peta- and exa- loadings, though well established, are not in
jargon use either — yet. The prefix milli-, denoting multiplication by
``1/1000``, has always been rare in jargon (there is, however, a
standard joke about the millihelen — notionally, the amount of beauty
required to launch one ship). See the entries on
`*micro-* <../M/micro-.html>`__, `*pico-* <../P/pico-.html>`__, and
`*nano-* <../N/nano-.html>`__ for more information on connotative jargon
use of these terms. ‘Femto’ and ‘atto’ (which, interestingly, derive not
from Greek but from Danish) have not yet acquired jargon loadings,
though it is easy to predict what those will be once computing
technology enters the required realms of magnitude (however, see
`*attoparsec* <../A/attoparsec.html>`__).
There are, of course, some standard unit prefixes for powers of 10. In
the following table, the ‘prefix’ column is the international standard
prefix for the appropriate power of ten; the ‘binary’ column lists
jargon abbreviations and words for the corresponding power of 2. The
B-suffixed forms are commonly used for byte quantities; the words ‘meg’
and ‘gig’ are nouns that may (but do not always) pluralize with ‘s’.
|
| prefix decimal binary pronunciation}
| kilo- k K, KB, *kay*
| mega- M M, MB, meg *meg*
| giga- G G, GB, gig *gig*,\ *jig*
Confusingly, hackers often use K or M as though they were suffix or
numeric multipliers rather than a prefix; thus “2K dollars”, “2M of disk
space”. This is also true (though less commonly) of G.
Note that the formal SI metric prefix for 1000 is ‘k’; some use this
strictly, reserving ‘K’ for multiplication by 1024 (KB is thus
‘kilobytes’).
K, M, and G used alone refer to quantities of bytes; thus, 64G is 64
gigabytes and ‘a K’ is a kilobyte (compare mainstream use of ‘a G’ as
short for ‘a grand’, that is, $1000). Whether one pronounces ‘gig’ with
hard or soft ‘g’ depends on what one thinks the proper pronunciation of
‘giga-’ is.
Confusing 1000 and 1024 (or other powers of 2 and 10 close in magnitude)
— for example, describing a memory in units of 500K or 524K instead of
512K — is a sure sign of the `*marketroid* <../M/marketroid.html>`__.
One example of this: it is common to refer to the capacity of 3.5"
floppies as ‘1.44 MB’ In fact, this is a completely
`*bogus* <../B/bogus.html>`__ number. The correct size is 1440 KB, that
is, 1440 \* 1024 = 1474560 bytes. So the ‘mega’ in ‘1.44 MB’ is
compounded of two ‘kilos’, one of which is 1024 and the other of which
is 1000. The correct number of megabytes would of course be 1440 / 1024
= 1.40625. Alas, this fine point is probably lost on the world forever.
[1993 update: hacker Morgan Burke has proposed, to general approval on
Usenet, the following additional prefixes:
+-----------+----------+
| groucho | 10^-30 |
+-----------+----------+
| harpo | 10^-27 |
+-----------+----------+
| harpi | 10^27 |
+-----------+----------+
| grouchi | 10^30 |
+-----------+----------+
We observe that this would leave the prefixes zeppo-, gummo-, and chico-
available for future expansion. Sadly, there is little immediate
prospect that Mr. Burke's eminently sensible proposal will be ratified.]
--------------
+------------------------------------+----------------------------+-----------------------------------------+
| `Prev `__ | `Up <../Q.html>`__ | `Next `__ |
+------------------------------------+----------------------------+-----------------------------------------+
| quadruple bucky | `Home <../index.html>`__ | quantum bogodynamics |
+------------------------------------+----------------------------+-----------------------------------------+


Dialogs
Two most frequntly used dialogs are alert and cofirm. In the case of a alert you just need to display a message to the user and require no feedback
besides user acknowledgement. Confirm dialog has similar purpose, but expects from the user a response by accepting or declining to the request.
The w2ui library includes these dialogs for your convenience.
Alert
The alert dialog can be called in the following way:
The method takes one or two arguments w2alert(msg, [title], [callBack]), where msg is the message to display. You
can optionally supply title for the message. If you need to define more options, you can use $().w2popup().
Confirm
The confirm dialog can be called in the following way:
The method takes up to three arguments w2confirm(msg, [title], [callBack]), where msg is the message to display.
You can optionally supply title for the message and a call back function.


The IMPC is a confederation of international mouse phenotyping projects working towards the agreed goals of the consortium: To undertake the phenotyping of 20,000 mouse mutants over a ten year period, providing the first functional annotation of a mammalian genome.
Source: Extract from page `Coordination` [2018/08/10]
This plugin was not developed by the IMPC team. IMPC neither supports nor endorses this work. References to IMPC in this plugin are meant only to credit the source of data.
Example queries: 'MGI:104510', 'Ptpn2'


Scottish Football LIVE: Celtic target midfielder in January, Hearts interview experienced coach for job, Hibs goalkeeper on exclusion
by Joel SkedCeltic winger Jonny Hayes is interesting a number of English sides, Aberdeen boss on transfer interest and Lewis Morgan backs new Hibs boss.
The live blog is back and we will have all the latest from around the SPFL. News, transfer speculation and more as Jack Ross is to be introduced to the media as Hibs boss.


--- layout: post title: The lunatics have taken over the asylum date: 2007-01-19 18:41:29.000000000 +01:00 type: post published: true status: publish categories: - coding - fun - horror - life - ruby tags: [] meta: _publicize_job_id: '14401149147' original_post_id: '89' _wp_old_slug: '89' author: login: joesixpack email<EMAIL_ADDRESS>display_name: dirk lüsebrink first_name: '' last_name: '' ---
in Monschau, Germany(the middle of nowhere), "The Web´s most ambitious RUBY ON RAILS Startup" started looking for some fellow ruby coder to kick-off their project. But there is a twist, a big one:
MUST BE BORN BETWEEN JULY 24 AND AUGUST 22 OR NOVEMBER 23 AND DECEMBER 19 AND BE BETWEEN 18 AND 99 YEARS YOUNG
And seemingly the search with increasing despair:
15th Jan: Startup looking for web designer/programmer/co-founder
and latest to date:
18th Jan: The most ambitious Ruby on Rails project calls for a Rail’s guru to lead team as Co-founder
RoR, TDD, AJAX!, scalable websites, whatever you like, you name it you get it, its all there and you can become "importend" part and development team lead, Co-founder even!
"NOVEMBER 23 AND DECEMBER 19 ", sigh, and so another bright future fades away for me, 16th Nov, misssed by a few days, phew.
oh, and some more requirements are piling up, you won't make it without
a deep love for humanity and the relentless will to facilitate happiness and emotional fulfilment for all.
yep, ok for me!, but as i said, wrong dates. The position is "Full-Time", but please keep in mind:
There is no immediate compensation for the first few months. Once the first round of financing is finalized then we will begin paying a salary.
so better bring you own, for the "entrepreneurial" spirit i guess. Me beeing you would contact Gabriella von Schadewitz right away in case i would be more lucky with the stars.
have fun
and oh, don't forget to check their website: http://simplyooh.com