**Please use xcore/v2** **The version 1 is obsolete.** Package xcore is a set of basic objects for programation (XCache for caches, XDataset for data sets, XLanguage for languages and XTemplate for templates). For GO, the actual existing code includes: - XCache: Application Memory Caches for any purpose, with time control and quantity control of object in the cache and also check changes against original source. It is a thread safe cache. - XDataset: Basic nested data structures for any purpose (template injection, configuration files, database records, etc). - XLanguage: language dependent text tables for internationalization of code. The sources can be text or XML file definitions. - XTemplate: template system with meta language to create complex documents (compatible with any text language, HTML, CSS, JS, PDF, XML, etc), heavily used on CMS systems and others. It is already used on sites that serve more than 60 million pages a month (500 pages per second on pike hour) and can be used on multithreading environment safely. XCache is a library to cache all the data you want into current application memory for a very fast access to the data. The access to the data support multithreading and concurrency. For the same reason, this type of cache is not persistent (if you exit the application) and cannot grow too much (as memory is the limit). However, you can control a timeout of each cache piece, and eventually a comparison function against a source (file, database, etc) to invalid the cache. 1. Declare a new XCache with NewXCache() function: 2. Fill in the cache: Once you have declared the cache, you can fill it with anything you want. The main cache object is an interface{} so you can put here anything you need, from simple variables to complex structures. You need to use the Set function: Note the ID is always a string, so convert a database key to string if needed. 3. To use the cache, just ask for your entry with Get function: 4. To maintain the cache: You may need Del function, to delete a specific entry (maybe because you deleted the record in database). You may also need Clean function to deletes a percentage of the cache, or Flush to deletes it all. The Verify function is used to check cache entries against their sources through the Validator function. Be very careful, if the cache is big or the Validator function is complex (maybe ask for a remote server information), the verification may be VERY slow and huge CPU use. The Count function gives some stats about the cache. 5. How to use Verify Function: This function is recommended when the source is local and fast to check (for instance a language file or a template file). When the source is distant (other cluster database, any rpc source on another network, integration of many parts, etc), it is more recommended to create a function that will delete the cache when needed (on demand cache change). The validator function is a func(id, time.Time) bool function. The first parameter is the ID entry in the cache, the second parameter the time of the entry was created. The validator function returns true is the cache is still valid, or false if it needs to be invalidated. The XCache is thread safe. The cache can be limited in quantity of entries and timeout for data. The cache is automanaged (for invalid expired data) and can be cleaned partially or totally manually. The XLanguage table of text entries can be loaded from XML file, XML string or normal text file or string. It is used to keep a table of id=value set of entries in any languages you need, so it is easy to switch between XLanguage instance based on the required language needed. Obviously, any XLanguage you load in any language should have the same id entries translated, for the same use. 1. loading: You can load any file or XML string directly into the object. 1.1 The XML Format is: NAMEOFTABLE is the name of your table entry, for example "loginform", "user_report", etc. LG is the ISO-3369 2 letters language ID, for example "es" for spanish, "en" for english, "fr" for french, etc. ENTRYNAME is the ID of the entry, for example "greating", "yourname", "submitbutton". ENTRYVALUE is the text for your entry, for example "Hello", "You are:", "Save" if your table is in english. 1.2 The flat text format is: ENTRYNAME is the ID of the entry, for example "greating", "yourname", "submitbutton". ENTRYVALUE is the text for your entry, for example "Hello", "You are:", "Save" if your table is in english. There is no name of table or language in this format (you "know" what you are loading). The advantage to use XML format is to have more control over your language, and eventyally add attributes into your entries, for instance you may add attributes translated="yes/no", verified="yes/no", and any other data that your system could insert. The XLanguage will ignore those attributes loading the table. 2. creation: To create a new XLanguage empty structure: There are 4 functions to create the language from a file or string, flat text or XML text: Then you can use the set of basic access functions: SetName/SetLanguage functions are used to set the table name and language of the object (generally to build an object from scratch). GetName/GetLanguage functions are used to get the table name and language of the object (generally when you load it from some source). Set/Get/Del functions are used to add or modify a new entry, read an entry, or deletes an entry in the object. 1. Overview: The XDataSet is a set of interfaces and basic classes ready-to-use to build a standard set of data optionally nested and hierarchical, that can be used for any purpose: - Keep complex data in memory. - Create JSON structures. - Inject data into templates. - Interchange database data (records set and record). You can store into it generic supported data, as well as any complex interface structures: - Int - Float - String - Time - Bool - []Int - []Float - []Time - []Bool - XDataSetDef (anything extended with this interface) - []String - Anything else ( interface{} ) - XDataSetCollectionDef (anything extended with this interface) The generic supported data comes with a set of functions to get/set those data directly into the XDataset. Example: Note that all references to XDataset and XDatasetCollection are pointers, always (to be able to modify the values of them). 2. XDatasetDef interface: It is the interface to describe a simple set of data mapped as "name": value, where value can be of any type. The interface implements a good amount of basic methods to get the value on various format such as GetString("name"), GetInt("name"), etc (see below). If the value is another type as asked, the method should contert it if possible. For instance "key":123 required through GetString("key") should return "123". The XDataset type is a simple map[string]interface{} with all the implemented methods and should be enough to use for almost all required cases. However, you can build any complex structure that extends the interface and implements all the required functions to stay compatible with the XDatasetDef. 3. XDatasetCollectionDef Interface: This is the interface used to extend any type of data as a Collection, i-e an array of XDatasetDef. This is a slice of any XDatasetDef compatible data. The interface implements some methods to work on array structure such as Push, Pop, Shift, Unshift and some methods to search data into the array. The XDatasetCollection type is a simple []DatasetDef with all the implemented methods and should be enough to use for almost all required cases. 1. Overview: This is a class to compile and keep a Template that can be injected with an XDataSet structure of data, with a metalanguage to inject the data. The metalanguage is extremely simple and is made to be useful and **really** separate programation from template code (not like other many generic template systems that just mix code and data). A template is a set of HTML/XML (or any other language) string with a meta language to inject variables and build a final string. The XCore XTemplate system is based on the injection of parameters, language translation strings and data fields directly into the HTML (Or any other language you need) template. The HTML itself (or any other language) is a text code not directly used by the template system, but used to dress the data you want to represent in your preferred language. The variables to inject must be into a XDataSet structure or into a structure extended from XDataSetDef interface. The injection of data is based on a XDataSet structure of values that can be nested into another XDataSet and XDataSetConnection and so on. The template compiler recognize nested arrays to automatically make loops on the information. Templates are made to store reusable HTML code, and overall easily changeable by people that do not know how to write programs. A template can be as simple as a single character (no variables to inject) to a very complex nested, conditional and loops sub-templates. Yes. this is a template, but a very simple one without need to inject any data. Let's go more complex: Having an array of data, we want to paint it beautifull: We can create a template to inject this data into it: 2. Create and use XTemplateData: In sight to create and use templates, you have all those possible options to use: Creates the XTemplate from a string or a file or any other source: 3. Metalanguage Reference: 3.1 Comments: %-- and --% You may use comments into your template. The comments will be discarded immediately at the compilation of the template and do not interfere with the rest of your code. Example: 3.2 Nested Templates: [[...]] and [[]] You can define new nested templates into your main template A nested template is defined by: The templteid is any combination of lowers letters only (a-z), numbers (0-9), and 3 special chars: . (point) - (dash) and _ (underline). The template is closed with [[]]. There is no limits into nesting templates. Any nested template will inheritate all the father elements and can use father elements too. To call a sub-template, you need to use &&templateid&& syntax (described below in this document). Example: You may use more than one id into the same template to avoid repetition of the same code. The different id's are separated with a pipe | Important note: A template will be visible only on the same level of its declaration. For example, if you put a subtemplate "b" into a subtemplate "a", it will not be visible by &&b&& from the top level, but only into the subtemplate "a". 3.3 Simple Elements: ##...## and {{...}} There are 2 types of simple elements. Language elements and Data injector elements (also called field elements). We "logically" define the 2 type of elements. The separation is only for human logic and template filling, however the language information can perfectly fit into the data to inject (and not use ## entries). 3.3.1 Languages elements: ##entry## All the languages elements should have the format: ##entry##. A language entry is generally anything written into your code or page that does not come from a database, and should adapt to the language of the client visiting your site. Using the languages elements may depend on the internationalization of your page. If your page is going to be in a single language forever, you really dont need to use languages entries. The language elements generally carry titles, menu options, tables headers etc. The language entries are set into the "#" entry of the main template XDataset to inject, and is a XLanguage table. Example: With data to inject: 3.3.2 Field elements: {{fieldname}} Fields values should have the format: {{fieldname}}. Your fields source can be a database or any other preferred repository data source. Example: You can access an element with its path into the data set to inject separating each field level with a > (greater than). This will take the name of the second hobby in the dataset defined upper. (collections are 0 indexed). The 1 denotes the second record of the hobbies XDatasetCollection. If the field is not found, it will be replaced with an empty string. Tecnically your field names can be any string in the dataset. However do not use { } or > into the names of your fields or the XTemplate may not use them correctly. We recommend to use lowercase names with numbers and ._- Accents and UTF8 symbols are also welcome. 3.3.3 Scope: When you use an id to point a value, the template will first search into the available ids of the local level. If no id is found, the it will search into the upper levers if any, and so on. Example: At the level of 'data2', using {{appname}} will get back 'DomCore'. At the level of 'key1', using {{appname}} will get back 'Nested App'. At the level of 'key2', using {{appname}} will get back 'DomCore'. At the level of root, 'data1' or 'detail', using {{appname}} will get back an empty string. 3.3.4 Path access: id>id>id>id At any level into the data array, you can access any entry into the subset array. For instance, taking the previous array of data to inject, let's suppose we are into a nested meta elements at the 'data1' level. You may want to access directly the 'Juan' entry. The path will be: The José's status value from the root will be: 3.4 Meta Elements They consist into an injection of a XDataset, called the "data to inject", into the template. The meta language is directly applied on the structure of the data array. The data to inject is a nested set of variables and values with the structure you want (there is no specific construction rules). You can inject nearly anything into a template meta elements. Example of a data array to inject: You can access directly any data into the array with its relative path (relative to the level you are when the metaelements are applied, see below). There are 4 structured meta elements in the XTemplate templates to use the data to inject: Reference, Loops, Condition and Debug. The structure of the meta elements in the template must follow the structure of the data to inject. 3.4.1 References to another template: &&order&& 3.4.1.1 When order is a single id (characters a-z0-9.-_), it will make a call to a sub template with the same set of data and replace the &&...&& with the result. The level in the data set is not changed. Example based on previous array of Fred's data: 3.4.1.2 When order contains 2 parameters separated by a semicolumn :, then second parameter is used to change the level of the data of array, with the subset with this id. The level in the data set is changed to this sub set. Example based on previous array of Fred's data: 3.4.1.3 When order contains 3 parameters separated by a semicolumn :, the second and third parameters are used to search the name of the new template based on the data fields to inject. This is an indirect access to the template. The name of the subtemplate is build with parameter3 as prefix and the content of parameter2 value. The third parameter must be empty. 3.4.2 Loops: @@order@@ 3.4.2.1 Overview This meta element will loop over each itterance of the set of data and concatenate each created template in the same order. You need to declare a sub template for this element. You may aso declare derivated sub templates for the different possible cases of the loop: For instance, If your main subtemplate for your look is called "hobby", you may need a different template for the first element, last element, Nth element, Element with a value "no" in the sport field, etc. The supported postfixes are: When the array to iterate is empty: - .none (for example "There is no hobby") When the array contains elements, it will search in order, the following template and use the first found: - templateid.key.[value] value is the key of the vector line. If the collection has a named key (string) or is a direct array (0, 1, 2...) - templateid.first if it is the first element of the array set (new from v1.01.11) - templateid.last if it is the first element of the array set (new from v1.01.11) - templateid.even if the line number is even - templateid in all other cases (odd is contained here if even is defined) 3.4.2.2 When order is a single id (characters a-z0-9.-_), it will make a call to the sub template id with the same subset of data with the same id and replace the @@...@@ for each itterance of the data with the result. Example based on previous array of Fred's data: 3.4.2.3 When order contains 2 parameters separated by a semicolumn :, then first parameter is used to change the level of the data of array, with the subset with this id, and the second one for the template to use. Example based on previous array of Fred's data: 3.4.3 Conditional: ??order?? Makes a call to a subtemplate only if the field exists and have a value. This is very userfull to call a sub template for instance when an image or a video is set. When the condition is not met, it will search for the [id].none template. The conditional element does not change the level in the data set. 3.4.3.1 When order is a single id (characters a-z0-9.-_), it will make a call to the sub template id with the same field in the data and replace the ??...?? with the corresponding template Example based on previous array of Fred's data: 3.4.3.2 When order contains 2 parameters separated by a semicolumn :, then second parameter is used to change the level of the data of array, with the subset with this id. Example based on previous array of Fred's data: If the asked field is a catalog, true/false, numbered, you may also use .[value] subtemplates 3.5 Debug Tools: !!order!! There are two keywords to dump the content of the data set. This is very useful when you dont know the code that calls the template, don't remember some values, or for debug facilities. 3.5.1 !!dump!! Will show the totality of the data set, with ids and values. 3.5.1 !!list!! Will show only the tree of parameters, values are not shown.
Command goimports updates your Go import lines, adding missing ones and removing unreferenced ones. It's a drop-in replacement for your editor's gofmt-on-save hook. It has the same command-line interface as gofmt and formats your code in the same way. For emacs, make sure you have the latest go-mode.el: Then in your .emacs file: For vim, set "gofmt_command" to "goimports": For GoSublime, follow the steps described here: For other editors, you probably know what to do. Happy hacking!
Package schematic implements the parsing of Schematic files for Dragonfly. Due to the format of schematics, only blocks with an ID smaller than 256 are supported. This means that new blocks are not supported. Due to new blocks not being supported, this package does not provide methods to save blocks to a schematic. The Schematic struct provided by the schematic package implements Dragonfly's world.Structure interface, allowing for a high throughput for schematic pasting and easy usage. See World.BuildStructure for pasting a schematic.
Give open source Golang developers the credit they deserve, follow your legal obligations, and save time with `gocomply`. This little program scans the Go module in the current directory for all direct and indirect dependencies, and attempts to download and write all of their license files to stdout. Progress or warnings are written to stderr. See https://www.tawesoft.co.uk/gopkg/gocomply
Give open source Golang developers the credit they deserve, follow your legal obligations, and save time with `gocomply`. This little program scans the Go module in the current directory for all direct and indirect dependencies, and attempts to download and write all of their license files to stdout. Progress or warnings are written to stderr. See https://www.tawesoft.co.uk/gopkg/gocomply
Fresh is a command line tool that builds and (re)starts your web application everytime you save a go or template file. If the web framework you are using supports the Fresh runner, it will show build errors on your browser. It currently works with Traffic (https://github.com/pilu/traffic), Martini (https://github.com/codegangsta/martini) and gocraft/web (https://github.com/gocraft/web). Fresh will watch for file events, and every time you create/modifiy/delete a file it will build and restart the application. If `go build` returns an error, it will logs it in the tmp folder. Traffic (https://github.com/pilu/traffic) already has a middleware that shows the content of that file if it is present. This middleware is automatically added if you run a Traffic web app in dev mode with Fresh.
A filesystem hierarchy synchronizer Rename files in TARGET so that identical files found in SOURCE and TARGET have the same relative path. The main goal of the program is to make folders synchronization faster by sparing big file transfers when a simple rename suffices. It complements other synchronization programs that lack this capability. See http://ambrevar.bitbucket.io/hsync and 'hsync -h' for more details. Usage: For usage options, see: We store the file entries in the following structure: This 'entries' map indexes the possible file matches by content ('partialHash'). A file match references the paths that will be used to rename the file in TARGET from 'oldpath' to 'newpath'. Note that 'newpath' is given by 'sourceID.path', and 'oldpath' by 'targetID.path'. The algorithm is centered around one main optimization: rolling-checksums. We assume that two files match if they have the same partial hash. The initial partial hash is just the size with an empty hash. This speeds up the process since this saves an open/close of the file. We just need a 'stat'. Files will not be read unless a rolling-checksum is required. As a consequence, unreadable files with a unique size will be stored in 'entries', while unreadable conflicting files will be discarded. Note that the system allows to rename files that cannot be read. One checksum roll increments 'pos' and updates the hash by hashing the next BLOCKSIZE bytes of the file. BLOCKSIZE is set to a value that is commonly believed to be optimal in most cases. The optimal value would be the device blocksize where the file resides. It would be more complex and memory consuming to query this value for each file. We choose md5 (128 bits) as the checksum algorithm. Adler32, CRC-32 and CRC-64 are only a tiny little faster while suffering from more clashes. This choice should be backed up with a proper benchmark. A conflict arises when two files in either SOURCE or TARGET have the same partial hash. We solve the conflict by updating the partial hashes until they differ. If the partial hashes cannot be updated any further (i.e. we reached end-of-file), it means that the files are duplicates. Notes: - Partial hashes of conflicting files will be complete at the same roll since they have the same size. - When a partial hash is complete, we have the following relation: - There is only one possible conflicting file at a time. A file match may be erroneous if the partial hash is not complete. The most obvious case is when two different files are the only ones of size N in SOURCE and TARGET. This down-side is a consequence of the design choice, i.e. focus on speed. Erroneous matches can be corrected in the preview file. If we wanted no ambiguity, we would have to compute the full hashes and this would take approximately as much time as copying files from SOURCE to TARGET, like a regular synchronization tool would do. We store the digest 'hash.Hash' together with the file path for when we update a partial hash. Process: 1. We walk SOURCE completely. Only regular files are processed. The 'sourceID' are stored. If two entries conflict (they have the same partial hash), we compute update the partial hashes until they do not conflict anymore. If the conflict is not resolvable, i.e. the partial hash is complete and files are identical, we drop both files from 'entries'. Future files can have the same partial hash that led to a former conflict. To distinguish the content from former conflicts when adding a new file, we must compute the partial hash up to the 'pos' of the last conflict (the number of checksum rolls). To keep track of this 'pos' when there is a conflict, we mark all computed partial hash as dummy values. When the next entry will be added, we will have to compute the partial hash until it does not match a dummy value in 'entries'. Duplicates are not processed but display a warning. Usually the user does not want duplicates, so she is better off fixing them before processing with the renames. It would add a lot of complexity to handle duplicates properly. 2. We walk TARGET completely. We skip all dummies as source the SOURCE walk. We need to analyze SOURCE completely before we can check for matches. - If there are only dummy entries, there was an unsolvable conflict in SOURCE. We drop the file. - If we end on a non-empty entry with an 'unsolvable' targetID, it means that an unsolvable conflict with target files happened with this partial hash. This is only possible at end-of-file. We drop the file. - If we end on an empty entry, there is no match with SOURCE and we drop the file. - If we end on a non-empty entry without previous matches, we store the match. - Else we end on a non-empty entry with one match already present. This is a conflict. We solve the conflict as for the SOURCE walk except that we need to update the partial hashes of three files: the SOURCE file, the first TARGET match and the new TARGET match. 3. We generate the 'renameOps' and 'reverseOps' maps. They map 'oldpath' to 'newpath' and 'newpath' to 'oldpath' respectively. We drop entries where 'oldpath==newpath' to spare a lot of noise. Note that file names are not used to compute a match since they could be identical while the content would be different. 4. We proceed with the renames. Chains and cycles may occur. - Example of a chain of renames: a->b, b->c, c->d. - Example of a cycle of renames: a->b, b->c, c->a. TARGET must be fully analyzed before proceeding with the renames so that we can detect chains. We always traverse chains until we reach the end, then rename the elements while going backward till the beginning. The beginning can be before the entry point. 'reverseOps' is used for going backward. When a cycle is detected, we break it down to a chain. We rename one file to a temporary name. Then we add this new file to the other end of the chain so that it gets renamed to its original new name once all files have been processed.
Package grab provides a HTTP download manager implementation. Get is the most simple way to download a file: Get will download the given URL and save it to the given destination directory. The destination filename will be determined automatically by grab using Content-Disposition headers returned by the remote server, or by inspecting the requested URL path. An empty destination string or "." means the transfer will be stored in the current working directory. If a destination file already exists, grab will assume it is a complete or partially complete download of the requested file. If the remote server supports resuming interrupted downloads, grab will resume downloading from the end of the partial file. If the server does not support resumed downloads, the file will be retransferred in its entirety. If the file is already complete, grab will return successfully. For control over the HTTP client, destination path, auto-resume, checksum validation and other settings, create a Client: You can monitor the progress of downloads while they are transferring:
Package d2s provides functions for interfacing with Diablo II saved game file formats. Current file formats supported are v1.10 - v1.13d.
Fresh is a command line tool that builds and (re)starts your web application everytime you save a go or template file. If the web framework you are using supports the Fresh runner, it will show build errors on your browser. It currently works with Traffic (https://github.com/pilu/traffic), Martini (https://github.com/codegangsta/martini) and gocraft/web (https://github.com/gocraft/web). Fresh will watch for file events, and every time you create/modifiy/delete a file it will build and restart the application. If `go build` returns an error, it will logs it in the tmp folder. Traffic (https://github.com/pilu/traffic) already has a middleware that shows the content of that file if it is present. This middleware is automatically added if you run a Traffic web app in dev mode with Fresh.
Multi-device Android Debug Bridge The madb command wraps Android Debug Bridge (adb) command line tool and provides various features for controlling multiple Android devices concurrently. Usage: The madb commands are: The madb flags are: The global flags are: Clears your app data from all devices. To specify which user's data should be cleared, use 'madb user set' command to set the default user ID for that device. (See 'madb help user' for more details.) Usage: <application_id> is usually the package name where the activities are defined. (See: http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename) If the application ID is not specified, madb automatically determines which app to be cleared, based on the build scripts found in the current working directory. If the working directory contains a Gradle Android project (i.e., has "build.gradle"), run a small Gradle script to extract the application ID. In this case, the extracted ID is cached, so that "madb clear-data" can be repeated without even running the Gradle script again. The ID can be re-extracted by clearing the cache by providing "-clear-cache" flag. The madb clear-data flags are: Runs the provided adb command on all devices and emulators concurrently. For example, the following line: copies the ./foo.txt file to /sdcard/foo.txt for all the currently connected devices. There are a few pre-defined keywords that can be expanded within an argument. For example, the following line: copies the ./Alice.txt file to the device named Alice, and ./Bob.txt to the device named Bob. Note that you should type in "{{name}}" as-is, with the opening/closing curly braces, similar to when you're using a template library such as mustache. To see the list of available adb commands, type 'adb help'. Usage: <command> is a normal adb command, which will be executed on all devices and emulators. The madb exec flags are: Runs the provided external command for all devices and emulators concurrently. For each available device, this command will spawn a sub-shell with the ANDROID_SERIAL environmental variable set to the target device serial, and then will run the provided external command. There are a few pre-defined keywords that can be expanded within an argument. For example, the following line: prints out the name and serial pairs for each device. Note that you should type in "{{name}}" as-is, with the opening/closing curly braces, similar to when you're using a template library such as mustache. This command is intended to be used with external commands that are designed to work with only a single device at a time (e.g. gomobile, flutter). Usage: <external_command> is an external shell command to run for all devices and emulators. The madb extern flags are: Manages device groups, each of which can have one or more device members. The device groups can be used for specifying the target devices of other madb commands. Usage: The madb group commands are: Adds members to a device group. This command also creates the group, if the group does not exist yet. The device group can be used when specifying devices in any madb commands. When creating a new device group with this command, the provided name must not conflict with an existing device nickname (see: madb help name set). A group can contain another device group, in which case all the members of the other group will also be considered as members of the current group. Usage: <group_name> is an alpha-numeric string with no special characters or spaces. This name must not be an existing device nickname. <member> is a member specifier, which can be one of device serial, qualifier, device index (e.g., '@1', '@2'), device nickname, or another device group. Clears all the existing device groups. Usage: Deletes an existing device group. Usage: <group_name> the name of an existing device group. You can specify more than one group names. Lists the name and members of all the existing device groups. Usage: Removes members from an existing device group. If there are no remaining members after that, the group gets deleted. Usage: <group_name> is an alpha-numeric string with no special characters or spaces. This name must be an existing device group name. <member> is a member specifier, which can be one of device serial, qualifier, device index (e.g., '@1', '@2'), device nickname, or another device group. Renames an existing device group. Usage: <old_name> is the name of an existing device group. <new_name> is the new name for the existing group. This must be an alpha-numeric string with no special characters or spaces, and must not conflict with another existing device or group name. Installs your app on all devices. If the working directory contains a Gradle Android project (i.e., has "build.gradle"), this command will first run a small Gradle script to extract the variant properties, which will be used to find the best matching .apk for each device. These extracted properties are cached, and "madb install" can be repeated without running this Gradle script again. The properties can be re-extracted by clearing the cache by providing "-clear-cache" flag. Once the variant properties are extracted, the best matching .apk for each device will be installed in parallel. This command is similar to running "gradlew :<moduleName>:<variantName>Install", but "madb install" is more flexible: 1) you can install the app to a subset of the devices, and 2) the app is installed concurrently, which saves a lot of time. If the working directory contains a Flutter project (i.e., has "flutter.yaml"), this command will run "flutter install --device-id <device serial>" for all devices. To install your app for a specific user on a particular device, use 'madb user set' command to set the default user ID for that device. (See 'madb help user' for more details.) To install a specific .apk file to all devices, use "madb exec install <path_to_apk>" instead. Usage: The madb install flags are: Manages device nicknames, which are meant to be more human-friendly compared to the device serials provided by adb tool. Usage: The madb name commands are: Sets a human-friendly nickname that can be used when specifying the device in any madb commands. The device serial can be obtained using the 'adb devices -l' command. For example, consider the following example output: The first value, 'HT4BVWV00023', is the device serial. To assign a nickname for this device, run the following command: and it will assign the 'MyTablet' nickname to the device serial 'HT4BVWV00023'. The alternative device specifiers (e.g., 'usb:3-3.4.2', 'product:volantisg') can also have nicknames. When a nickname is set for a device serial, the nickname can be used to specify the device within madb commands. There can only be one nickname for a device serial. When the 'madb name set' command is invoked with a device serial with an already assigned nickname, the old one will be replaced with the newly provided one. Usage: <device_serial> is a device serial (e.g., 'HT4BVWV00023') or an alternative device qualifier (e.g., 'usb:3-3.4.2') obtained from 'adb devices -l' command <nickname> is an alpha-numeric string with no special characters or spaces. Unsets a nickname assigned by the 'madb name set' command. Either the device serial or the assigned nickname can be specified to remove the mapping. Usage: There should be only one argument, which is either the device serial or the nickname. Lists all the currently stored nicknames of device serials. Usage: Clears all the currently stored nicknames of device serials. Usage: Resolves the provided device specifiers and prints out their device serials, each in a separate line. This command only displays the unique serials of the devices that are currently available. This command can be useful when you want to use the device nicknames and groups defined by madb in other command line tools. For example, to run a flutter app on "MyTablet" device, you can use the following command (in Bash): Usage: <specifier> can be anything that is accepted in the '-n' flag (see 'madb help'). It can be a device serial, qualifier, index, nickname, or a device group name. Runs the provided adb shell command on all devices and emulators concurrently. This command is a shorthand syntax for 'madb exec shell <command...>'. See 'madb help exec' for more details. Usage: <command> is a normal adb shell command, which will be executed on all devices and emulators. The madb shell flags are: Launches your app on all devices. In most cases, running "madb start" from an Android Gradle project directory will do the right thing for you. "madb start" will build the project first. After the project build is completed, this command will install the best matching .apk for each device, only if one or more of the following conditions are met: If you would like to run the same version of the app repeatedly (e.g., for QA testing), you can explicitly turn off the build flag by providing "-build=false" to skip the build step. To run your app as a specific user on a particular device, use 'madb user set' command to set the default user ID for that device. (See 'madb help user' for more details.) Usage: <application_id> is usually the package name where the activities are defined. (See: http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename) <activity_name> is the Java class name for the activity you want to launch. If the package name of the activity is different from the application ID, the activity name must be a fully-qualified name (e.g., com.yourcompany.yourapp.MainActivity). If either <application_id> or <activity_name> is provided, the other must be provided as well. If no arguments are specified, madb automatically determines which app to launch, based on the build scripts found in the current working directory. 1) If the working directory contains a Flutter project (i.e., has "flutter.yaml"), this command will run "flutter start --device-id <device serial>" for all the specified devices. 2) If the working directory contains a Gradle Android project (i.e., has "build.gradle"), this command will run a small Gradle script to extract the application ID and the main activity name. In this case, the extracted IDs are cached, so that "madb start" can be repeated without even running the Gradle script again. The IDs can be re-extracted by clearing the cache by providing "-clear-cache" flag. The madb start flags are: Stops your app on all devices. To stop your app for a specific user on a particular device, use 'madb user set' command to set the default user ID for that device. (See 'madb help user' for more details.) Usage: <application_id> is usually the package name where the activities are defined. (See: http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename) If the application ID is not specified, madb automatically determines which app to stop, based on the build scripts found in the current working directory. 1) If the working directory contains a Flutter project (i.e., has "flutter.yaml"), this command will run "flutter stop --device-id <device serial>" for all the specified devices. 2) If the working directory contains a Gradle Android project (i.e., has "build.gradle"), run a small Gradle script to extract the application ID. In this case, the extracted ID is cached, so that "madb stop" can be repeated without even running the Gradle script again. The ID can be re-extracted by clearing the cache by providing "-clear-cache" flag. The madb stop flags are: Uninstall your app from all devices. To uninstall your app for a specific user on a particular device, use 'madb user set' command to set the default user ID for that device. (See 'madb help user' for more details.) Usage: <application_id> is usually the package name where the activities are defined. (See: http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename) If the application_id is not specified, madb automatically determines which app to uninstall, based on the build scripts found in the current working directory. If the working directory contains a Gradle Android project (i.e., has "build.gradle"), run a small Gradle script to extract the application ID. In this case, the extracted ID is cached, so that "madb uninstall" can be repeated without even running the Gradle script again. The ID can be re-extracted by clearing the cache by providing "-clear-cache" flag. The madb uninstall flags are: Manages default user settings for each device. An Android device can have multiple user accounts, and each user account has a numeric ID associated with it. Certain adb commands accept '--user <user_id>' as a parameter to allow specifying which of the Android user account should be used when running the command. The default behavior when the user ID is not provided varies by the adb command being run. Some madb commands internally run these adb commands which accept the '--user' flag. You can let madb use different user IDs for different devices by storing the default user ID for each device using 'madb user set' command. If the default user ID is not set for a particular device, madb will not provide the '--user' flag to the underlying adb command, and the current user will be used for that device as a result. Below is the list of madb commands which are affected by the default user ID settings: For more details on how to obtain the user ID from an Android device, see 'madb user help set'. Usage: The madb user commands are: Sets a default user ID to be used for the specified device, when there are multiple user accounts on a single device. The user IDs can be obtained using the 'adb [<device_serial>] shell pm list users' command. Alternatively, you can use 'madb exec' if you want to specify the device with a nickname. For example, running the following command: will list the available users and their IDs on the MyPhone device. Consider the following example output: There are two available users, "John Doe" and "Work profile". Each user is assigned a "user ID", which appears on the left of the user name. In this case, the user ID of "John Doe" is "0", and the user ID of the "Work profile" is "10". To use the "Work profile" as the default user when running madb commands on this device, run the following command: and then madb will use "Work profile" as the default user for device "MyPhone" in any of the subsequence madb commands. Usage: <device_serial> is the unique serial number for the device, which can be obtained from 'adb devices'. <user_id> is one of the user IDs obtained from 'adb shell pm list users' command. Unsets the default user ID assigned by the 'madb user set' command for the specified device. Running this command without any device specifiers will unset the default users only for the currently available devices and emulators, while keeping the default user IDs for the other devices. Usage: <device_serial> is the unique serial number for the device, which can be obtained from 'adb devices'. Lists all the currently stored default user IDs for devices. Usage: Clears all the currently stored default user IDs for devices. This command clears the default user IDs regardless of whether the device is currently connected or not. Usage: Prints the madb version number to the console. If this version of madb binary is an official release, this command will show the version number. Otherwise, the version will be in the form of "<version>-develop", where the version indicates the most recent stable release version prior to this version of madb binary. Usage: Help with no args displays the usage of the parent command. Help with args displays the usage of the specified sub-command or help topic. "help ..." recursively displays help for all commands and topics. Usage: [command/topic ...] optionally identifies a specific sub-command or help topic. The madb help flags are:
Copyright 2016 - 2018 The excelize Authors. All rights reserved. Use of this source code is governed by a BSD-style license that can be found in the LICENSE file. Package excelize providing a set of functions that allow you to write to and read from XLSX files. Support reads and writes XLSX file generated by Microsoft Excel™ 2007 and later. Support save file without losing original charts of XLSX. This library needs Go version 1.8 or later. See https://xuri.me/excelize for more information about this package.
Package draw2d is a pure go 2D vector graphics library with support for multiple output devices such as images (draw2d), pdf documents (draw2dpdf) and opengl (draw2dgl), which can also be used on the google app engine. It can be used as a pure go Cairo alternative. draw2d is released under the BSD license. Operations in draw2d include stroking and filling polygons, arcs, Bézier curves, drawing images and text rendering with truetype fonts. All drawing operations can be transformed by affine transformations (scale, rotation, translation). Package draw2d follows the conventions of http://www.w3.org/TR/2dcontext for coordinate system, angles, etc... To install or update the package draw2d on your system, run: Package draw2d itself provides a graphic context that can draw vector graphics and text on an image canvas. The following Go code generates a simple drawing and saves it to an image file: There are more examples here: https://github.com/llgcode/draw2d/tree/master/samples Drawing on pdf documents is provided by the draw2dpdf package. Drawing on opengl is provided by the draw2dgl package. See subdirectories at the bottom of this page. The samples are run as tests from the root package folder `draw2d` by: Or if you want to run with test coverage: This will generate output by the different backends in the output folder. Laurent Le Goff wrote this library, inspired by Postscript and HTML5 canvas. He implemented the image and opengl backend with the freetype-go package. Also he created a pure go Postscript interpreter, which can read postscript images and draw to a draw2d graphic context (https://github.com/llgcode/ps). Stani Michiels implemented the pdf backend with the gofpdf package. - https://github.com/llgcode/ps: Postscript interpreter written in Go - https://github.com/gonum/plot: drawing plots in Go - https://github.com/muesli/smartcrop: content aware image cropping - https://github.com/peterhellberg/karta: drawing Voronoi diagrams - https://github.com/vdobler/chart: basic charts in Go
xig To fetch **instagram** user img, content, avatar data. install from github usage list To fetch recently img(12), avatar and content To fetch **ALL** images data (if user uploaded more, may slow) Print recently data Output format: To find some deleted content Some users turn to private account, using `-u` to login user account for fetch private data. (required setting environment variables in `IGUSER`, `IGPASS`, and cookies file will save as `cookies.gob`) by user * All images will try to fetch original size. * Private user need setting `IGUSER`, `IGPASS` and using `-u`. Cookies file will save as `cookies.gob` * Content's readable date is in `RFC3339` format. * instagram won't to ban ip, may CDN doesn't check. * `xig`'s code base are not pretty, I will make it pretty :) For crontab, every 1m to fetch For crontab, using `-d` for delay fetch.
Copyright 2016 - 2018 The excelize Authors. All rights reserved. Use of this source code is governed by a BSD-style license that can be found in the LICENSE file. Package excelize providing a set of functions that allow you to write to and read from XLSX files. Support reads and writes XLSX file generated by Microsoft Excel™ 2007 and later. Support save file without losing original charts of XLSX. This library needs Go version 1.8 or later. See https://xuri.me/excelize for more information about this package.
Package excelize providing a set of functions that allow you to write to and read from XLSX files. Support reads and writes XLSX file generated by Microsoft Excel™ 2007 and later. Support save file without losing original charts of XLSX. This library needs Go version 1.8 or later. See https://xuri.me/excelize for more information about this package.
Fresh is a command line tool that builds and (re)starts your web application everytime you save a go or template file. If the web framework you are using supports the Fresh runner, it will show build errors on your browser. It currently works with Traffic (https://github.com/pilu/traffic), Martini (https://github.com/codegangsta/martini) and gocraft/web (https://github.com/gocraft/web). Fresh will watch for file events, and every time you create/modifiy/delete a file it will build and restart the application. If `go build` returns an error, it will logs it in the tmp folder. Traffic (https://github.com/pilu/traffic) already has a middleware that shows the content of that file if it is present. This middleware is automatically added if you run a Traffic web app in dev mode with Fresh.
Command godep helps build packages reproducibly by fixing their dependencies. Save currently-used dependencies to file Godeps: Build project using saved dependencies: or
Package captcha implements generation and verification of image and audio CAPTCHAs. A captcha solution is the sequence of digits 0-9 with the defined length. There are two captcha representations: image and audio. An image representation is a PNG-encoded image with the solution printed on it in such a way that makes it hard for computers to solve it using OCR. An audio representation is a WAVE-encoded (8 kHz unsigned 8-bit) sound with the spoken solution (currently in English, Russian, Chinese, and Japanese). To make it hard for computers to solve audio captcha, the voice that pronounces numbers has random speed and pitch, and there is a randomly generated background noise mixed into the sound. This package doesn't require external files or libraries to generate captcha representations; it is self-contained. To make captchas one-time, the package includes a memory storage that stores captcha ids, their solutions, and expiration time. Used captchas are removed from the store immediately after calling Verify or VerifyString, while unused captchas (user loaded a page with captcha, but didn't submit the form) are collected automatically after the predefined expiration time. Developers can also provide custom store (for example, which saves captcha ids and solutions in database) by implementing Store interface and registering the object with SetCustomStore. Captchas are created by calling New, which returns the captcha id. Their representations, though, are created on-the-fly by calling WriteImage or WriteAudio functions. Created representations are not stored anywhere, but subsequent calls to these functions with the same id will write the same captcha solution. Reload function will create a new different solution for the provided captcha, allowing users to "reload" captcha if they can't solve the displayed one without reloading the whole page. Verify and VerifyString are used to verify that the given solution is the right one for the given captcha id. Server provides an http.Handler which can serve image and audio representations of captchas automatically from the URL. It can also be used to reload captchas. Refer to Server function documentation for details, or take a look at the example in "capexample" subdirectory.
This package implements a parser for configuration files. This allows easy reading and writing of structured configuration files. Given a sample configuration file: To read this configuration file, do: Note the support for unfolding variables (such as %(base-url)s), which are read from the special (reserved) section name [default]. A new configuration file can also be created with: This results in the file: Note that sections and options are case-insensitive (values are case-sensitive) and are converted to lowercase when saved to a file. The functionality and workflow is loosely based on the configparser.py package of the Python Standard Library.
Package excelize providing a set of functions that allow you to write to and read from XLSX files. Support reads and writes XLSX file generated by Microsoft Excel™ 2007 and later. Support save file without losing original charts of XLSX. This library needs Go version 1.10 or later. See https://xuri.me/excelize for more information about this package.
Package okatype (i.e., Okanero type) provides basic types used for implementing the Okanero protocol, for the Go programming language. With the Okanero protocol, there is a message-oriented layer to the protocol. An Okanero Message is represented, in the Golang code, by: okatype_message.Type. However, okatype_message.Type makes more sense in the context of three other types. In the Golang code, there are 4 major types that you should start with, when dealing with the Okanero protocol's message-oriented layer: • okatype_message.Type • okatype_block.Type • okatype_datum.Type • okatype_content.Type The way that these relate to each other are: You can see nesting with okatype_message.Type as: And with okatype_message.Type as: And with okatype_datum.Type as: To understand this: • What is sent over or received from the network is an Okanero Message. • What is endorsed into a Blockchain is an Okanero Block. This is what an agent acting as an endorser would create. (In other related technologies, you might call "endorsers": "miners" or "stakers".) • What is created by the author is an Okanero Datum. This is what would-be endorsers would try to turn into an Okanero Block. • Content is where the the author would assert any information the author wishes to assert. (Ex: if the content was an event, then it might have a "name" field (ex: "name"="FOOD_EATEN"), and a "version" field (ex: "verion"="1.0.0"), and possibly some other information (ex: "calories"="240", "sodium"="10g").) An Okanero Message is represented by okatype_message.Type. An Okanero Message is what you would send over or receive from the network. An Okanero Message is also what you might save to or read from a file. When serialized into a []byte, an Okanero Message can look like: (Note the nested Okanero Block inside of the Okanero Message. We will go into more detail about Okanero Blocks shortly.) You may receive a serialized Okanero Message over a network communication, or stored in (or as part of) a file. You can think of this as the "native" format of an Okanero Message. When working with an Okanero Message in Golang code (you probably wouldn't want to work with the serialized Okanero Message directly, but instead), likely would want to load this kind of data into an okatype_message.Type. (Also, from the Golang code, likely, you would will not have this serialized Okanero Message data in the form of a []byte, but instead will have it coming from an io.Reader. So....) For example: You can then more easily work with the different aspects of an Okanero Message more easily. For example: An Okanero Message wraps an Okanero Block. (You could (probably safely) conflate an Okanero Block with a "Block" in a "Blockchain".) When serialized into a []byte, an Okanero Message can look like: (Note the nested Okanero Datum inside of the Okanero Message. We will go into more detail about Okanero Datum shortly.) A serialized Okanero Datum might look like:
Copyright 2016 - 2018 The excelize Authors. All rights reserved. Use of this source code is governed by a BSD-style license that can be found in the LICENSE file. Package excelize providing a set of functions that allow you to write to and read from XLSX files. Support reads and writes XLSX file generated by Microsoft Excel™ 2007 and later. Support save file without losing original charts of XLSX. This library needs Go version 1.8 or later. See https://xuri.me/excelize for more information about this package.
Copyright 2016 - 2018 The excelize Authors. All rights reserved. Use of this source code is governed by a BSD-style license that can be found in the LICENSE file. Package excelize providing a set of functions that allow you to write to and read from XLSX files. Support reads and writes XLSX file generated by Microsoft Excel™ 2007 and later. Support save file without losing original charts of XLSX. This library needs Go version 1.8 or later. See https://xuri.me/excelize for more information about this package.
Package for working with dBase III plus database files. 1. Package provides both reflection-via-struct interface and direct Row()/FieldValueByName()/AddxxxField() interface. 2. Once table is created and rows added to it, table structure can not be modified. 3. Working with reflection-via-struct interface is easier and produces less verbose code. 4. Use Iterator to iterate over table since it skips deleted rows. TODO: File is loaded and kept in-memory. Not a good design choice if file is huge. This should be changed to use buffers and keep some of the data on-disk in the future. Current API structure should allow redesign. Typical usage db := dbf.New() or dbf.LoadFile(filename) then use db.NewIterator() and iterate or db.Append() do not forget db.SaveFile(filename) if you want changes saved.
Copyright 2016 - 2018 The excelize Authors. All rights reserved. Use of this source code is governed by a BSD-style license that can be found in the LICENSE file. Package excelize providing a set of functions that allow you to write to and read from XLSX files. Support reads and writes XLSX file generated by Microsoft Excel™ 2007 and later. Support save file without losing original charts of XLSX. This library needs Go version 1.8 or later. See https://xuri.me/excelize for more information about this package.
Package draw2d is a pure go 2D vector graphics library with support for multiple output devices such as images (draw2d), pdf documents (draw2dpdf) and opengl (draw2dgl), which can also be used on the google app engine. It can be used as a pure go Cairo alternative. draw2d is released under the BSD license. Operations in draw2d include stroking and filling polygons, arcs, Bézier curves, drawing images and text rendering with truetype fonts. All drawing operations can be transformed by affine transformations (scale, rotation, translation). Package draw2d follows the conventions of http://www.w3.org/TR/2dcontext for coordinate system, angles, etc... To install or update the package draw2d on your system, run: Package draw2d itself provides a graphic context that can draw vector graphics and text on an image canvas. The following Go code generates a simple drawing and saves it to an image file: There are more examples here: https://github.com/llgcode/draw2d/tree/master/samples Drawing on pdf documents is provided by the draw2dpdf package. Drawing on opengl is provided by the draw2dgl package. See subdirectories at the bottom of this page. The samples are run as tests from the root package folder `draw2d` by: Or if you want to run with test coverage: This will generate output by the different backends in the output folder. Laurent Le Goff wrote this library, inspired by Postscript and HTML5 canvas. He implemented the image and opengl backend with the freetype-go package. Also he created a pure go Postscript interpreter, which can read postscript images and draw to a draw2d graphic context (https://github.com/llgcode/ps). Stani Michiels implemented the pdf backend with the gofpdf package. - https://github.com/llgcode/ps: Postscript interpreter written in Go - https://github.com/gonum/plot: drawing plots in Go - https://github.com/muesli/smartcrop: content aware image cropping - https://github.com/peterhellberg/karta: drawing Voronoi diagrams - https://github.com/vdobler/chart: basic charts in Go