SYNOPSIS
/etc/gitweb.conf, /etc/gitweb-common.conf, $GITWEBDIR/gitweb_config.perl
DESCRIPTION
The gitweb CGI script for viewing Git repositories over the web uses a
perl script fragment as its configuration file. You can set variables
using "our $variable = value
"; text from a "#" character until the
end of a line is ignored. See perlsyn(1) for details.
An example:
# gitweb configuration file for http://git.example.org
#
our $projectroot = "/srv/git"; # FHS recommendation
our $site_name = 'Example.org >> Repos';
The configuration file is used to override the default settings that were built into gitweb at the time the gitweb.cgi script was generated.
While one could just alter the configuration settings in the gitweb CGI itself, those changes would be lost upon upgrade. Configuration settings might also be placed into a file in the same directory as the CGI script with the default name gitweb_config.perl — allowing one to have multiple gitweb instances with different configurations by the use of symlinks.
Note that some configuration can be controlled on per-repository rather than gitweb-wide basis: see "Per-repository gitweb configuration" subsection on gitweb(1) manpage.
DISCUSSION
Gitweb reads configuration data from the following sources in the following order:
-
built-in values (some set during build stage),
-
common system-wide configuration file (defaults to /etc/gitweb-common.conf),
-
either per-instance configuration file (defaults to gitweb_config.perl in the same directory as the installed gitweb), or if it does not exists then fallback system-wide configuration file (defaults to /etc/gitweb.conf).
Values obtained in later configuration files override values obtained earlier in the above sequence.
Locations of the common system-wide configuration file, the fallback
system-wide configuration file and the per-instance configuration file
are defined at compile time using build-time Makefile configuration
variables, respectively GITWEB_CONFIG_COMMON
, GITWEB_CONFIG_SYSTEM
and GITWEB_CONFIG
.
You can also override locations of gitweb configuration files during
runtime by setting the following environment variables:
GITWEB_CONFIG_COMMON
, GITWEB_CONFIG_SYSTEM
and GITWEB_CONFIG
to a non-empty value.
The syntax of the configuration files is that of Perl, since these files are
handled by sourcing them as fragments of Perl code (the language that
gitweb itself is written in). Variables are typically set using the
our
qualifier (as in "our $variable = <value>;
") to avoid syntax
errors if a new version of gitweb no longer uses a variable and therefore
stops declaring it.
You can include other configuration file using read_config_file() subroutine. For example, one might want to put gitweb configuration related to access control for viewing repositories via Gitolite (one of git repository management tools) in a separate file, e.g. in /etc/gitweb-gitolite.conf. To include it, put
read_config_file("/etc/gitweb-gitolite.conf");
somewhere in gitweb configuration file used, e.g. in per-installation gitweb configuration file. Note that read_config_file() checks itself that the file it reads exists, and does nothing if it is not found. It also handles errors in included file.
The default configuration with no configuration file at all may work
perfectly well for some installations. Still, a configuration file is
useful for customizing or tweaking the behavior of gitweb in many ways, and
some optional features will not be present unless explicitly enabled using
the configurable %features
variable (see also "Configuring gitweb
features" section below).
CONFIGURATION VARIABLES
Some configuration variables have their default values (embedded in the CGI script) set during building gitweb — if that is the case, this fact is put in their description. See gitweb’s INSTALL file for instructions on building and installing gitweb.
Location of repositories
The configuration variables described below control how gitweb finds git repositories, and how repositories are displayed and accessed.
See also "Repositories" and later subsections in gitweb(1) manpage.
- $projectroot
-
Absolute filesystem path which will be prepended to project path; the path to repository is
$projectroot/$project
. Set to$GITWEB_PROJECTROOT
during installation. This variable has to be set correctly for gitweb to find repositories.For example, if
$projectroot
is set to "/srv/git" by putting the following in gitweb config file:our $projectroot = "/srv/git";
then
http://git.example.com/gitweb.cgi?p=foo/bar.git
and its path_info based equivalent
http://git.example.com/gitweb.cgi/foo/bar.git
will map to the path /srv/git/foo/bar.git on the filesystem.
- $projects_list
-
Name of a plain text file listing projects, or a name of directory to be scanned for projects.
Project list files should list one project per line, with each line having the following format
<URI-encoded filesystem path to repository> SP <URI-encoded repository owner>
The default value of this variable is determined by the
GITWEB_LIST
makefile variable at installation time. If this variable is empty, gitweb will fall back to scanning the$projectroot
directory for repositories. - $project_maxdepth
-
If
$projects_list
variable is unset, gitweb will recursively scan filesystem for git repositories. The$project_maxdepth
is used to limit traversing depth, relative to$projectroot
(starting point); it means that directories which are further from$projectroot
than$project_maxdepth
will be skipped.It is purely performance optimization, originally intended for MacOS X, where recursive directory traversal is slow. Gitweb follows symbolic links, but it detects cycles, ignoring any duplicate files and directories.
The default value of this variable is determined by the build-time configuration variable
GITWEB_PROJECT_MAXDEPTH
, which defaults to 2007. - $export_ok
-
Show repository only if this file exists (in repository). Only effective if this variable evaluates to true. Can be set when building gitweb by setting
GITWEB_EXPORT_OK
. This path is relative toGIT_DIR
. git-daemon[1] uses git-daemon-export-ok, unless started with--export-all
. By default this variable is not set, which means that this feature is turned off. - $export_auth_hook
-
Function used to determine which repositories should be shown. This subroutine should take one parameter, the full path to a project, and if it returns true, that project will be included in the projects list and can be accessed through gitweb as long as it fulfills the other requirements described by $export_ok, $projects_list, and $projects_maxdepth. Example:
our $export_auth_hook = sub { return -e "$_[0]/git-daemon-export-ok"; };
though the above might be done by using
$export_ok
insteadour $export_ok = "git-daemon-export-ok";
If not set (default), it means that this feature is disabled.
See also more involved example in "Controlling access to git repositories" subsection on gitweb(1) manpage.
- $strict_export
-
Only allow viewing of repositories also shown on the overview page. This for example makes
$gitweb_export_ok
file decide if repository is available and not only if it is shown. If$gitweb_list
points to file with list of project, only those repositories listed would be available for gitweb. Can be set during building gitweb viaGITWEB_STRICT_EXPORT
. By default this variable is not set, which means that you can directly access those repositories that are hidden from projects list page (e.g. the are not listed in the $projects_list file).
Finding files
The following configuration variables tell gitweb where to find files. The values of these variables are paths on the filesystem.
- $GIT
-
Core git executable to use. By default set to
$GIT_BINDIR/git
, which in turn is by default set to$(bindir)/git
. If you use git installed from a binary package, you should usually set this to "/usr/bin/git". This can just be "git" if your web server has a sensible PATH; from security point of view it is better to use absolute path to git binary. If you have multiple git versions installed it can be used to choose which one to use. Must be (correctly) set for gitweb to be able to work. - $mimetypes_file
-
File to use for (filename extension based) guessing of MIME types before trying /etc/mime.types. NOTE that this path, if relative, is taken as relative to the current git repository, not to CGI script. If unset, only /etc/mime.types is used (if present on filesystem). If no mimetypes file is found, mimetype guessing based on extension of file is disabled. Unset by default.
- $highlight_bin
-
Path to the highlight executable to use (it must be the one from http://www.andre-simon.de due to assumptions about parameters and output). By default set to highlight; set it to full path to highlight executable if it is not installed on your web server’s PATH. Note that highlight feature must be set for gitweb to actually use syntax highlighting.
NOTE: if you want to add support for new file type (supported by "highlight" but not used by gitweb), you need to modify
%highlight_ext
or%highlight_basename
, depending on whether you detect type of file based on extension (for example "sh") or on its basename (for example "Makefile"). The keys of these hashes are extension and basename, respectively, and value for given key is name of syntax to be passed via--syntax <syntax>
to highlighter.For example if repositories you are hosting use "phtml" extension for PHP files, and you want to have correct syntax-highlighting for those files, you can add the following to gitweb configuration:
our %highlight_ext; $highlight_ext{'phtml'} = 'php';
Links and their targets
The configuration variables described below configure some of gitweb links:
their target and their look (text or image), and where to find page
prerequisites (stylesheet, favicon, images, scripts). Usually they are left
at their default values, with the possible exception of @stylesheets
variable.
- @stylesheets
-
List of URIs of stylesheets (relative to the base URI of a page). You might specify more than one stylesheet, for example to use "gitweb.css" as base with site specific modifications in a separate stylesheet to make it easier to upgrade gitweb. For example, you can add a
site
stylesheet by puttingpush @stylesheets, "gitweb-site.css";
in the gitweb config file. Those values that are relative paths are relative to base URI of gitweb.
This list should contain the URI of gitweb’s standard stylesheet. The default URI of gitweb stylesheet can be set at build time using the
GITWEB_CSS
makefile variable. Its default value is static/gitweb.css (or static/gitweb.min.css if theCSSMIN
variable is defined, i.e. if CSS minifier is used during build).Note: there is also a legacy
$stylesheet
configuration variable, which was used by older gitweb. If$stylesheet
variable is defined, only CSS stylesheet given by this variable is used by gitweb. - $logo
-
Points to the location where you put git-logo.png on your web server, or to be more the generic URI of logo, 72x27 size). This image is displayed in the top right corner of each gitweb page and used as a logo for the Atom feed. Relative to the base URI of gitweb (as a path). Can be adjusted when building gitweb using
GITWEB_LOGO
variable By default set to static/git-logo.png. - $favicon
-
Points to the location where you put git-favicon.png on your web server, or to be more the generic URI of favicon, which will be served as "image/png" type. Web browsers that support favicons (website icons) may display them in the browser’s URL bar and next to the site name in bookmarks. Relative to the base URI of gitweb. Can be adjusted at build time using
GITWEB_FAVICON
variable. By default set to static/git-favicon.png. - $javascript
-
Points to the location where you put gitweb.js on your web server, or to be more generic the URI of JavaScript code used by gitweb. Relative to the base URI of gitweb. Can be set at build time using the
GITWEB_JS
build-time configuration variable.The default value is either static/gitweb.js, or static/gitweb.min.js if the
JSMIN
build variable was defined, i.e. if JavaScript minifier was used at build time. Note that this single file is generated from multiple individual JavaScript "modules". - $home_link
-
Target of the home link on the top of all pages (the first part of view "breadcrumbs"). By default it is set to the absolute URI of a current page (to the value of
$my_uri
variable, or to "/" if$my_uri
is undefined or is an empty string). - $home_link_str
-
Label for the "home link" at the top of all pages, leading to
$home_link
(usually the main gitweb page, which contains the projects list). It is used as the first component of gitweb’s "breadcrumb trail":<home link> / <project> / <action>
. Can be set at build time using theGITWEB_HOME_LINK_STR
variable. By default it is set to "projects", as this link leads to the list of projects. Other popular choice it to set it to the name of site. - $logo_url
- $logo_label
-
URI and label (title) for the Git logo link (or your site logo, if you chose to use different logo image). By default, these both refer to git homepage, http://git-scm.com; in the past, they pointed to git documentation at http://www.kernel.org.
Changing gitweb’s look
You can adjust how pages generated by gitweb look using the variables described below. You can change the site name, add common headers and footers for all pages, and add a description of this gitweb installation on its main page (which is the projects list page), etc.
- $site_name
-
Name of your site or organization, to appear in page titles. Set it to something descriptive for clearer bookmarks etc. If this variable is not set or is, then gitweb uses the value of the
SERVER_NAME
CGI environment variable, setting site name to "$SERVER_NAME Git", or "Untitled Git" if this variable is not set (e.g. if running gitweb as standalone script).Can be set using the
GITWEB_SITENAME
at build time. Unset by default. - $site_html_head_string
-
HTML snippet to be included in the <head> section of each page. Can be set using
GITWEB_SITE_HTML_HEAD_STRING
at build time. No default value. - $site_header
-
Name of a file with HTML to be included at the top of each page. Relative to the directory containing the gitweb.cgi script. Can be set using
GITWEB_SITE_HEADER
at build time. No default value. - $site_footer
-
Name of a file with HTML to be included at the bottom of each page. Relative to the directory containing the gitweb.cgi script. Can be set using
GITWEB_SITE_FOOTER
at build time. No default value. - $home_text
-
Name of a HTML file which, if it exists, is included on the gitweb projects overview page ("projects_list" view). Relative to the directory containing the gitweb.cgi script. Default value can be adjusted during build time using
GITWEB_HOMETEXT
variable. By default set to indextext.html. - $projects_list_description_width
-
The width (in characters) of the "Description" column of the projects list. Longer descriptions will be truncated (trying to cut at word boundary); the full description is available in the title attribute (usually shown on mouseover). The default is 25, which might be too small if you use long project descriptions.
- $default_projects_order
-
Default value of ordering of projects on projects list page, which means the ordering used if you don’t explicitly sort projects list (if there is no "o" CGI query parameter in the URL). Valid values are "none" (unsorted), "project" (projects are by project name, i.e. path to repository relative to
$projectroot
), "descr" (project description), "owner", and "age" (by date of most current commit).Default value is "project". Unknown value means unsorted.
Changing gitweb’s behavior
These configuration variables control internal gitweb behavior.
- $default_blob_plain_mimetype
-
Default mimetype for the blob_plain (raw) view, if mimetype checking doesn’t result in some other type; by default "text/plain". Gitweb guesses mimetype of a file to display based on extension of its filename, using
$mimetypes_file
(if set and file exists) and /etc/mime.types files (see mime.types(5) manpage; only filename extension rules are supported by gitweb). - $default_text_plain_charset
-
Default charset for text files. If this is not set, the web server configuration will be used. Unset by default.
- $fallback_encoding
-
Gitweb assumes this charset when a line contains non-UTF-8 characters. The fallback decoding is used without error checking, so it can be even "utf-8". The value must be a valid encoding; see the Encoding::Supported(3pm) man page for a list. The default is "latin1", aka. "iso-8859-1".
- @diff_opts
-
Rename detection options for git-diff and git-diff-tree. The default is ('-M'); set it to ('-C') or ('-C', '-C') to also detect copies, or set it to () i.e. empty list if you don’t want to have renames detection.
Note that rename and especially copy detection can be quite CPU-intensive. Note also that non git tools can have problems with patches generated with options mentioned above, especially when they involve file copies ('-C') or criss-cross renames ('-B').
Some optional features and policies
Most of features are configured via %feature
hash; however some of extra
gitweb features can be turned on and configured using variables described
below. This list beside configuration variables that control how gitweb
looks does contain variables configuring administrative side of gitweb
(e.g. cross-site scripting prevention; admittedly this as side effect
affects how "summary" pages look like, or load limiting).
- @git_base_url_list
-
List of git base URLs. These URLs are used to generate URLs describing from where to fetch a project, which are shown on project summary page. The full fetch URL is "
$git_base_url/$project
", for each element of this list. You can set up multiple base URLs (for example one forgit://
protocol, and one forhttp://
protocol).Note that per repository configuration can be set in $GIT_DIR/cloneurl file, or as values of multi-value
gitweb.url
configuration variable in project config. Per-repository configuration takes precedence over value composed from@git_base_url_list
elements and project name.You can setup one single value (single entry/item in this list) at build time by setting the
GITWEB_BASE_URL
built-time configuration variable. By default it is set to (), i.e. an empty list. This means that gitweb would not try to create project URL (to fetch) from project name. - $projects_list_group_categories
-
Whether to enables the grouping of projects by category on the project list page. The category of a project is determined by the
$GIT_DIR/category
file or thegitweb.category
variable in each repository’s configuration. Disabled by default (set to 0). - $project_list_default_category
-
Default category for projects for which none is specified. If this is set to the empty string, such projects will remain uncategorized and listed at the top, above categorized projects. Used only if project categories are enabled, which means if
$projects_list_group_categories
is true. By default set to "" (empty string). - $prevent_xss
-
If true, some gitweb features are disabled to prevent content in repositories from launching cross-site scripting (XSS) attacks. Set this to true if you don’t trust the content of your repositories. False by default (set to 0).
- $maxload
-
Used to set the maximum load that we will still respond to gitweb queries. If the server load exceeds this value then gitweb will return "503 Service Unavailable" error. The server load is taken to be 0 if gitweb cannot determine its value. Currently it works only on Linux, where it uses /proc/loadavg; the load there is the number of active tasks on the system — processes that are actually running — averaged over the last minute.
Set
$maxload
to undefined value (undef
) to turn this feature off. The default value is 300. - $omit_age_column
-
If true, omit the column with date of the most current commit on the projects list page. It can save a bit of I/O and a fork per repository.
- $omit_owner
-
If true prevents displaying information about repository owner.
- $per_request_config
-
If this is set to code reference, it will be run once for each request. You can set parts of configuration that change per session this way. For example, one might use the following code in a gitweb configuration file
our $per_request_config = sub { $ENV{GL_USER} = $cgi->remote_user || "gitweb"; };
If
$per_request_config
is not a code reference, it is interpreted as boolean value. If it is true gitweb will process config files once per request, and if it is false gitweb will process config files only once, each time it is executed. True by default (set to 1).NOTE:
$my_url
,$my_uri
, and$base_url
are overwritten with their default values before every request, so if you want to change them, be sure to set this variable to true or a code reference effecting the desired changes.This variable matters only when using persistent web environments that serve multiple requests using single gitweb instance, like mod_perl, FastCGI or Plackup.
Other variables
Usually you should not need to change (adjust) any of configuration variables described below; they should be automatically set by gitweb to correct value.
- $version
-
Gitweb version, set automatically when creating gitweb.cgi from gitweb.perl. You might want to modify it if you are running modified gitweb, for example
our $version .= " with caching";
if you run modified version of gitweb with caching support. This variable is purely informational, used e.g. in the "generator" meta header in HTML header.
- $my_url
- $my_uri
-
Full URL and absolute URL of the gitweb script; in earlier versions of gitweb you might have need to set those variables, but now there should be no need to do it. See
$per_request_config
if you need to set them still. - $base_url
-
Base URL for relative URLs in pages generated by gitweb, (e.g.
$logo
,$favicon
,@stylesheets
if they are relative URLs), needed and used <base href="$base_url"> only for URLs with nonempty PATH_INFO. Usually gitweb sets its value correctly, and there is no need to set this variable, e.g. to $my_uri or "/". See$per_request_config
if you need to override it anyway.
CONFIGURING GITWEB FEATURES
Many gitweb features can be enabled (or disabled) and configured using the
%feature
hash. Names of gitweb features are keys of this hash.
Each %feature
hash element is a hash reference and has the following
structure:
"<feature_name>" => {
"sub" => <feature-sub (subroutine)>,
"override" => <allow-override (boolean)>,
"default" => [ <options>... ]
},
Some features cannot be overridden per project. For those
features the structure of appropriate %feature
hash element has a simpler
form:
"<feature_name>" => {
"override" => 0,
"default" => [ <options>... ]
},
As one can see it lacks the 'sub' element.
The meaning of each part of feature configuration is described below:
- default
-
List (array reference) of feature parameters (if there are any), used also to toggle (enable or disable) given feature.
Note that it is currently always an array reference, even if feature doesn’t accept any configuration parameters, and 'default' is used only to turn it on or off. In such case you turn feature on by setting this element to
[1]
, and torn it off by setting it to[0]
. See also the passage about the "blame" feature in the "Examples" section.To disable features that accept parameters (are configurable), you need to set this element to empty list i.e.
[]
. - override
-
If this field has a true value then the given feature is overriddable, which means that it can be configured (or enabled/disabled) on a per-repository basis.
Usually given "<feature>" is configurable via the
gitweb.<feature>
config variable in the per-repository git configuration file.Note that no feature is overriddable by default.
- sub
-
Internal detail of implementation. What is important is that if this field is not present then per-repository override for given feature is not supported.
You wouldn’t need to ever change it in gitweb config file.
Features in %feature
The gitweb features that are configurable via %feature
hash are listed
below. This should be a complete list, but ultimately the authoritative
and complete list is in gitweb.cgi source code, with features described
in the comments.
- blame
-
Enable the "blame" and "blame_incremental" blob views, showing for each line the last commit that modified it; see git-blame(1). This can be very CPU-intensive and is therefore disabled by default.
This feature can be configured on a per-repository basis via repository’s
gitweb.blame
configuration variable (boolean). - snapshot
-
Enable and configure the "snapshot" action, which allows user to download a compressed archive of any tree or commit, as produced by git-archive(1) and possibly additionally compressed. This can potentially generate high traffic if you have large project.
The value of 'default' is a list of names of snapshot formats, defined in
%known_snapshot_formats
hash, that you wish to offer. Supported formats include "tgz", "tbz2", "txz" (gzip/bzip2/xz compressed tar archive) and "zip"; please consult gitweb sources for a definitive list. By default only "tgz" is offered.This feature can be configured on a per-repository basis via repository’s
gitweb.blame
configuration variable, which contains a comma separated list of formats or "none" to disable snapshots. Unknown values are ignored. - grep
-
Enable grep search, which lists the files in currently selected tree (directory) containing the given string; see git-grep(1). This can be potentially CPU-intensive, of course. Enabled by default.
This feature can be configured on a per-repository basis via repository’s
gitweb.grep
configuration variable (boolean). - pickaxe
-
Enable the so called pickaxe search, which will list the commits that introduced or removed a given string in a file. This can be practical and quite faster alternative to "blame" action, but it is still potentially CPU-intensive. Enabled by default.
The pickaxe search is described in git-log(1) (the description of
-S<string>
option, which refers to pickaxe entry in gitdiffcore(7) for more details).This feature can be configured on a per-repository basis by setting repository’s
gitweb.pickaxe
configuration variable (boolean). - show-sizes
-
Enable showing size of blobs (ordinary files) in a "tree" view, in a separate column, similar to what
ls -l
does; see description of-l
option in git-ls-tree(1) manpage. This costs a bit of I/O. Enabled by default.This feature can be configured on a per-repository basis via repository’s
gitweb.showsizes
configuration variable (boolean). - patches
-
Enable and configure "patches" view, which displays list of commits in email (plain text) output format; see also git-format-patch(1). The value is the maximum number of patches in a patchset generated in "patches" view. Set the default field to a list containing single item of or to an empty list to disable patch view, or to a list containing a single negative number to remove any limit. Default value is 16.
This feature can be configured on a per-repository basis via repository’s
gitweb.patches
configuration variable (integer). - avatar
-
Avatar support. When this feature is enabled, views such as "shortlog" or "commit" will display an avatar associated with the email of each committer and author.
Currently available providers are "gravatar" and "picon". Only one provider at a time can be selected (default is one element list). If an unknown provider is specified, the feature is disabled. Note that some providers might require extra Perl packages to be installed; see gitweb/INSTALL for more details.
This feature can be configured on a per-repository basis via repository’s
gitweb.avatar
configuration variable.See also
%avatar_size
with pixel sizes for icons and avatars ("default" is used for one-line like "log" and "shortlog", "double" is used for two-line like "commit", "commitdiff" or "tag"). If the default font sizes or lineheights are changed (e.g. via adding extra CSS stylesheet in@stylesheets
), it may be appropriate to change these values. - highlight
-
Server-side syntax highlight support in "blob" view. It requires
$highlight_bin
program to be available (see the description of this variable in the "Configuration variables" section above), and therefore is disabled by default.This feature can be configured on a per-repository basis via repository’s
gitweb.highlight
configuration variable (boolean). - remote_heads
-
Enable displaying remote heads (remote-tracking branches) in the "heads" list. In most cases the list of remote-tracking branches is an unnecessary internal private detail, and this feature is therefore disabled by default. git-instaweb(1), which is usually used to browse local repositories, enables and uses this feature.
This feature can be configured on a per-repository basis via repository’s
gitweb.remote_heads
configuration variable (boolean).
The remaining features cannot be overridden on a per project basis.
- search
-
Enable text search, which will list the commits which match author, committer or commit text to a given string; see the description of
--author
,--committer
and--grep
options in git-log(1) manpage. Enabled by default.Project specific override is not supported.
- forks
-
If this feature is enabled, gitweb considers projects in subdirectories of project root (basename) to be forks of existing projects. For each project
$projname.git
, projects in the$projname/
directory and its subdirectories will not be shown in the main projects list. Instead, a '+' mark is shown next to$projname
, which links to a "forks" view that lists all the forks (all projects in$projname/
subdirectory). Additionally a "forks" view for a project is linked from project summary page.If the project list is taken from a file (
$projects_list
points to a file), forks are only recognized if they are listed after the main project in that file.Project specific override is not supported.
- actions
-
Insert custom links to the action bar of all project pages. This allows you to link to third-party scripts integrating into gitweb.
The "default" value consists of a list of triplets in the form ‘("<label>", "<link>", "<position>")` where "position" is the label after which to insert the link, "link" is a format string where
%n
expands to the project name,%f
to the project path within the filesystem (i.e. "$projectroot/$project"),%h
to the current hash ('h’ gitweb parameter) and ‘%b` to the current hash base ('hb’ gitweb parameter); ‘%%` expands to '%’.For example, at the time this page was written, the http://repo.or.cz git hosting site set it to the following to enable graphical log (using the third party tool git-browser):
$feature{'actions'}{'default'} = [ ('graphiclog', '/git-browser/by-commit.html?r=%n', 'summary')];
This adds a link titled "graphiclog" after the "summary" link, leading to
git-browser
script, passingr=<project>
as a query parameter.Project specific override is not supported.
- timed
-
Enable displaying how much time and how many git commands it took to generate and display each page in the page footer (at the bottom of page). For example the footer might contain: "This page took 6.53325 seconds and 13 git commands to generate." Disabled by default.
Project specific override is not supported.
- javascript-timezone
-
Enable and configure the ability to change a common timezone for dates in gitweb output via JavaScript. Dates in gitweb output include authordate and committerdate in "commit", "commitdiff" and "log" views, and taggerdate in "tag" view. Enabled by default.
The value is a list of three values: a default timezone (for if the client hasn’t selected some other timezone and saved it in a cookie), a name of cookie where to store selected timezone, and a CSS class used to mark up dates for manipulation. If you want to turn this feature off, set "default" to empty list:
[]
.Typical gitweb config files will only change starting (default) timezone, and leave other elements at their default values:
$feature{'javascript-timezone'}{'default'}[0] = "utc";
The example configuration presented here is guaranteed to be backwards and forward compatible.
Timezone values can be "local" (for local timezone that browser uses), "utc" (what gitweb uses when JavaScript or this feature is disabled), or numerical timezones in the form of "+/-HHMM", such as "+0200".
Project specific override is not supported.
EXAMPLES
To enable blame, pickaxe search, and snapshot support (allowing "tar.gz" and "zip" snapshots), while allowing individual projects to turn them off, put the following in your GITWEB_CONFIG file:
$feature{'blame'}{'default'} = [1];
$feature{'blame'}{'override'} = 1;
$feature{'pickaxe'}{'default'} = [1];
$feature{'pickaxe'}{'override'} = 1;
$feature{'snapshot'}{'default'} = ['zip', 'tgz'];
$feature{'snapshot'}{'override'} = 1;
If you allow overriding for the snapshot feature, you can specify which snapshot formats are globally disabled. You can also add any command line options you want (such as setting the compression level). For instance, you can disable Zip compressed snapshots and set gzip(1) to run at level 6 by adding the following lines to your gitweb configuration file:
$known_snapshot_formats{'zip'}{'disabled'} = 1;
$known_snapshot_formats{'tgz'}{'compressor'} = ['gzip','-6'];
ENVIRONMENT
The location of per-instance and system-wide configuration files can be overridden using the following environment variables:
- GITWEB_CONFIG
-
Sets location of per-instance configuration file.
- GITWEB_CONFIG_SYSTEM
-
Sets location of fallback system-wide configuration file. This file is read only if per-instance one does not exist.
- GITWEB_CONFIG_COMMON
-
Sets location of common system-wide configuration file.
FILES
- gitweb_config.perl
-
This is default name of per-instance configuration file. The format of this file is described above.
- /etc/gitweb.conf
-
This is default name of fallback system-wide configuration file. This file is used only if per-instance configuration variable is not found.
- /etc/gitweb-common.conf
-
This is default name of common system-wide configuration file.
SEE ALSO
gitweb/README, gitweb/INSTALL
GIT
Part of the git(1) suite


Select the module that you want to administrate
This is the main home page of the RIFE/crud sample administration interface.
Choose a module in the menu to administrate a particular section.


Hello
World
Hello World Tech Conference 2020
February 15th, Porto, Portugal
Get Your Ticket
Speakers
Schedule
Sponsors
Be a Sponsor
Location


The
format is developed based on the results of the AK Equipment Exchange from 2007-02-07,
version 0.9 (see [1]) and example files of different manufacturers. First prototypes
have been realized by
Version
1.0 is developed in Dec 2009 by the companies KT Automotive, Messring, MSC and
Kistler. Intention of the 1.0 version is the ability of the format to exchange
a complete set of sensor and dummy data from one database to another without
loss of information. Support of EQX version 1.0 is realized since CrashDesigner
V2.6.1 by KT Automotive.
Version
1.1 is a compatible enhancement to V1.0 in Oct 2010 by KT Automotive. It
additionally supports the exchange of test setups with ISO attributes and
additional company specific attributes for the test and the test objects. It
was requested by users to realize the exchange with 3rd party test
preparation software packages. Support of EQX 1.1 is provided in CrashDesigner
V2.7.1 by KT Automotive.
Version
1.2 is a compatible enhancement to V1.1 in Jul 2011 by Kistler. Optional
attributes are allowed on sensor axes and calibration entries and additional
fix attributes are defined to fully support test setup exchanges.
Version
1.3 is a compatible enhancement to V1.2 in May 2012 as a result of a
stakeholder meeting at TRW on 2012-03-15. It contains additional optional
attributes for calibration entries and additional SensorGroup
Categories.
Version
1.4 is a compatible enhancement to V1.3 in Jul 2014 by Kistler. Exchange of
digitally calibrated sensors, operated in LSB (least significant bit) instead
of mV is added. ID module types are enhanced. Elements to specify the bridge
resistors are added.
Version
1.5 is a compatible enhancement to V1.4 in Jul 2016 as discussed and agreed in
a web meeting on 2016-05-11 and a meeting at Messring
on 2016-06-22 with participants from ZF/TRW, Kistler, DTS, Hentschel,
Messring, measX, IAT.
SensorGroup
enhancements:
·
New
category ‘Equipment’ for the exchange of peripheral equipment.
·
New
element ‘Path’ to specify structure information for a group.
SensorAxis
enhancements:
·
New
scaling method ‘Linear with Offset’.
·
New
connector types ‘Tajimi 7pol flat’ and ‘Micro D 15pol’.
·
New
Electrical methods ‘Half Bridge Poti’, ‘Quarter
Bridge’, ‘High Voltage Input’.
·
New
element ‘NominalValue’ as a complement to the ‘MinRange’ and ‘MaxRange’ elements
in an asymmetrically used context.
·
New
elements ‘SWOffsetCompensationType’, ‘SWOffsetCalculationStartSec’, ‘SWOffsetCalculationEndSec’,
‘SWOffsetFixValue’, ‘SWFilterClassType’,
‘SWFilterAdHocFrequency’ for a detailed specification
of software offset and filter corrections.
·
New
elements ‘FiringDuration’, ‘FiringVoltageLimit’,
‘FiringCurrentLimit’ for an enhanced exchange of
timer channel parameters.
CalHistoryEntry enhancements:
·
New
flag ‘ReferenceCalibration’ to mark a calibration to
be the master for the deviation verifications.
Attachment
enhancements:
·
New
attribute ‘Type’ to optionally specify whether the attachment is a calibration
sheet, data sheet or image.
SensorAxis
enhancements:
·
New
element ‘EngineeringUnit’ for SensorAxis
and CalHistory elements.
·
New
possible values ‘DiMod’ and ‘Microdau’
for IDModuleType elements.
·
New
elements ‘BridgeResistorPinpPexc’, ‘BridgeResistorPinpNexc’, ‘BridgeResistorNinpPexc’,
‘BridgeResistorNinpNexc’ for SensorAxis
elements.
SensorAxis
enhancements:
·
New
elements ‘LinearityDeviation’ and ‘StandardDeviation’ for SensorAxis
and CalHistory elements.
·
New
elements ‘MaxSensitivityDeviation’, ‘MaxLinearityDeviation’ and ‘MaxStandardDeviation’
to exchange accepted limits.
SensorGroup
enhancements:
·
The
choice for the ‘Category’ has been enhanced by the ‘TestBench’
and the ‘MeasurementDevice’ category.
SensorAxis
enhancements:
·
The
elements ‘ReadoutEnabled’ and ‘ConversionEnabled’
have been added to SensorAxis elements.
·
The
element ‘Attribute’ has been added to CalHistory
elements as well as for SensorAxis elements. See
specific attribute names for analog trigger definition below.
·
The
element ‘ConnectorId’ has been added to SensorAxis elements, enabling to exchange information about
sensor axes connected with the same multi-channel connector.
SensorGroup
enhancements:
·
The
element ‘Attribute’ has been added to SensorGroup and
Sensors elements.
·
The
choice for the ‘Category’ has been enhanced by the ‘TestSetup’
category.
General
changes:
· The element ‘Data format edition’ has
been renamed to ‘DataFormatEdition’ to be consistent
with the naming of other elements
· The Address type is defined as a set
of attributes.
· The elements ‘AttachmentX’
and ‘AttachmentXDescription’ have been replaced by a
new type ‘Attachment’, which may be added unbounded.
· The element ‘Remark’ is moved from the
header section to the base type of all grouping types. So general remarks are
part of the ‘Sensors’ root element, now.
SensorGroup
changes and enhancements:
· Sensor groups may represent
different types like dummies, multi-axis sensors or just nested groups of
dummies or sensors. To separate those cases, an additional element ‘Category’
with an according enumeration has been added, as it is already used in some of
the example files.
SensorAxis
changes and enhancements:
· The element ‘Electrical_Methode’
has been renamed to ‘ElectricalMethod’ to be
consistent with the naming of other elements. The underlying enumeration has
been enhanced, please see [2] for details. An additional element ‘ScalingMethod’ respects non-linear transformations.
· All elements except the ‘Name’ and ‘UUID’
are optional, now. A sensor axis may optionally be used for arbitrary dummy or
car channels, even without a physical sensor behind like airbag timer channels
or constant channels. Additionally, some sensor axes may not know about their
mounting location or orientation.
· The new element ‘Enabled’ allows the
specification of disabled channels / sensor axes.
· The location specification has been
enhanced by a long name and company specific code and long name.
· The new element ‘Technology’ specifies
a certain technology type of sensor, e.g. RES for resistive sensors, PES for
piezo electrical sensors
· The enumeration ‘IdModuleType’
has been reduced to the actually used id modules. A new element ‘TedsType’ marks sensors with TEDS
information.
· The new element ‘Status’ specifies a
sensor status – detailed information to the ‘Usable’ flag.
· The shunt parameters are enhanced by
the new flags ‘ShuntCheckPos’ and ‘ShuntCheckNeg’ specifying whether the shunt measurement is
active or not. The shunt check tolerance is now specified in % of the reference
value instead of mV/V.
· The new element ‘ExcitationVoltage’
specifies the excitation used for this channel which may derive from the
excitation used for the latest calibration (‘SensitivityVoltage’).
In comparison to that, the ‘ExcitationVoltageMin’ and
‘ExcitationVoltageMax’ elements specify the allowed
voltage range given by the sensor manufacturer.
·
The
new element ‘PreferredRange’ holds the CAC (Channel
Amplitude Class) of the channel, which may differ from the already defined maxRange. While the maxRange
specified the range of linearity of the sensor output, the preferred range
controls the ideal amplification. Signals above the preferred range will run
into overdrive while signals much lower than the preferred range will not use
the available resolution of the measurement device.
· The reference to a device channel is
added in the new element ‘DeviceChannelName’. The
content is a unique identification of a device channel according to the device
manufacturer naming convention.
· The calibration elements are enhanced
by the ‘CalPersion’ and the ‘CalRemark’.
To transfer also a calibration history, further entries containing old
calibration data may be added unbounded as ‘CalHistory’
elements. The new element ‘CalVersion’ is an
increasing number usable for calibration entry sorting. Additional calibration
values may be added for non-linear sensors like IRTRACC or cubic polynomial
calibrated displacement sensors (see the description of the ScalingMethod
type enumeration). The ‘CalDate’ type now refers to
the standard schema type ‘date’ to avoid proprietary formatting and provide
format checking by schema.
· Some further optional elements handle
constant channels and timer channels specifications.
· The elements ‘AttachmentX’
and ‘AttachmentXDescription’ have been replaced by a
new type ‘Attachment’, which may be added unbounded.
· The element ‘Direction’ has been
renamed to ‘AxisDirection’, the ‘MountingPolarity’
is specified by an own element. Any inversions due to sensor wiring are
specified by an element ‘ElectricalPolarity’.
· The ‘ConnectorPinX’
elements have been replaced with unbounded ‘ConnectorPin’
definitions, each identified by id which is not necessarily a number in 1-10
anymore.
The data
exchange is done via an XML file with the suffix ‘.e2x’. The XML file follows
the XML schema definition, which contains a detailed description of the current
types and elements (see [2]).
Additional
related files like data sheets, calibration sheets or images can be exchanged
together with the XML structure. Those are referred by the ‘Attachment’
elements in the XML file. The content of the Attachment element specify the path
relative to the current directory of the XML file. Best practice for the
exchange is to place the attached files on a subfolder named similar to the
.e2x file but without the suffix.
A sensor
should be specified as SensorGroup element of
category ‘Multi-Axis Sensor’. Single axis sensors use the same category but add
only one axis.
The
order of Sensor Axis elements within the SensorGroup needs
to be respected carefully. Usually they should be ordered by 1st
Dimension and 2nd Direction.
Sensors
may be specified multiple times in a file, e.g. as a part of a multi axis
sensor and as a part of dummies. Only one specification needs to be complete,
others may just refer to the UUID and name of the sensor. Complete sensor
definitions need at least the specification of the Model and the ElectricalMethod.
The latest
calibration should be added direct to the SensorAxis element.
Older or alternative calibrations may be added as CalHistory
elements with decreasing CalVersion numbers.
Calibration
labs should check new calibrations against the latest calibration of the
history with ReferenceCalibration set to true (if
available) or the calibration information directly at the SensorAxis
as fallback. The tolerance for the sensitivity may be
provided via the MaxSensitivityDeviation element.
Additional verifications are requested, if the elements MaxLinearityDeviation
and MaxStandardDeviation are defined.
Dummys and
other channel groups are SensorGroup elements of
category ‘Dummy’. Each channel is specified as SensorAxis
element. Assigned sensors are referred via the UUID and Name element.
Channels
without sensors should be named similar to their ‘LocationCode’.
‘FiringMode’ and ‘FiringDelay’
should be specified for timer channels only. ‘ConstInValue’
and ‘ConstInReadOnly’ should be specified for
constant channels only (e.g. Pendulum mass).
General
equipment as balances, tilt sensors or data loggers should be specified as SensorGroup element of category ‘Equipment’ with a single SensorAxis sub-element. If assigned to a dummy, these specific
SensorGroup elements may be added to a dummy SensorGroup element.
Test
setups should be exchanged as SensorGroup element of
category ‘TestSetup’. The substructure hold test
objects on first level and seat positions in second level. A nested structure
of other SensorGroup elements reflects the structure
of the test setup.
Each SensorGroup level can hold specific attributes. The ‘Attribute’
keys for ISOMME data should follow the convention of ISOMME, e.g. ‘Customer
test ref. number’. The keys for numerated ISOMME data should follow the convention
of ISOMME without number, e.g. ‘Velocity test object’, ‘Name of test object’
and should be assigned directly to the according test object SensorGroup element one level below the test setup SensorGroup element. Customer specific keys are allowed,
but possibly need registration to the importing system.
The following
additional attribute keys are known yet:
|
Attribute Key |
Value Format |
Unit |
Element |
Description |
|
Pre
trigger time |
xxx.yyyy |
sec |
SensorGroup, Category TestSetup |
The
required pre trigger time for data acquisition |
|
Post trigger
time |
xxx.yyyy |
sec |
SensorGroup, Category TestSetup |
The
required post trigger time for data acquisition |
|
Analog
trigger |
[lt|gt] xxx.yyyy |
Sensor
unit |
SensorAxis |
Defines
an analog trigger on a specified sensor. The trigger is launched if the
sensor value is above (gt) or below (lt) the specified threshold. |
|
BaudRate |
int |
Baud |
SensorAxis |
Baud
rate of a CAN logger channel |
|
BusTermination |
[true|false] |
|
SensorAxis |
True
if the CAN bus of a logger channel should be terminated by the device |
The
example [3] shows a H3 dummy. It contains a SensorGroup
element of category ‘Dummy’ containing Sensor elements referring to the dummy
channels. The sensor axes are just referred by name, as the detailed sensor
axis information is added in the context of the SensorGroup
of type ‘Multi-Axis Sensor’. In a general case, the axes of a multi axis sensor
need not be referred in the same order inside a dummy or some axes may not be
used. But for the sensor import, it is necessary to import the complete axes
specification with the correct order into the database.
The
example [4] shows an export of a sensor query of cubic polynomial sensors. The
calibration sheets of some sensors are attached and exist as file parallel to
the e2x.
Example
[5] shows the export of a small test setup, containing ISO attributes.
[1]
AKEQEX_070207_Wuppertal_Delphi_DArp_Attributliste.xls
Description
of attributes, version 0.9
[2]
EquipmentExchange.xsd
The XML
schema definition
[3]
Dummy
9.zip
An
example for dummy exchange, version 1.0
[4]
Sensors.zip
An
example for a multi axis sensor exchange list, version 1.0
[5]
Tests-1.1.zip
An
example for a test setup exchange list, version 1.1


Represents the progress when downloading a Page and notifies the appropriate listeners.
More...
|
| double | CurrentProgress [get] |
| | The current progress in percent. More...
|
| |
| CancellationTokenSource | CancellationToken [get] |
| | The CancellationTokenSource used to cancel the download. More...
|
| |
| bool | IsSubProgress [get] |
| | Set to true if Page is downloaded as part of an entire Workbook and the download can thus not be cancelled individually. False otherwise. More...
|
| |
Represents the progress when downloading a Page and notifies the appropriate listeners.
◆ MarkAsSubProgress()
| void Lingvo.MobileApp.Services.Progress.PageProgress.MarkAsSubProgress |
( |
| ) |
|
|
inline |
◆ OnReport()
| override void Lingvo.MobileApp.Services.Progress.PageProgress.OnReport |
( |
double |
value | ) |
|
|
inlineprotected |
Notifies the appropriate listeners (as indicated by the ProgressHolder) of download progress.
- Parameters
-
| value | The current download progress, in percent |
◆ Report()
| void Lingvo.MobileApp.Services.Progress.PageProgress.Report |
( |
double |
progress | ) |
|
|
inline |
Informs this instance of its current download progress.
- Parameters
-
| progress | The current download progress, in percent |
◆ CancellationToken
| CancellationTokenSource Lingvo.MobileApp.Services.Progress.PageProgress.CancellationToken |
|
get |
The CancellationTokenSource used to cancel the download.
◆ CurrentProgress
| double Lingvo.MobileApp.Services.Progress.PageProgress.CurrentProgress |
|
get |
The current progress in percent.
◆ IsSubProgress
| bool Lingvo.MobileApp.Services.Progress.PageProgress.IsSubProgress |
|
get |
Set to true
if Page is downloaded as part of an entire Workbook and the download can thus not be cancelled individually. False
otherwise.
◆ Cancelled
| Action<PageProgress> Lingvo.MobileApp.Services.Progress.PageProgress.Cancelled |
Raised when the download is cancelled.
The documentation for this class was generated from the following file:
- src/MobileApp/Services/Progress/PageProgress.cs


Funding estimates
Some text here that explains about estimates - what it means and what it doesn't mean.
| Adult Education Budget | £96,067.55 |
| How is this calculated? | |
| 16-18 Apprenticeships | £9,696.66 |
| How is this calculated? |
| Advanced learner loan facility | £96,067.55 |


A camera stand helps us use longer exposure times for still subjects as they prevent the camera from moving and causing blur.
The normal stand is a tripod, but monopods are useful when we want more flexibility


*BATTERIES NOT INCLUDED A film review by Dan Frank Copyright 1987 Dan Frank
I haven't written many reviews lately, mostly because the movies seem to get to other cities before ours, and because they pretty much summed up what I would say anyway. In the case of *BATTERIES NOT INCLUDED, however, I want to be the first to warn everyone: Stay Away From This Movie.
Siskel and Ebert split on *BATTERIES NOT INCLUDED. Ebert was in a good mood, and recommended it for the special effects and the cute models. Siskel thought it just didn't work.
Hume Cronyn and Jessica Tandy star as a couple living in a tenement building in New York, and running a diner in the commercial space on the first floor. The rest of the neighborhood has been bought up and flattened by a Donald-Trump-style developer who now wants to demolish the one remaining brownstone--theirs--so that he can build a lavish commercial development. To this end, he alternately bribes the residents of the building with envelopes of cash, and threatens them with attacks by the local Hispanic gang, whose leader is basically good but just Never Had a Dad (Big Brothers of America, where are you?).
Cronyn has it tough. Tandy is senile, and believes that Eisenhower is still alive and the Hispanic tough is her long-lost son Bobby. Of course, things are bad all over the building. The sweet pregnant thing upstairs, abandoned by her musician boyfriend, is scared for the health of her baby, so she won't go to a doctor. Her neighbor, the artist, has just been jilted by his girlfriend. The building super is a simple but sweet ex-boxer who spends his days watching TV and trying to repair the tile in the foyer.
This one building contains more Need than any other place in the universe, as a result of which it attracts these mechanical elf things from outer space who want to use the electrical outlets and fix the place up. Do things get better? No! Everything stays rotten, although the appliances now work. All the needy people stay unhappy, hopeless, and forgotten, for the most part. The air of unremitting sadness and gloom never dissipates for a moment.
Don't take your children to see this movie. Don't take your loved ones to see this movie. Send someone you hate; it will make them suicidal.
Do I sound too negative? Then: the machines were really cute. I just loved the little buggers. If you think cute, mute flying robots are worth 90 minutes of pointless pathos, this is a film for you.
-- Dan
P.S. If for some reason you are forced, at gunpoint, to see *BATTERIES NOT INCLUDED, watch for the scene where the developer is fiddling with a model of the development. Look between the two towers for the wee model of the tenement. Very sloppy.
[Moderator's note: There seems to be no consensus on whether the title includes the leading asterisk or not. Since the ads show it as part of the title, I will presume that the makers of the film intended it to be that way and include it here. -ecl]
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


from concurrent.futures import ProcessPoolExecutor, as_completed
from tqdm import tqdm
[docs]def parallel_process(array, function, n_jobs=4, use_kwargs=False, front_num=0):
"""
A parallel version of the map function with a progress bar.
Args:
array (array-like): An array to iterate over.
function (function): A python function to apply to the elements of array
n_jobs (int, default=16): The number of cores to use
use_kwargs (boolean, default=False): Whether to consider the elements of array as dictionaries of
keyword arguments to function
front_num (int, default=3): The number of iterations to run serially before kicking off the parallel job.
Useful for catching bugs
Returns:
list: A list containing the results of each function on each of the arguments
in the array::
[function(array[0]), function(array[1]), ...].
"""
#We run the first few iterations serially to catch bugs
if front_num > 0:
front = [function(**a) if use_kwargs else function(a) for a in array[:front_num]]
else:
front = []
#If we set n_jobs to 1, just run a list comprehension. This is useful for benchmarking and debugging.
if n_jobs==1:
return front + [function(**a) if use_kwargs else function(a) for a in tqdm(array[front_num:])]
#Assemble the workers
with ProcessPoolExecutor(max_workers=n_jobs) as pool:
#Pass the elements of array into function
if use_kwargs:
futures = [pool.submit(function, **a) for a in array[front_num:]]
else:
futures = [pool.submit(function, a) for a in array[front_num:]]
kwargs = {
'total': len(futures),
'unit': 'it',
'unit_scale': True,
'leave': True
}
#Print out the progress as tasks complete
for f in tqdm(as_completed(futures), **kwargs):
pass
out = []
#Get the results from the futures.
for i, future in tqdm(enumerate(futures)):
try:
out.append(future.result())
except Exception as e:
out.append(e)
return front + out


Cong and Margi met at an All-You-Can-Eat hotpot in Boston through Allie. After a quick introduction, Cong proceeded to get his money’s worth of meat. Margi did interact with him by teaching him how to make a crane chopstick holder though. We took a group photo that day. Notice Cong’s awkward hand on Margi’s shoulder.
Before Allie moved to CA, she wanted to go clubbing in NYC. She brought Margi and another friend. That night, Cong and Margi drank and hit it off. Cong was very drunk. Margi was fine. Cong thought Margi was a tank. (Margi actually poured herself ⅕ shots) Cong and Margi started talking soon after :)
At the end of summer, Cong went back to Berkeley to finish his last year in college, while Margi started working in Boston. Still, they couldn't stop talking! When Margi visited Cong for the first time, he took her to the hills near Lawrence Hall of the Science, and asked her out with a letter and a jar of origami cranes. She said yes!
After a year of skyping and flying to each other, Margi moved out to CA as Cong began his new job in Mountain View! Over the next 4 years, they settled into the typical-but-blissful, surburbian South Bay life. They played board games (favorite being Dominion), hung out and travelled with friends, and occasionally celebrated at fancy restaurants.
After some thinking, Cong decided to grow up and embark on the next step of adult life. First, Cong and his friend Boss embarked on this journey of understanding “engagement rings”. Cong learned about the 4 C’s, while Boss booked appointments at very fancy jewelry shops for Cong. After 6 months, Cong finally bought the ring!
Next was the actual proposal. Cong chose to propose at the hills near Lawrence Hall of the Science, just like before! He invited friends, including Margi’s two best friends from college, to show up. The weekend before, they scouted out the location, established optimal location for photos, and finalized details (i.e. which knee to propose on). Cong (secretly) prepared and practiced his speech all week.
Everything went relatively to plan - Cong and Margi had lunch in Berkeley, and headed up to the hills where Margi spotted a table with a letter and flowers. Cong delivered the crappiest version of his speech, but Margi still said yes. Friends came out of hiding to join the couple, and she cried when she saw Susie and Yukun. (Yes, more than when Cong proposed). We celebrated at dinner together with everyone.
Fiancé(e) was a strange term that Cong and Margi soon got used to saying. Wedding planning began and it was more stressful than they imagined. A year after Cong and Margi got engaged, they bought a house and finally moved in together! They were excited for home ownership. But, they're even more elated for their future wedding festivities with their dear friends and family.


Languages
DB/deployment
Web
Design
Other
Developer - [ Parthenon Software ]
Full stack development of web applications, sites, mobile apps, and other web products for clients. Develop and maintain Python applications with Django and Flask. Templating, styling, and JavaScript for responsive applications with modern front-end tooling and libraries. Created mobile apps on the Cordova platform.
Financial Analyst - [ Boeing ]
Analysis of various financial and performance data. I developed forecasts of roughly $100M in annual cost, maintained risks and opportunities to the target, and created reports to identify and explain variances.
Portland Code School
Full-Stack Javascript
Southern Oregon University
Bachelor of Science, Business Administration - Economics
Certificate in Applied Finance and Economics


I am on my way to Insomnia Cookes, and I see some 1. {{words.word1}} 2. {{words.word2}} a 3. {{words.word3}}. These {{words.word1}} were 4. {{words.word4}} very 5. {{words.word5}} for {{words.word1}}.  Turns out that girl was 9. {{words.word9}}!


|
JavaTM 2 Platform Standard Ed. 5.0 |
|||||||||
| PREV LETTER NEXT LETTER | FRAMES NO FRAMES |
int
constant for the enum value ADD_OVERRIDE.
SystemException
was thrown.
SystemException
was thrown.
SystemException
was thrown.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object."
This method is the default implementation of the
org.omg.CORBA.Object
method.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object."
This method is the default implementation of the
org.omg.CORBA.Object
method.
Request
instance initialized with the
given context, method name, list of arguments, and container
for the method's return value.
Request
instance initialized with the
given context, method name, list of arguments, container
for the method's return value, list of possible exceptions,
and list of context strings needing to be resolved.
Request
object that contains the given context,
method, argument list, and container for the result.
Request
object that contains the given context,
method, argument list, container for the result, exceptions, and
list of property names to be used in resolving the context strings.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object."
This method is the default implementation of the
org.omg.CORBA.Object
method.
ObjectImpl
object.
Delegate
object to which this ObjectImpl
object delegates all
methods invoked on it.
PortableServer::Servant
.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object." This method
does not apply to local objects and is therefore not implemented.
DomainManagers
of this object.
ObjectImpl
object.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object." This method
does not apply to local objects and is therefore not implemented.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object."
This method is the default implementation of the
org.omg.CORBA.Object
method.
InterfaceDef
for the object implementation
referenced by this object reference.
ObjectImpl
object.
InterfaceDef
object as a
CORBA::Object
that defines the runtime type of the
CORBA::Object
implemented by the Servant
.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object." This method
does not apply to local objects and is therefore not implemented.
Policy
object of the specified type
which applies to this object.
Policy
object for this
ObjectImpl
object that has the given
policy type.
ObjectImpl
object.
_IDLTypeStub
object.
_IDLTypeStub
object initialized
with the given Delegate
object.
ObjectImpl
object.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object."
This method is the default implementation of the
org.omg.CORBA.Object
method.
InputStream
object for reading the response.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object." This method
does not apply to local objects and is therefore not implemented.
ObjectImpl
object.
repository_id
is present
on the list returned by _all_interfaces()
or is the
repository_id
for the generic CORBA Object.
ObjectImpl
object is
equivalent to this ObjectImpl
object.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object."
This method is the default implementation of the
org.omg.CORBA.Object
method.
ObjectImpl
object is implemented
by a local servant.
NamingContextExt
is the extension of NamingContext
which
contains a set of name bindings in which each name is unique and is
part of Interoperable Naming Service.false
.
ObjectImpl
object has been destroyed.
Object
.
PortableServer::Current::get_object_id
.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object."
This method is the default implementation of the
org.omg.CORBA.Object
method.
Servant
(convenience method).
PortableServer::Current:get_POA
.
_PolicyStub
object initialized
with the given Delegate
object.
postEdit
and endUpdate
.
input
and initalizes the value in the Holder
with the unmarshalled data.
input
and assigns it to this
BooleanHolder
object's value
field.
input
and initalizes the value in
this ByteHolder
object
with the unmarshalled data.
input
and initalizes the value in
this CharHolder
object
with the unmarshalled data.
input
and assigns it to
the value
field in this IntHolder
object.
input
and initalizes the value in the Holder
with the unmarshalled data.
input
and initalizes the value in
this ObjectHolder
object
with the unmarshalled data.
istream
and initalizes the
value
field of the Holder with the unmarshalled data.
in
and assigns it to
the value
field in this ServiceInformationHolder
object.
input
and initalizes the value in
this ShortHolder
object
with the unmarshalled data.
input
and assigns it to
the value
field of this StringHolder
object.
input
and initalizes the value in
this TypeCodeHolder
object
with the unmarshalled data.
input
and initalizes the value in the Holder
with the unmarshalled data.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object."
This method is the default implementation of the
org.omg.CORBA.Object
method.
ObjectImpl
object.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object."
This method is the default implementation of the
org.omg.CORBA.Object
method.
_invoke
.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object."
This method is the default implementation of the
org.omg.CORBA.Object
method.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object."
This method is the default implementation of the
org.omg.CORBA.Object
method.
Request
instance for use in the
Dynamic Invocation Interface.
Request
object containing the given method
that can be used with the Dynamic Invocation Interface.
OutputStream
object to use for marshalling
the arguments of the given method.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object."
This method is the default implementation of the
org.omg.CORBA.Object
method.
_servant_preinvoke
.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object."
This method is the default implementation of the
org.omg.CORBA.Object
method.
ObjectImpl
instance to the given
Delegate
object.
int
constant for the enum value SET_OVERRIDE.
org.omg.CORBA.NO_IMPLEMENT
exception with
the message "This is a locally constrained object." This method
does not apply to local objects and is therefore not implemented.
Object
with the given policies
either replacing any existing policies in this
Object
or with the given policies added
to the existing ones, depending on the value of the
given SetOverrideType
object.

TypeCode
object corresponding to the value
held in this AnyHolder
object.
TypeCode
object that corresponds to the
value held in this BooleanHolder
object.
ByteHolder
object.
TypeCode
object corresponding
to the value held in
this CharHolder
object.
TypeCode
of this holder object.
TypeCode
of this holder object.
TypeCode
of this Streamable.
TypeCode
object that corresponds
to the value held in this IntHolder
object's
value
field.
TypeCode
object
corresponding to the value held in the Holder.
ObjectHolder
object
TypeCode
object corresponding to the value
in the value
field of the Holder.
TypeCode
object that corresponds
to the value held in this ServiceInformationHolder
object's
value
field.
ShortHolder
object.
TypeCode
object that corresponds to
the value held in this StringHolder
object.
TypeCodeHolder
object.
TypeCode
object
corresponding to the value held in the Holder.
output
the value in
this AnyHolder
object.
BooleanHolder
object's
value
field to the output stream output
.
output
the value in
this ByteHolder
object.
output
the value in
this CharHolder
object.
OutputStream
.
OutputStream
.
IntHolder
object's
value
field to the output stream output
.
output
the value in the Holder.
output
the value in
this ObjectHolder
object.
ostream
the value in the
value
field of the Holder.
ServiceInformationHolder
object's
value
field to the output stream out
.
output
the value in
this ShortHolder
object.
StringHolder
object
to the output stream output
.
output
the value in
this TypeCodeHolder
object.
output
the value in the Holder.
|
JavaTM 2 Platform Standard Ed. 5.0 |
|||||||||
| PREV LETTER NEXT LETTER | FRAMES NO FRAMES |
Copyright © 2004, 2010 Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. Also see the documentation redistribution policy.


Receive more information about our shops and stores. If you’d like to book a room for Cielito Lindo, click here.
At Timeless Antiaging Spa you will find health and beauty treatments to treat your skin, body, and overall well-being. Our environment is especially designed for you to have a peaceful and memorable experience. We’re committed to providing the best spa treatments in Los Algodones, our trained masseuses and cosmeticians will help you relax your mind and body.
Combining traditional methods with modern beauty techniques, Timeless is the most extensive spa in Los Algodones. Treat yourself to a relaxing day and visit us at MediPlaza Los Algodones. If you were looking for beauty, health, comfort, and wellness, you’ve found it; only at Timeless Antiaging Spa.


After every semester, we have an exhibition of sorts by various departments showcasing the excellent work they did during the course. Following is a rather utilitarian compilation of pictures of these exhibitions.
PS: All rights are reserved to the respected content creators.
Product Design Photo Courtesy- ASV Arun Balaji
Interaction Design
Communication Design
Mobility and Vehicle Design
This is a small collection. I will probably update it as and when i get more :)
Cheers,
Rohit


Preparation time
less than 30 mins
Cooking time
30 mins to 1 hour
Serves
Serves 3
Dietary
The rhubarb tart on its own is quite sharp, so the sweetened mascarpone cream helps to balance the dessert. This cream works wonders with any soft fruit.
For the roasted rhubarb, preheat the oven to 200C/400F/Gas 6. Cut the rhubarb into 15cm/6in or so lengths (about the length of a wooden spoon-handle) and place in a roasting tin with half a tea-cup of water and the light brown sugar. Roast until just soft enough to take the point of a knife, about 10-15 minutes. Allow to cool, then drain, reserving the cooking juices.
For the tart, preheat the oven to 220C/425F/Gas 7. Unroll the puff pastry, and using a rolling pin, roll it again to make the pastry slightly thinner. Cut the pastry into three even-sized rectangles. Using a sharp knife, score a 1.5cm/½in border around each rectangle, being careful not to cut through the pastry. Place the pastry rectangles on a lightly greased baking sheet.
Arrange 3-4 lengths of drained rhubarb, depending on the thickness of them, into the middle of the pastry rectangles and brush some of the reserved juice from the roasted rhubarb around the edges to give the pastry a shine. Bake for 20 minutes, until golden and risen.
Meanwhile beat the egg yolks and sugar in a bowl for a few seconds, until thoroughly mixed. Beat in the mascarpone until you have a custard-coloured cream. Stir in a little vanilla extract; a couple of drops should be enough. With a clean whisk, beat the egg white in a clean bowl until it stands in stiff peaks, then fold into the creamed mascarpone mixture.
Serve the mascarpone cream with the warm rhubarb tarts. Any remaining mascarpone cream can be served the following day with berries or used to top meringues served with fruit.


Environtment in Guinea
Enter the link to be shortened in the long field:
Enter any text "a-z" that you want your link to be shortened to:
{% if shortURL %} Here's your new short URL:
{{ shortURL }}
{% endif %}
Brought to you by:


Some people may think that aerial arts are daunting and difficult to begin doing. While it may seem that way, the only way to get better is by practicing. The strength comes with continued training! Some of the notable aerial schools in Portland, OR are Night Flight Aerial, A-WOL Dance, and The Circus Project.
Circus arts have a wide variety of disciplines, and aerial is no different. You can choose to train on whatever apparatus suits your own aesthetic or comfort, to a certain extent.
While some aspects of aerial may seem fun and easy, and they might look super cool, safety is always the top priority.


nrg-energy
Businessmodel of NRG Energy
Customer Segments
NRG serves a broad range of customers, across multiple segments and sectors. NRG’s retail business provides home energy and related services as well as personal power to consumers to approximately 2.77 million recurring customers, and around 624,000 discrete customers of products and services, including:
- Residential customers, including family households, and individual apartments and apartment buildings;
- Commercial customers, including a range of businesses of varying sizes;
- Industrial customers, including various industrial companies, such as manufacturers and engineering companies. NRG also provides a full range of renewable solar energy solutions to utilities providers, schools, municipalities, and businesses, and operates thermal infrastructure assets that provide steam, hot water, and in some instances electricity, to commercial businesses, universities, hospitals and government bodies. Among NRG’s customers are high-profile companies such as Kaiser Permanente, Unilever, and Cisco.
NRG does not have a broad international customer base. It is based in the US, and serves customers across its domestic market.
Value Propositions
NRG provides value to its customers in the following ways:
- The quality and reliability of its products and services, with the Company established as a reliable provider of energy solutions, utilising an efficient generation and distribution infrastructure system;
- Its commitment to delivering innovative and sustainable solutions, with the Company involved in ongoing research and development with a view to providing state-of-the-art sustainable services to customers;
- Its broad range of customers, with the Company providing services to suit general consumers, commercial entities, public and government bodies, and industrial businesses; and
- The technical expertise of its personnel, with the Company employing a team of highly-trained, specialist staff across its operating segments, led by experienced industry executives. ### Channels
NRG operates a website at www.nrg.com, through which the Company provides information on its products, services, and energy assets. While the Company details its various services, it does not operate an online sales channel.
NRG operates an in-house direct sales force, through which it makes its energy sales under various brand names, including NRG Reliant. Customers are served through a variety of sales channels, including direct sales representatives, call centres, brokers and brick-and-mortar stores, as well as the Company’s domestic network of offices. Business-to-business sales are conducted by specialist teams, organised by operating segment and unit.
NRG delivers power and utilities through its own generation, distribution, and transmission infrastructure. It owns and operates approximately 50,000 MW of generation, including one of the largest and most diversified power generation portfolios in the US, with assets are diversified by fuel-type, dispatch level and region. The Company has generation assets in or near Houston, New York, Chicago, Washington DC, New Jersey, southwestern Connecticut, Pittsburgh, Cleveland, Los Angeles, San Diego, and San Francisco.
Customer Relationships
NRG does not provide any products or services to its customers on a self-service basis. The Company, instead, consults directly with its customers – both businesses and consumers – with a view to establishing each client’s individual needs. The Company provides the majority of its services to through long-term sales contracts, which are often pursuant to rates regulated by state utility commissions, with a view to establishing longstanding relationships and recurring business.
NRG provides ongoing support to and works closely with its customers throughout the provision of its products and services. The Company operates customer service teams across its various business units, which can be contacted by customers over the phone for a personalised response to queries and concerns.
The NRG website includes a news page, where the Company publishes press releases and provides market reports, keeping its customers updated on the Company’s operations. The Company also operates Facebook, Twitter, LinkedIn, and Google+ accounts, through which it is able to interact directly with its customers.
Key Activities
NRG is a US-based integrated power company. It is engaged in the production, sale, and delivery of energy, and energy products and services across domestic power markets.
The Company’s activities are divided into several business segments: NRG Business, which includes the Company’s power generation, carbon capture and energy services offerings; NRG Home, which includes the Company’s residential retail services and products, and the installation and leasing of residential solar solutions; NRG Renew, which is concerned with the operation of solar and wind assets; and NRG Yield, which includes certain of the Company’s contracted generation assets.
NRG is also involved in certain corporate activities, largely through its subsidiary Boston Energy Trading and Marketing. NRG owns and operates one of the largest energy networks in the US, with around 50,000 megawatts of generation capacity.
Key Partners
NRG collaborates with a range of companies and organisations, throughout the generation, sale, and distribution of its energy products and services. The Company’s solar business, in particular, targets strategic partnerships with local, regional, national and multi-national companies and institutions to provide on-site and off-site renewable power generation. NRG’s other partners include:
- Power Generation and Joint Venture Partners, comprising a range of energy and energy service companies and municipal and local government bodies, with which it collaborates on joint-venture projects through mutually-owned vehicles;
- Sales and Marketing Partners, comprising a range of channel partners that help to extend the Company’s own sales and marketing reach;
- Supplier and Vendor Partners, comprising vendors and suppliers of services, equipment, and resources that support and supplement the Company’s operations, as well as various companies to which non-core functions are outsourced; and
- Strategic and Alliance Partners, comprising a range of companies and organisations, with which the Company shares resources and collaborates on joint projects. In 2014 NRG became the exclusive electric energy partner of Comcast in Pennsylvania. The Company has also recently agreed a deal with the NBA’s Miami Heat franchise as part of a clean energy partnership, and has collaborated with the University of Louisiana at Lafayette to develop solar energy solutions.
Key Resources
NRG’s key resources are its various permits and licences, its physical energy generation and distribution assets, its technologies, its partnerships, its sales and marketing channels – including its physical network of outlets, and its personnel.
The Company’s physical infrastructure and assets are key to its activities. The Company owns and operates power production and cogeneration facilities across the US, organised into three regions: Gulf Coast Region, East Region, and West Region.
Cost Structure
NRG incurs costs in relation to its research and development activities, the operation and maintenance of its energy generation and distribution assets, the management of its partnerships, the operation of its sales and marketing channels – including physical outlets, and the retention of its personnel.
In 2015, NRG accrued sales costs in the amount of $7.84 billion, its largest expense. The Company also recorded annual operation and maintenance costs totalling $2.31 billion, and selling, general and administrative expenses amounting to $1.22 billion. Included within these expenses are the payment of salaries and benefits to the Company’s 10,468 employees.
Revenue Streams
NRG generates revenue through the provision of energy and energy services to a range of customers, including consumers, commercial entities, industrial operators, and government bodies. This principally includes:
- Energy Revenue, derived from the sale to third-parties of electricity in the day-ahead and real-time markets, as well as bilateral sales;
- Capacity Revenue, derived through rom market clearing resource adequacy contracts, tolling arrangements, power purchase agreements, and other long-term contractual arrangements;
- Retail Revenue, derived from retail sales to residential, small business, commercial, industrial and governmental/institutional customers; and
- Market-to-Market Revenue, derived from the Company’s economic hedging activities. In 2014 NRG generated $14.67 billion in annual operating revenue, down on the $15.87 billion recorded by the Company in 2014. More than 90% of the Company’s revenue was attributed to the Company’s energy revenue and retail revenue, which generated $6.59 billion and $6.92 billion in 2015 respectively.


# -*- coding: utf-8 -*-
# Soohwan Kim, Seyoung Bae, Cheolhwang Won.
# @ArXiv : KoSpeech: Open-Source Toolkit for End-to-End Korean Speech Recognition
# This source code is licensed under the Apache 2.0 License license found in the
# LICENSE file in the root directory of this source tree.
import math
import torch
import torch.nn as nn
import torch.nn.functional as F
from torch import Tensor
from typing import Tuple
from kospeech.models.extractor import DeepSpeech2Extractor
from kospeech.models.modules import Linear, BNReluRNN
[docs]class DeepSpeech2(nn.Module):
"""
Deep Speech2 architecture with configurable encoder and decoder.
Paper: https://arxiv.org/abs/1512.02595
Args:
input_size (int): size of input
num_classes (int): number of classfication
rnn_type (str, optional): type of RNN cell (default: gru)
num_rnn_layers (int, optional): number of recurrent layers (default: 5)
rnn_hidden_dim (int): the number of features in the hidden state `h`
dropout_p (float, optional): dropout probability (default: 0.1)
bidirectional (bool, optional): if True, becomes a bidirectional encoder (defulat: True)
activation (str): type of activation function (default: hardtanh)
device (torch.device): device - 'cuda' or 'cpu'
Inputs: inputs, input_lengths
- **inputs**: list of sequences, whose length is the batch size and within which each sequence is list of tokens
- **input_lengths**: list of sequence lengths
Returns: output
- **output**: tensor containing the encoded features of the input sequence
"""
def __init__(
self,
input_size: int, # size of input
num_classes: int, # number of classfication
rnn_type='gru', # type of RNN cell
num_rnn_layers: int = 5, # number of RNN layers
rnn_hidden_dim: int = 512, # dimension of RNN`s hidden state
dropout_p: float = 0.1, # dropout probability
bidirectional: bool = True, # if True, becomes a bidirectional rnn
activation: str = 'hardtanh', # type of activation function
device: str = 'cuda' # device - 'cuda' or 'cpu'
):
super(DeepSpeech2, self).__init__()
self.rnn_layers = list()
self.device = device
input_size = int(math.floor(input_size + 2 * 20 - 41) / 2 + 1)
input_size = int(math.floor(input_size + 2 * 10 - 21) / 2 + 1)
input_size <<= 5
rnn_output_size = rnn_hidden_dim << 1 if bidirectional else rnn_hidden_dim
self.conv = DeepSpeech2Extractor(activation, mask_conv=True)
for idx in range(num_rnn_layers):
self.rnn_layers.append(BNReluRNN(
input_size=input_size if idx == 0 else rnn_output_size,
hidden_dim=rnn_hidden_dim,
rnn_type=rnn_type,
bidirectional=bidirectional,
dropout_p=dropout_p,
device=device
))
self.fc = nn.Sequential(
Linear(rnn_output_size, rnn_hidden_dim),
nn.ReLU(),
Linear(rnn_hidden_dim, num_classes, bias=False)
)
[docs] def forward(self, inputs: Tensor, input_lengths: Tensor) -> Tuple[Tensor, Tensor]:
inputs = inputs.unsqueeze(1).permute(0, 1, 3, 2)
output, output_lengths = self.conv(inputs, input_lengths)
batch_size, num_channels, hidden_dim, seq_length = output.size()
output = output.view(batch_size, num_channels * hidden_dim, seq_length).permute(2, 0, 1).contiguous()
for rnn_layer in self.rnn_layers:
rnn_layer.to(self.device)
output = rnn_layer(output, output_lengths)
output = output.transpose(0, 1)
output = self.fc(output)
output = F.log_softmax(output, dim=-1)
return output, output_lengths
def greedy_decode(self, inputs: Tensor, input_lengths: Tensor, device: str):
with torch.no_grad():
output = self.forward(inputs, input_lengths)
logit = torch.stack(output, dim=1).to(device)
return logit.max(-1)[1]


Attendance System
Home
Take Attendance
Take Attendance
Update Attendance
Details
Your Subjects
Staff Details
Students Details
All Subjects Details
Your Subject Reports
Up-to-Date Report
Date-Wise Report
Daily Report
Subject Wise Report
Up-to-Date Report
Date-Wise Report
Daily Report
Class Wise Report
Up-to-Date Report
Date-Wise Report
Daily Report
{{type}}: {{email}}
Logout
Update Attendance's details here
Date
Subject
{{subj.sub_branch}}-({{subj.shift}})-{{subj.sub_name}}({{subj.sub_code}})
Head
Theory
Practical
Time Slot
07:30-08:30
08:30-09:30
10:00-11:00
11:00-12:00
12:10-01:10
01:10-02:10
07:30-09:30
10:00-12:00
12:10-02:10
12:10-01:10
01:10-02:10
02:20-03:20
03:20-04:20
04:30-05:30
05:30-06:30
12:10-02:10
02:20-04:20
04:30-06:30
Proceed
Take Attendance
Check all Present
Check all Absent
No Students Found
R.n
Names
Status
{{ staff.roll}})
{{ staff.fname}} {{staff.mname}} {{staff.lname}}
ADD ATTENDANCE
BACK
{{msg}}


My Portfolio
Toggle navigation
Projects
About Me
Contact
Gerald Roberts
Projects
Tribute Page
Check out the Source
Portfolio Page
Check out the Source
About Me
My name is Gerald Roberts
Contact Information
Check me out on
Github
or on
Linkedin
.


Register
We are honoured to have you on our team.
Welcome aboard!
First Name
Last Name
Email
Password
Confirm Password
Date of Birth
Male
Female
Other
Register
done


Class nowjs
Defined in: now.js.
| Constructor Attributes | Constructor Name and Description |
|---|---|
|
nowjs()
The object returned by require('now').
|
| Method Attributes | Method Name and Description |
|---|---|
|
getClient(id, callback)
Retrieves a user from the given client ID and executes
of several actions in the context of that user.
|
|
|
getGroup(name)
Retrieves and returns a group from its name, creating it if
necessary.
|
|
| <static> |
nowjs.initialize(server, options)
Returns a reference to the `everyone` object.
|
| Event Attributes | Event Name and Description |
|---|---|
|
connect()
Called in the context of a user when the server first
receives a message from the given user.
|
|
|
Called in the context of a user who has just
disconnected from the server.
|
|
|
groupdel(group)
Called when deleting a variable from all members of
the group specified by this function's argument.
|
|
|
grouprv(group)
Called when replacing the value of a variable for all
members of the group specified by this function's argument.
|
|
|
newgroup(group)
Called when a new group is created.
|
Method Detail
getClient(id, callback)
Retrieves a user from the given client ID and executes
of several actions in the context of that user.
nowjs.getClient('1234567890' function () { this.now.receiveMessage('SERVER', 'Anything is possible with NowJS.'); });
- Parameters:
- {String} id
- The client ID associated with the target user.
- {Function} callback
- Takes no arguments. Called in the context of the user corresponding to the given id.
{Group}
getGroup(name)
Retrieves and returns a group from its name, creating it if
necessary.
var new_group = nowjs.getGroup('a new group');
- Parameters:
- {String} name
- The name of the group to be retrieved.
<static>
{Group}
nowjs.initialize(server, options)
Returns a reference to the `everyone` object. The
options object, if supplied, will be automatically merged with the
default values.
nowjs.initialize(server, {clientWrite: false, socketio: {'log level': 2});
- Parameters:
- {httpServer} server
- A Node.js http server (such as the one available in the http module or a module like Express) on which to run Now.
- {Object} options Optional, Default: {"clientWrite" : true, "autoHost" : true, "host" : undefined, "port" : undefined, "socketio" : {}, "closureTimeout : 30000, "client : {}, "scope" : "window"}
Event Detail
connect()
Called in the context of a user when the server first
receives a message from the given user.
nowjs.on('connect', function () { this.now.receiveMessage('SERVER', 'Welcome to NowJS.'); });
disconnect()
Called in the context of a user who has just
disconnected from the server.
nowjs.on('disconnect, function () { delete myArray[this.user.clientId]; });
groupdel(group)
Called when deleting a variable from all members of
the group specified by this function's argument.
nowjs.on('groupdel', function (group) { if (group.groupName === 'everyone') { console.log('Everyone now no longer possesses ' + group.fqn); } });
- Parameters:
- {Group} group
- Actually not quite a group; this parameter refers to a clone of the group in question that also carries the fully qualified name (fqn) of the variable to delete. Access the fqn via `group.fqn`.
grouprv(group)
Called when replacing the value of a variable for all
members of the group specified by this function's argument.
nowjs.on('grouprv', function (group) { if (group.groupName === 'everyone') { console.log('Everyone now sees ' + group.fqn + ' as ' + group.val); } });
- Parameters:
- {Group} group
- Similar to nowjs#groupdel, this is also a clone of the actual group. In addition to the fully qualified name, this clone also possesses a serialized form of its target value, accessible via `group.val`.
newgroup(group)
Called when a new group is created.
nowjs.on('newgroup', function (name) { console.log('You have successfully created the group `' + name + '`'); });
- Parameters:
- {Group} group
- The group created by nowjs#getGroup.


To align a learning resource to a competency:
1. Select a resource using one of the provided tools under the '...' at the right.
No Selected Resource
2. Next, select an alignment and location to store the alignment from the below box.
3. Select the competency you wish to align the resource to.
No Selected Competency
4. Click 'Create Alignment' and follow the provided instructions.


THE LAW OF ENCLOSURES (2000) / *** 1/2
Directed by John Greyson. Screenplay by Greyson, based on the novel by Dale Peck. Starring Sarah Polley, Brendan Fletcher, Diane Ladd. Running time: 111 minutes. Rated AA for mature subject matter by the MFCB. Reviewed on September 14th, 2001.
By SHANNON PATRICK SULLIVAN
Synopsis: Sarnia, Ontario, 1991. Beatrice (Polley) and Henry (Fletcher) are a young couple newly fallen in love. Sarnia, Ontario, 1991. Bea (Ladd) and Hank (Sean McCann) are an older married couple, bitter and cold and full of loathing for each other. As the Gulf War rages in the background, we explore how Beatrice and Henry become Bea and Hank; and we witness the final effort of Bea and Hank to recover their beginnings as Beatrice and Henry.
Review: Initially slow and ponderous, "The Law Of Enclosures" gradually, almost imperceptibly, draws you in. Its structure is unusual, the characters comprising two groups of people living contemporaneously. One set is young and the other older, but apparently, impossibly, they are the same. The youthful group includes Beatrice, Henry, Myrah and Stanley; the elder consists of Bea, Hank, Myra and Stan. There's even a child Beatrice/Bea in a few scenes, also existing simultaneously. The point of this seemingly convoluted and heavily metaphorical set-up is to paint a cinematic palindrome: the dawn of Beatrice and Henry's relationship is mirrored by its twilight. Greyson includes several hints as to the nature of the movie; clocks get stuck, and numbers counted backward are a perennial feature. Also watch for reflected actions, particularly beautiful shots of lovemaking through a glazed window. The backdrop of the War, oil-rich Sarnia posing as a Western Kuwait and the relationship(s) as the arena of destruction, is effective but not overdone. Polley and Fletcher don't quite find the right note as Beatrice and Henry; they go through the motions of being in love, but it never quite feels genuine. Ladd and McCann, though, are spectacular, at first communicating a controlled animosity which beautifully transforms into something more.
Copyright © 2001 Shannon Patrick Sullivan. Archived at The Popcorn Gallery, http://www.physics.mun.ca/~sps/movies.html
| Shannon Patrick Sullivan |<EMAIL_ADDRESS>| +---------------------------------+---------------------------------+ / Doctor Who: A Brief History of Time (Travel) go.to/drwho-history \ \__ We are all in the gutter but some of us are looking at the stars __/
========== X-RAMR-ID: 29470 X-Language: en X-RT-SourceID: 886 X-RT-AuthorID: 1699 X-RT-RatingText: 3.5/4
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


Stony Brook University
Center of Excellence in Wireless & Information Technology
In today's world, data and technology are becoming a huge part of our lives. To learn how to keep our own websites, data, and personal information safe, we have to learn how malicious hackers break it. That’s what BytesCTF is here to do! BytesCTF is Stony Brook Computing Society’s first Capture The Flag event. Spend 12 hours completing various cybersecurity challenges to find secret flags, and compete to catch em’ all. Our topics include binary exploitation, website investigation, cryptography and much more. Have questions? Feel free to visit our website, bytesctf.org or email<EMAIL_ADDRESS>Take the first steps into Cyber Security and touch on aspects of security like: cryptography, steganography, binary analysis, reverse engineering, mobile security and others.
Large companies and inspiring startups looking for talented students like you
Create bonds and have unforgettable memories with friends from all over
Interested in sponsoring? Email us at<EMAIL_ADDRESS>!
Not at all! We will be having a boot camp the weeks before BytesCTF to introduce you to everything you need to know. PS: We will also have some difficult flags for our more experienced hackers.
BytesCTF is completely free! We will supply you with all the food + caffeine you need to succeed. Sadly, we do not offer travel reimbursement due to this being the events first year.
Bring yourself, a photo ID, your signed waiver (if applicable), a change of clothes, toiletries, a sleeping bag/blanket (if you’re sleeping of course), your hacker setup (laptop, charger, headphones), and a passion to compete!
The maximum team size is 2; you can work with one other person or alone. It’s completely okay to make your team beforehand, either in person or over our BytesCTF Slack. Another option is joining us for our Team Building activity and meet your partner right then and there! The times and location for that activity is on the Schedule.
Throughout the CTF, we will be using Slack as the main form of communication. Never used Slack before? Here's a quick introduction!
We will have a separate room for sleeping, so that everyone who wants to rest can do so in peace and quiet. However, please bring your own sleeping bags and whatever blankets you may need. The specific rooms and maps will be released closer to BytesCTF!


Blot turns a folder into a blog. You can use any of the following tools and services to sync your folder to Blot:
{{> client_list}}Is there another tool or service you'd like us to support? Please contact us with your suggestions.
You can switch your site's folder from one client to another at any point. For example, if you want to use Git instead of Dropbox, Blot will seamlessly transition your folder's contents from one to the other, and you can pick up in Git where you left off in Dropbox.
You can manage multiple blogs from the same account. Each blog is independent: you could use Dropbox with one and Git with another. If you have multiple blogs, they can all use the same Dropbox account, or different accounts.