Header Navigation

Issue is a client for reading and updating issues in a GitHub project issue tracker. Issue runs the query against the given project's issue tracker and prints a table of matching issues, sorted by issue summary. The default owner/repo is golang/go. If multiple arguments are given as the query, issue joins them by spaces to form a single issue search. These two commands are equivalent: Searches are always limited to open issues. If the query is a single number, issue prints that issue in detail, including all comments. Issue expects to find a GitHub "personal access token" in $HOME/.github-issue-token and will use that token to authenticate to GitHub when reading or writing issue data. A token can be created by visiting https://github.com/settings/tokens/new. The token only needs the 'repo' scope checkbox, and optionally 'private_repo' if you want to work with issue trackers for private repositories. It does not need any other permissions. The -token flag specifies an alternate file from which to read the token. If the -a flag is specified, issue runs as a collection of acme windows instead of a command-line tool. In this mode, the query is optional. If no query is given, issue uses "state:open". There are three kinds of acme windows: issue, issue creation, issue list, search result, and milestone list. The following text forms can be looked for (right clicked on) and open a window (or navigate to an existing one). Executing "New" opens an issue creation window. Executing "Search <query>" opens a new window showing the results of that search. An issue window, opened by loading an issue number, displays full detail about an issue, a header followed by each comment. For example: Executing "Get" reloads the issue data. Executing "Put" updates an issue. It saves any changes to the issue header and, if any text has been entered between the header and the "Reported by" line, posts that text as a new comment. If both succeed, Put then reloads the issue data. The "Closed" and "URL" headers cannot be changed. An issue creation window, opened by executing "New", is like an issue window but displays only an empty issue template: Once the template has been completed (only the title is required), executing "Put" creates the issue and converts the window into a issue window for the new issue. An issue list window displays a list of all open issue numbers and titles. If the project has any open milestones, they are listed in a header line. For example: As in any window, right clicking on an issue number opens a window for that issue. A search result window, opened by executing "Search <query>", displays a list of issues matching a search query. It shows the query in a header line. For example: Executing "Sort" in a search result window toggles between sorting by title and sorting by decreasing issue number. Executing "Bulk" in an issue list or search result window opens a new bulk edit window applying to the displayed issues. If there is a non-empty text selection in the issue list or search result list, the bulk edit window is restricted to issues in the selection. The bulk edit window consists of a metadata header followed by a list of issues, like: The metadata header shows only metadata shared by all the issues. In the above example, all four issues are open and have milestone Go1.4.3, but they have no common labels nor a common assignee. The bulk edit applies to the issues listed in the window text; adding or removing issue lines changes the set of issues affected by Get or Put operations. Executing "Get" refreshes the metadata header and issue summaries. Executing "Put" updates all the listed issues. It applies any changes made to the metadata header and, if any text has been entered between the header and the first issue line, posts that text as a comment. If all operations succeed, Put then refreshes the window as Get does. The milestone list window, opened by loading any of the names "milestone", "Milestone", or "Milestones", displays the open project milestones, sorted by due date, along with the number of open issues in each. For example: Loading one of the listed milestone names opens a search for issues in that milestone. The -e flag enables basic editing of issues with editors other than acme. The editor invoked is $VISUAL if set, $EDITOR if set, or else ed. Issue prepares a textual representation of issue data in a temporary file, opens that file in the editor, waits for the editor to exit, and then applies any changes from the file to the actual issues. When <query> is a single number, issue -e edits a single issue. See the “Issue Window” section above. If the <query> is the text "new", issue -e creates a new issue. See the “Issue Creation Window” section above. Otherwise, for general queries, issue -e edits multiple issues in bulk. See the “Bulk Edit Window” section above. The -json flag causes issue to print the results in JSON format using these data structures: If asked for a specific issue, the output is an Issue with Comments. Otherwise, the result is an array of Issues without Comments.

package uncurl is Go library to consume a Chrome/Chromium browser "Copy as cURL" string and generate one or more Go *http.Request objects from it In the Chrome or Chromium browser, if you open "Developer tools" and go to the Network tab and navigate somewhere with the browser, you will see a list of requests. Right-clicking one these requests yields a menu with a Copy submenu. One of those options is "Copy as cURL". It allows you to paste a `curl` command to your terminal or editor, one that reproduces the request if run. This library accepts that text input and turns it into a Go request. Further Go requests can be generated with different target URLs while maintaining the same header values.

Issue is a client for reading and updating issues in a GitHub project issue tracker. Issue runs the query against the given project's issue tracker and prints a table of matching issues, sorted by issue summary. The default owner/repo is golang/go. If multiple arguments are given as the query, issue joins them by spaces to form a single issue search. These two commands are equivalent: Searches are always limited to open issues. If the query is a single number, issue prints that issue in detail, including all comments. Issue expects to find a GitHub "personal access token" in $HOME/.github-issue-token and will use that token to authenticate to GitHub when reading or writing issue data. A token can be created by visiting https://github.com/settings/tokens/new. The token only needs the 'repo' scope checkbox, and optionally 'private_repo' if you want to work with issue trackers for private repositories. It does not need any other permissions. The -token flag specifies an alternate file from which to read the token. If the -a flag is specified, issue runs as a collection of acme windows instead of a command-line tool. In this mode, the query is optional. If no query is given, issue uses "state:open". There are three kinds of acme windows: issue, issue creation, issue list, search result, and milestone list. The following text forms can be looked for (right clicked on) and open a window (or navigate to an existing one). Executing "New" opens an issue creation window. Executing "Search <query>" opens a new window showing the results of that search. An issue window, opened by loading an issue number, displays full detail about an issue, a header followed by each comment. For example: Executing "Get" reloads the issue data. Executing "Put" updates an issue. It saves any changes to the issue header and, if any text has been entered between the header and the "Reported by" line, posts that text as a new comment. If both succeed, Put then reloads the issue data. The "Closed" and "URL" headers cannot be changed. An issue creation window, opened by executing "New", is like an issue window but displays only an empty issue template: Once the template has been completed (only the title is required), executing "Put" creates the issue and converts the window into a issue window for the new issue. An issue list window displays a list of all open issue numbers and titles. If the project has any open milestones, they are listed in a header line. For example: As in any window, right clicking on an issue number opens a window for that issue. A search result window, opened by executing "Search <query>", displays a list of issues matching a search query. It shows the query in a header line. For example: Executing "Sort" in a search result window toggles between sorting by title and sorting by decreasing issue number. Executing "Bulk" in an issue list or search result window opens a new bulk edit window applying to the displayed issues. If there is a non-empty text selection in the issue list or search result list, the bulk edit window is restricted to issues in the selection. The bulk edit window consists of a metadata header followed by a list of issues, like: The metadata header shows only metadata shared by all the issues. In the above example, all four issues are open and have milestone Go1.4.3, but they have no common labels nor a common assignee. The bulk edit applies to the issues listed in the window text; adding or removing issue lines changes the set of issues affected by Get or Put operations. Executing "Get" refreshes the metadata header and issue summaries. Executing "Put" updates all the listed issues. It applies any changes made to the metadata header and, if any text has been entered between the header and the first issue line, posts that text as a comment. If all operations succeed, Put then refreshes the window as Get does. The milestone list window, opened by loading any of the names "milestone", "Milestone", or "Milestones", displays the open project milestones, sorted by due date, along with the number of open issues in each. For example: Loading one of the listed milestone names opens a search for issues in that milestone. The -e flag enables basic editing of issues with editors other than acme. The editor invoked is $VISUAL if set, $EDITOR if set, or else ed. Issue prepares a textual representation of issue data in a temporary file, opens that file in the editor, waits for the editor to exit, and then applies any changes from the file to the actual issues. When <query> is a single number, issue -e edits a single issue. See the “Issue Window” section above. If the <query> is the text "new", issue -e creates a new issue. See the “Issue Creation Window” section above. Otherwise, for general queries, issue -e edits multiple issues in bulk. See the “Bulk Edit Window” section above. The -json flag causes issue to print the results in JSON format using these data structures: If asked for a specific issue, the output is an Issue with Comments. Otherwise, the result is an array of Issues without Comments.

Package geyser implements an HTTP client for the Steam Web API. API interfaces and methods are generated automatically by sub-package "apigen" and are structured as a tree. NOTE: A non-partner api key is used to fetch the API schema, so only non-partner interfaces are generated. Interfaces are grouped by their base name, with the leading "I" and the AppID removed. For example: all "IGCVersion_<ID>" interfaces are grouped into a single interface struct named "GCVersion" that is instantiated by passing the AppID as parameter ("GCVersion(version)"). Interfaces that don't have an AppID do not require an AppID parameter (e.g.: "ISteamApps" -> "SteamApps()"). Interfaces that have a single AppID still require an AppID parameter. The same grouping is done for interface methods. All methods with the same name but different versions are grouped by name and the version is parameterized ("Method(version)"). Methods that have a single version do not require a version parameter ("Method()"). The workflow for requesting an interface method is: Client is the root element. Interfaces are instantiated with methods in the Client struct (possibly requiring an AppID parameter). Interface methods are struct methods of the interface struct (possibly requiring a version parameter). Parameters to the request must be set in the Request configuration step (see Request.SetOptions). Parameters are validated automatically conforming the interface method schema and the request execution will return an error if the validation failed. Results of requests can be obtained in two ways: parsing the response body manually, or configuring the result object in the Request before executing. Requests are always sent using "format=json", so response bodies (seem to) always be in JSON format. For manual parsing, checking "Content-Type" response header is recommended. When setting the result object in the Request (see Request.SetResult), a "JSON-unmarshable" object is expected. All requests created by generated methods are pre-configured with a corresponding result struct. Result structs are also (initially) automatically generated, they are named by concatenating the interface struct name and the method name (e.g.: "ISteamApps/GetAppList" -> "SteamAppsGetAppList"). Given that each response has a specific format and cannot be automatically generated, most of these result structs are empty (so they are useless, but response bodies are still available for manual parsing). When a response format is known, the result struct will be updated and won't be automatically (re)generated. Look for non-empty result structs for each interface method to see if there's any available at the time. Contributions to implement proper result structs are welcome! NOTE: Since not all similarly named interfaces with different AppIDs are necessarily identical, this grouping can result in generated interface struct methods that are not present in a given interface. For example, given an API schema of: where IFace_2 is a superset of IFace_1, the resulting structure would be: GetValue and GetSpecificAppID2Value are generated struct methods of Face, regardless of AppID and version. Accessing Face(1).GetValue(1) is valid, so is accessing Face(1).GetValue(2). But accessing Face(1).GetSpecificAppID2Value() returns an error. API schema is defined by "Schema*" types that compose the tree-like structure of the generated API and provide basic methods for navigating and manipulation of the schema. A schema starts with a root Schema node that contains API information and a SchemaInterfaces collection of interfaces. SchemaInterfaces is a collection of SchemaInterface interfaces. It also provides helper methods to group interfaces by name, extract AppIDs and so on. SchemaInterface holds the specificiation of the interface and a SchemaMethods collection of methods. SchemaMethods is a collection of SchemaMethod and provides helpers methods to group methods by name, extract versions and so on. SchemaMethod represents the specification of an interface method. It also contains a collection of parameters SchemaMethodParams. SchemaMethodParams is a collection of SchemaMethodParam. It also provides helpers for parameter validation. SchemaMethodParam holds the specification of an interface method parameter. The specification for each interface is exposed through "Schema<InterfaceName>" public variables. These can also be used direcly by users for any other purpose, including instantiating individual interface structs directly. All of the collection types provide JSON encoding methods that help in serialization/deserialization to/from JSON format. These types can be used directly when deserializing a JSON schema. Steam Web API documentation can be found at: https://partner.steamgames.com/doc/webapi_overview https://developer.valvesoftware.com/wiki/Steam_Web_API https://wiki.teamfortress.com/wiki/WebAPI There are several interfaces and methods not present in the official API schema (returned by "ISteamWebAPIUtil/GetSupportedAPIList"), including game-specific schemas. These undocumented interfaces are fetched from third-party sources and are also generated along with the official one. Specifications of undocumented methods don't define any parameters, so no validation is performed or any documentation is generated. More importantly, they also don't define the HTTP method to be used. For now, these methods default to GET HTTP method. When an interface or method originates from an undocumented source, they'll have a comment indicating it. A comprehensive list of interfaces and methods, documented and undocumented, can be found at https://steamapi.xpaw.me APIs that are available on different hosts and have different schemas are generated under sub-packages. These sub-packages will contain their own "Client" struct that are thin wrappers around the base Client. Schema structure and code generation rules are the same as for the main package. Currently, only Dota 2 is known to geyser and is implemented in sub-package "dota2".