Difference between revisions of "User:Oz Linden/Tools"

From Second Life Wiki
Jump to navigation Jump to search
m (Text replacement - "hg.secondlife.com" to "bitbucket.org/lindenlab")
 
(18 intermediate revisions by the same user not shown)
Line 25: Line 25:


For an example of the output of the current version resulting from the above, see my [[Open Development User Group/Archive/2011-02-09|user group archive for 9 Feb]]
For an example of the output of the current version resulting from the above, see my [[Open Development User Group/Archive/2011-02-09|user group archive for 9 Feb]]
:''I have an LSL script that can be used to record the timestamps and email the owner a chat-extract command line, but it is not quite polished enough for me to post here; ask if you are interested.''


=== chat-extract ===
=== chat-extract ===
Line 77: Line 79:


  bots = ''bot-names-file''
  bots = ''bot-names-file''
== Jira Issue Finder ==
Feed any stream of input to this script and it will extract the Jira issue keys from the stream and format them as a list.  Issues that have been moved will be listed using the most current key:
'''Usage:'''
findjiras [options]
===Formatting options===
These options control the output format, and are mutually exclusive.  With none of these specified, only the issue numbers are printed, separated by newline.
;-s ''separator'', --separator ''separator'':separate the results with this string (such as ", ")
To format a list including the summary line from the issue, use one of:
;-t, --text:format as plain text
;-m, --html:format as an html descriptive list
;-w, --wiki:format as a wiki descriptive list
===Filtering options===
:These options filter the issues by project name; the default without these options is to find all valid Jira ids.  Each may be specified more than once to specify multiple projects.  Note that for issues that have been moved, this applies to the final issue id.
;-p ''included-project'', --project ''included-project'':find issues only for the project named
;-x ''excluded-project'', --exclude ''excluded-project'':specific projects not to include
===Other options===
;-h, --help:show this help message and exit
;-c, --count:print a summary of counts of the different jira types after the list
;-u ''USERNAME'', --user ''USERNAME'': specify the user account in Jira (defaults to the FINDJIRAS_USER environment variable).  If not specified, the script will prompt you for it.
===Examples===
To find all issues since a the <tt>release-2-1</tt> tag, and display in wiki form:
hg log --follow --prune release-2-1 -rtip:0 --template '{desc}\n' | findjiras -w
To list just the issue ids for all issues in your local repository that are not in the canonical <tt>viewer-release</tt> repository:
hg out --template '{desc}\n' https://bitbucket.org/lindenlab/viewer-release | findjiras


== Python Help Message Wiki Formatter ==
== Python Help Message Wiki Formatter ==
Line 105: Line 147:
<nowiki>version of it to standard output.</nowiki>
<nowiki>version of it to standard output.</nowiki>


== Integration Tools ==
== Mercurial Tools ==
 
These tools are used to manage collections of related repositories, and to pull changes from one to another in a uniform way.


=== Repository Collection Updater ===
=== Repository Collection Updater ===


Usage:
mm-updates [<verbosity-option>] [-n|--dry-run] [-c|--config <configuration>] [  <repository> ... ]
   
    mm-updates [ <configuration> ]


Updates and checks local repositories based on a configuration file.  It is useful in maintaining a set of local mirrors of remote repositories.
Checks and updates local repositories based on a configuration file.  It is useful in maintaining a set of local mirrors of remote repositories, and displaying the relationships between them.


If the configuration file name is not specified on the command line:
If the configuration file name is not specified on the command line:
* The environment variable MM_UPDATES_CONFIG is checked
# The environment variable MM_UPDATES_CONFIG is checked
* If that is not set, then the default file is $HOME/.mm_updates_config
# If that is not set, then the default file is <tt>$\{HOME\}/.mm_updates_config</tt>
   
 
Each line of the configuration file contains either 2 or 3 repositories:
Each line of the configuration file contains 2 or more repositories:


  <local-path> <parent-repo> [ <downstream-repo> ]
  local-path remote-repo downstream-repo...


;local-path  
;local-path  
:Specifies the full path to a local hg repository. This is the only repository that is ever modified by this command.
:Specifies a local hg repository (may be an hg alias, but that alias must resolve to a full local path name). This is the only repository that is ever modified by this command.
;parent-repo
 
:Is either a remote repository URL or a local repository path. Any changesets from the parent not found in the local repo are pulled to it; if this would require a merge, the mm-updates command fails with an error.
;remote-repo
:Is either a remote repository URL or a local repository path. Any changesets from the remote not found in the local repo are pulled to it; if this would require a merge, the mm-updates command fails with an error.
 
;downstream-repo
;downstream-repo
:Is either a remote repository URL or a local repository path. If specified, this command checks to see if the local repo contains any changesets not in the downstream repo and displays the number found.
:Is a list of zero or more repositories: each may be a remote repository URL or a local repository path.
 
:If specified, each repository is checked to see if the local repo contains any changesets not in the downstream repo and displays the number found.
Note that the ~/.hgrc file may be used to define path aliases for the parent or downstream repositories, but that the local must be a directory path.


Blank lines are allowed in the configuration file, and the '#' character starts comments, which are ignored.
Blank lines are allowed in the configuration file, and the '#' character starts comments, which are ignored.
      
      
BUG: paths must be fully specified - specifically the usual '~' for $HOME does not work
If repositories are specified on the command line, then only those are updated and checked.
 
The verbosity options are: -d|--debug  -v|--verbose  -q|--quiet
 
The -n|--dry-run option causes the command to display what would have been fetched, but the local repository is not actually modified.
 
If a repository specified on the command line is not found in the configuration file, then remote-repo is assumed to be its 'default' repository, and downstream-repo is assumed to be its 'default-push' repository (if any).


Example Configuration file:
Example Configuration file:


#      local-repo                   parent-repo                                  downstream-repo
#      local-repo                 parent-repo                                  downstream-repo
/Users/oz/Work/viewer-release       http://hg.secondlife.com/viewer-release
/Users/oz/Work/viewer-release     ssh://bitbucket.org/lindenlab/viewer-release
/Users/oz/Work/viewer-beta         http://hg.secondlife.com/viewer-beta         /Users/oz/Work/viewer-release
/Users/oz/Work/viewer-beta         ssh://bitbucket.org/lindenlab/viewer-beta       /Users/oz/Work/viewer-release
/Users/oz/Work/viewer-betaR        /Users/oz/Work/viewer-beta-review
/Users/oz/Work/viewer-betareview  /Users/oz/Work/viewer-beta
/Users/oz/Work/viewer-development  ssh://bitbucket.org/lindenlab/viewer-development /Users/oz/Work/viewer-beta
/Users/oz/Work/viewer-devreview    /Users/oz/Work/viewer-development


/Users/oz/Work/viewer-development  http://hg.secondlife.com/viewer-development  /Users/oz/Work/viewer-beta-review
/Users/oz/Work/viewer-dev-review    /Users/oz/Work/viewer-dev-review


=== Change Merge ===
==== Merge ====


This is a wrapper for the mercurial ''hg fetch'' command that helps with constructing merge changeset comments based on the pattern of naming repositories using the jira issue key as the last element of the repository path.
This is a wrapper that properly merges a set of changes from another repository.


Usage:
Usage:
Line 164: Line 209:
Entering return for either prompt accepts default and proceeds.  After comment prompt, an 'hg fetch' command is executed. It is safe to abort the command at either prompt.
Entering return for either prompt accepts default and proceeds.  After comment prompt, an 'hg fetch' command is executed. It is safe to abort the command at either prompt.


=== License Header Splicing ===
====Release Candidate Checks====
 
Usage:
  rc-check [<verbosity-option>] [{-t|--trunk} <trunk-repository>] [<repository>]
 
Does checks for whether or not "repository" is ready to be pulled to "trunk-repository".
 
:;trunk-repository
::May also be set by the environment variable RC_CHECK_TRUNK
::Defaults to 'ssh://hg@bitbucket.org/lindenlab/viewer-release'
:;repository
::Is the repository to be tested;
::if not specified, the script looks for a value in the system clipboard
 
:;verbosity-option
::may be any of:
      -q | --quiet    : print only error messages
      <no option>    : print only minimal messages about the repositories
      -v | --verbose  : print additional messages about progress
      -d | --debug    : maximum detail
 
This requires that you have the standard coding policy hooks enabled.
See [[Mercurial_Tools#Coding_Policy|Mercurial Tools Coding Policy]]
 
Exit status 0 indicates that the checks passed, any other value is failure.
 
=== Push Wrapper ===
 
This provides some simple safety checks before pushing changes.
 
    mm-push [ <target-repo> ]
 
 
* Checks for any uncommitted local changes
** if there are local uncommitted changes, asks for confirmation to proceed
* Translates any alias used for target-repo.
* Checks to see if there are unmerged changes in the target-repo.
** if there are remote changes, displays them in 'compact' format and aborts.
* Checks to see if there any local changes to be pushed.
** if there are local changes, displays them in 'compact' format and requests confirmation before pushing them.
 
=== Hooks ===
 
==== Well Formed XML Checker ====
 
''migrated into the general [[Mercurial Tools#Policy Commit Hook|mercurial coding policy hook]]''
 
== License Header Splicing ==


This tool splices the contents of one file into another, replacing any lines found between a start and and marker in the target file.  In the process, it preserves the content syntax, if any, found in the original file.  It is useful for replacing the license header in a file, and especially so when you have many files to modify
This tool splices the contents of one file into another, replacing any lines found between a start and and marker in the target file.  In the process, it preserves the content syntax, if any, found in the original file.  It is useful for replacing the license header in a file, and especially so when you have many files to modify
Line 176: Line 268:
  splice --keep --begin '$LicenseInfo:' --end '$/LicenseInfo' ''new-license'' ''source-file''
  splice --keep --begin '$LicenseInfo:' --end '$/LicenseInfo' ''new-license'' ''source-file''


=== DOS Line End Checker ===
== DOS Line End Checker ==


Usage:
Usage:
Line 188: Line 280:




=== Open Source Contribution Statistics ===
== Open Source Contribution Statistics==


Generates statistics on Open Source contributions from a viewer repository.
Generates statistics on Open Source contributions from a viewer repository.

Latest revision as of 09:13, 1 May 2015

These are some tools I've built and make available under the following warranty:

These tools work:
  • for me
  • as well as I need them to
  • right now

... that having been said, suggestions and requests for help are welcome.

All of these tools are available from the mercurial repository:

https://bitbucket.org/oz_linden/tools


Chat Logs

Together, the two scripts below can be used to prepare wiki archives of in-world meeting text chat.

The first extracts text from a chat log as produced by the viewer, and that output can be piped to the second to convert to wiki formatting:

chat-extract --begin '[2011/02/09 13:02]' --end '[2011/02/09 14:08]' ~/SecondLife/Logs/oz_linden/chat \
| sllog2wiki > ~/tmp/post.wiki

For an example of the output of the current version resulting from the above, see my user group archive for 9 Feb

I have an LSL script that can be used to record the timestamps and email the owner a chat-extract command line, but it is not quite polished enough for me to post here; ask if you are interested.

chat-extract

Extracts text from a log file; the viewer must have the timestamp option enabled.

 chat-extract
    --begin begin-timestamp
    --end   end-timestamp
    [ --ignore ignore-pattern-file ]
    [--help]
    chat-log

Searches the specified chat-log file for lines bounded by the begin and end timestamps, and writes them to standard output. The '.txt' suffix may be left off the file name, and the command will automatically also try the same name with a datestamp added if the file is not found without it.

The ignore-pattern-file, if specified, contains patterns (perl regular expressions) which cause any line they match to be omitted from the output.

The ignore option default can be set by putting an assignment in the file

$HOME/.chat-extract.rc 

whose contents look like:

ignore = ignore-pattern-file


sllog2wiki

Converts chat log input to a nice wiki presentation

 sllog2wiki
    [ --bots bot-names-file ]
    [--help]
    [ chat-log ]

Reads chat-log (or standard input if no file is specified) and writes wiki markup to standard output. The name column of the output contains the display name of the agent, linked to the profile for the user.

The bot-names-file, is a list of names (one per line) for which no links to profiles should be generated.

The bots option default can be set by putting an assignment in the file

$HOME/.sllog2wiki.rc 

whose contents look like:

bots = bot-names-file

Jira Issue Finder

Feed any stream of input to this script and it will extract the Jira issue keys from the stream and format them as a list. Issues that have been moved will be listed using the most current key:

Usage:

findjiras [options]

Formatting options

These options control the output format, and are mutually exclusive. With none of these specified, only the issue numbers are printed, separated by newline.

-s separator, --separator separator
separate the results with this string (such as ", ")

To format a list including the summary line from the issue, use one of:

-t, --text
format as plain text
-m, --html
format as an html descriptive list
-w, --wiki
format as a wiki descriptive list

Filtering options

These options filter the issues by project name; the default without these options is to find all valid Jira ids. Each may be specified more than once to specify multiple projects. Note that for issues that have been moved, this applies to the final issue id.
-p included-project, --project included-project
find issues only for the project named
-x excluded-project, --exclude excluded-project
specific projects not to include

Other options

-h, --help
show this help message and exit
-c, --count
print a summary of counts of the different jira types after the list
-u USERNAME, --user USERNAME
specify the user account in Jira (defaults to the FINDJIRAS_USER environment variable). If not specified, the script will prompt you for it.

Examples

To find all issues since a the release-2-1 tag, and display in wiki form:

hg log --follow --prune release-2-1 -rtip:0 --template '{desc}\n' | findjiras -w

To list just the issue ids for all issues in your local repository that are not in the canonical viewer-release repository:

hg out --template '{desc}\n' https://bitbucket.org/lindenlab/viewer-release | findjiras

Python Help Message Wiki Formatter

Usage:

      pyhelp2wiki [--title <section-title>] [--level <section-level>]
      pyhelp2wiki [--help]


Options:

optional arguments:
--title SECTION_TITLE Adds this title as a section header
--level SECTION_LEVEL The number of '=' characters

Reads the output of a conventional python command --help options (as produced by the python argparse package) from standard input, and writes a wiki markup by the python argparse package) from standard input, and writes a wiki markup version of it to standard output. version of it to standard output.

Mercurial Tools

Repository Collection Updater

mm-updates [<verbosity-option>] [-n|--dry-run] [-c|--config <configuration>] [  <repository> ... ]

Checks and updates local repositories based on a configuration file. It is useful in maintaining a set of local mirrors of remote repositories, and displaying the relationships between them.

If the configuration file name is not specified on the command line:

  1. The environment variable MM_UPDATES_CONFIG is checked
  2. If that is not set, then the default file is $\{HOME\}/.mm_updates_config

Each line of the configuration file contains 2 or more repositories:

local-path remote-repo downstream-repo...
local-path
Specifies a local hg repository (may be an hg alias, but that alias must resolve to a full local path name). This is the only repository that is ever modified by this command.
remote-repo
Is either a remote repository URL or a local repository path. Any changesets from the remote not found in the local repo are pulled to it; if this would require a merge, the mm-updates command fails with an error.
downstream-repo
Is a list of zero or more repositories: each may be a remote repository URL or a local repository path.
If specified, each repository is checked to see if the local repo contains any changesets not in the downstream repo and displays the number found.

Blank lines are allowed in the configuration file, and the '#' character starts comments, which are ignored.

If repositories are specified on the command line, then only those are updated and checked.

The verbosity options are: -d|--debug -v|--verbose -q|--quiet

The -n|--dry-run option causes the command to display what would have been fetched, but the local repository is not actually modified.

If a repository specified on the command line is not found in the configuration file, then remote-repo is assumed to be its 'default' repository, and downstream-repo is assumed to be its 'default-push' repository (if any).

Example Configuration file:

#      local-repo                  parent-repo                                   downstream-repo
/Users/oz/Work/viewer-release      ssh://bitbucket.org/lindenlab/viewer-release
/Users/oz/Work/viewer-beta         ssh://bitbucket.org/lindenlab/viewer-beta        /Users/oz/Work/viewer-release
/Users/oz/Work/viewer-betareview   /Users/oz/Work/viewer-beta
/Users/oz/Work/viewer-development  ssh://bitbucket.org/lindenlab/viewer-development /Users/oz/Work/viewer-beta
/Users/oz/Work/viewer-devreview    /Users/oz/Work/viewer-development


Merge

This is a wrapper that properly merges a set of changes from another repository.

Usage:

  mm-getfix <repository> [<changeset>]
or
  mm-getfix <repository> [-r <changeset>]
  mm-getfix <repository> [--rev <changeset>]

Prompts for an issue number to be included in the merge change comment (a default is extracted from the last element of the repository path).

Displays all non-merge changesets that would be merged by this operation, then prompts for a merge comment (with default made from issue number).

Entering return for either prompt accepts default and proceeds. After comment prompt, an 'hg fetch' command is executed. It is safe to abort the command at either prompt.

Release Candidate Checks

Usage:

  rc-check [<verbosity-option>] [{-t|--trunk} <trunk-repository>] [<repository>]

Does checks for whether or not "repository" is ready to be pulled to "trunk-repository".

trunk-repository
May also be set by the environment variable RC_CHECK_TRUNK
Defaults to 'ssh://hg@bitbucket.org/lindenlab/viewer-release'
repository
Is the repository to be tested;
if not specified, the script looks for a value in the system clipboard
verbosity-option
may be any of:
     -q | --quiet    : print only error messages
     <no option>     : print only minimal messages about the repositories
     -v | --verbose  : print additional messages about progress
     -d | --debug    : maximum detail 

This requires that you have the standard coding policy hooks enabled. See Mercurial Tools Coding Policy

Exit status 0 indicates that the checks passed, any other value is failure.

Push Wrapper

This provides some simple safety checks before pushing changes.

   mm-push [ <target-repo> ]


  • Checks for any uncommitted local changes
    • if there are local uncommitted changes, asks for confirmation to proceed
  • Translates any alias used for target-repo.
  • Checks to see if there are unmerged changes in the target-repo.
    • if there are remote changes, displays them in 'compact' format and aborts.
  • Checks to see if there any local changes to be pushed.
    • if there are local changes, displays them in 'compact' format and requests confirmation before pushing them.

Hooks

Well Formed XML Checker

migrated into the general mercurial coding policy hook

License Header Splicing

This tool splices the contents of one file into another, replacing any lines found between a start and and marker in the target file. In the process, it preserves the content syntax, if any, found in the original file. It is useful for replacing the license header in a file, and especially so when you have many files to modify

Usage:

splice -b <begin-marker> -e <end-marker> [-f <fail-log>] [--keep] <file-to-insert-between-markers> <file-to-edit>

Specifically, in the Second Life Viewer code, the following is usually correct:

splice --keep --begin '$LicenseInfo:' --end '$/LicenseInfo' new-license source-file

DOS Line End Checker

Usage:

   check-lineends [ -t | --trace ] 

Detects use of carriage return for line endings. Prints the paths of files that contain carriage returns that should not.

With the --trace option, detects the mercurial changeset that introduced them, and prints the log message for that changeset.


Open Source Contribution Statistics

Generates statistics on Open Source contributions from a viewer repository.

open-contributions <tag-list-file>

Where the tag-list-file contains a sequence of mercurial tag values, one per line.