The Booking resource represents booking segments in the SAP Concur Travel system. TripLink suppliers use this resource to display a subset of the full booking fields.
Version 1.1
/travel/booking/v1.1/{query_parameters}
In order to obtain itinerary data when making Itinerary API calls, the value of the OAuth scope parameter must be set to: ITINER
Creates a new booking or updates an existing booking. A new booking will be assigned to the specified trip, or if no trip is specified, the first itinerary that spans the booking dates. If no trip is specified and no itinerary exists that spans the booking dates, a new itinerary will be created.
This endpoint can be used to create/update bookings for a user that is not the OAuth consumer. This is most often done when a travel supplier or Travel Management Company needs to create/update a booking on behalf of a user. The supplier or TMC must be registered with SAP Concur, and must have an account that has one of the following user roles: Web Services Administrator for Professional, or Can Administer for Standard.
POST /api/travel/booking/v1.0?tripId=12345678 HTTPS/1.1
Host: www.concursolutions.com
Authorization: OAuth {access token}
Examples:
https://www.concursolutions.com/api/travel/booking/v1.1?tripId={tripId}
https://www.concursolutions.com/api/travel/booking/v1.1?userid_type=login_id&userid_value={loginID}
application/xml
Authorization header with OAuth token for a valid SAP Concur user. In order to create or update booking for anyone other than the OAuth consumer, the OAuth consumer must have one of the following user roles in SAP Concur: Company Administrator or Web Services Administrator for Professional, or Can Administer for Standard.
The request contains a Booking parent element with the following child elements:
| Required Element | Description |
|---|---|
BookingSource |
The supplier’s name. |
RecordLocator |
Record locator for this booking. This is often six alphanumeric characters but can have other formats depending on the booking source |
| Optional Element | Description |
|---|---|
DateBookedLocal |
The date the booking was created, in the booking location’s local time. Format: YYYY-MM-DDThh:mm:ss |
FormOfPaymentName |
The name of the form of payment for the booking. |
FormOfPaymentType |
The type of the form of payment. |
TicketMailingAddress |
The mailing address for the booked ticket, if available. |
TicketPickupLocation |
The pickup location for the booked ticket, if available. |
TicketPickupNumber |
The confirmation number to pick up the booked ticket, if available. |
AirfareQuotes |
List of stored airfare quotes for this booking. |
AirlineTickets |
List of Airline Tickets for this booking. |
Charges |
List of Charges for this booking. |
MiscChargeOrders |
List of Miscellaneous AirCharges for this booking. |
Passengers |
The Passengers element contains a Passenger child element for each booked passenger. The description of each child element can be seen in a subsequent table. |
PassPrograms |
List of Pass Programs for this booking. |
PhoneNumbers |
List of Phone numbers associated with this booking. |
RailPayments |
List of Rail payments associated with rail segments in this booking. |
Segments |
List of Segments in this booking. This parent element contains one or more Air , Car , Hotel , Dining , Ride , Rail , Parking , or Event parent elements for the booking. Refer to Booking Object Elements for more information about the child elements contained in the booking elements. |
Delivery |
The method this booking was delivered. |
WaitListSegments |
The segments that the traveler is waitlisted for this booking. |
Warnings |
The warnings associated with the booking. |
WebAddresses |
List of web addresses such as emails, pickup URLs, etc. associated with this bookings |
| Required Element | Description |
|---|---|
NameFirst |
The first name of the passenger. |
NameLast |
The last name of the passenger. |
| Optional Element | Description |
|---|---|
NameMiddle |
The middle name of the passenger. |
NamePrefix |
The name prefix of the passenger. |
NameRemark |
Additional details about the passenger’s name. |
NameSuffix |
The name suffix of the passenger. |
NameTitle |
The title of the passenger. |
TextName |
The user’s full name as entered in the booking tool if different from the name in the database. |
FrequentTravelerProgram |
Passenger’s loyalty programs |
This function returns the full trip details, as documented in the Response of the Get Itinerary Details function.
If the end user updates an existing reservation which results in a new confirmation number, the old booking must be explicitly cancelled in addition to posting the new booking to SAP Concur. If the previous booking is not cancelled, the user will see both bookings in their SAP Concur trip list.
 By default, the OAuth consumer should be the owner of the booking. This endpoint can also be used to cancel bookings that the OAuth consumer does not own. This is most often done when a Travel Management Company needs to cancel bookings on behalf of a user. The TMC must be registered with SAP Concur and have a SAP Concur account that has one of the following user roles: Web Services Administrator for Professional, or Can Administer for Standard.
NOTE:
Example:
https://{baseUri}/api/travel/booking/v1.1/cancel?bookingSource={Supplier}&confirmationNumber={confnum}
POST /api/travel/booking/v1.1/cancel?bookingSource={FastTravel}&confirmationNumber={098765431} HTTPS/1.1
Host: www.concursolutions.com
Authorization: OAuth {access token}
The cancel keyword and the unique identifier for the supplier, configured by SAP Concur during the application review. The bookingSource must match the Supplier Name associated with the booking.
The confirmation number for the booking to cancel.
Example:
https://www.concursolutions.com/api/travel/booking/v1.1/cancel?bookingSource={Supplier}&confirmationNumber={confnum}
The SAP Concur login ID of the user who owns the booking. Only provided when the booking owner is not the OAuth consumer. Can only be used when the OAuth consumer has the required user role.
Example:
https://www.concursolutions.com/api/travel/booking/v1.1/cancel?bookingSource={Supplier}&confirmationNumber={confnum}&userid_type=login_id&userid_value={loginID}
application/xml
The authorization header must have an OAuth token for valid SAP Concur user. The OAuth consumer must be registered as a Supplier or TMC with SAP Concur, and must have one of the following user roles in SAP Concur: Company Administrator or Web Services Administrator for Professional, or Can Administer for Standard.
This function returns the full booking details, as specified in the Booking Object Elements section.
If the booking is not found, the function returns a HTTP 404 error and the following element:
Status: This element contains the value: NotFound.
POST /api/travel/booking/v1.1/cancel?bookingSource={FastTravel}&confirmationNumber={098765431} HTTPS/1.1
Host: www.concursolutions.com
Authorization: OAuth {access token}
<Car>
<Vendor>ZE</Vendor>
<Status>HK</Status>
<StartDateLocal>2013-12-21T12:00:00</StartDateLocal>
<EndDateLocal>2013-12-24T12:00:00</EndDateLocal>
<TimeZoneId xsi:nil="true"/>
<StartDateUtc>2013-12-21T20:00:00</StartDateUtc>
<EndDateUtc>2013-12-24T20:00:00</EndDateUtc>
<ConfirmationNumber>0987654321</ConfirmationNumber>
<CancellationNumber>1029384756</CancellationNumber>
<DateCreatedUtc>2012-07-22T11:55:42</DateCreatedUtc>
<DateCancelledUtc>2012-07-25T14:21:35</DateCancelledUtc>
<DateModifiedUtc>2012-07-22T11:55:42</DateModifiedUtc>
<UpgradedDateTime xsi:nil="true"/>
<IsUpgradeAllowed xsi:nil="true"/>
<FrequentTravelerId/>
<StartCityCode>SEA</StartCityCode>
<EndCityCode>SEA</EndCityCode>
<StartLocation>SEA</StartLocation>
<EndLocation>SEA</EndLocation>
<Class>E</Class>
<Body>C</Body>
<Transmission>M</Transmission>
<AirCondition>R</AirCondition>
<PhoneNumber/>
<NumPersons xsi:nil="true"/>
<NumCars>1</NumCars>
<DiscountCode>346660</DiscountCode>
<Charges>
<Fixed>
<Description>Dropoff Fee</Description>
<Currency>USD</Currency>
<Amount>0.0000</Amount>
<StartDateLocal xsi:nil="true"/>
<IsPaid xsi:nil="true"/>
<SemanticsCode>DROPOFFFEE</SemanticsCode>
<SemanticsVendorType>C</SemanticsVendorType>
</Fixed>
<RateWithAllowance>
<Currency>USD</Currency>
<Amount>44.0000</Amount>
<StartDateLocal>2013-12-21T12:00:00</StartDateLocal>
<IsPaid xsi:nil="true"/>
<SemanticsCode>DAYS</SemanticsCode>
<SemanticsVendorType>C</SemanticsVendorType>
<PerUnit>DAY</PerUnit>
<NumUnits>1.0000</NumUnits>
<AllowanceUnit/>
<AllowanceNumUnits>250.0000</AllowanceNumUnits>
<AllowanceAmount>0.2400</AllowanceAmount>
<AllowanceIsUnlimited>false</AllowanceIsUnlimited>
</RateWithAllowance>
</Charges>
<Remarks/>
<PerDiemLocation/>
</Car>


Thanks for downloading our app! Before you decide it is important for you to understand why the activity is being done and what it will involve. Please take time to read the following information carefully. Take time to decide whether or not you wish to take part. Thank you for reading this!
What is the project’s purpose?
The project supports the tackling a huge global social problem - physical inactivity. This is one of the most important contributors to poor health and wellbeing from cradle to grave. Being physically active also supports creation of wealth for individuals, businesses and populations. But accurate measurement of physical activity levels is difficult, and self-reported data is very unreliable and hugely over estimates real levels, reducing motivation for behavioural change.
We have developed a smart phone app able to generate an objective measurement of activity, educate people about their activity levels and achieve large-scale behavioural change. The app is composed of a mobile app tracking the individual and a server side program performing data cleaning and visualisation.
Our app is designed to support people in adopting a healthier lifestyle. It is designed to be fun and to generate a sense of city cohesion. It is also distributed for free. The app tracks the activity of a person (still, walking, running, cycling, etc.), the associated timing (e.g. you walked for 20 minutes starting from 12:23 on 20.12.2015) and location. The app enables users to monitor their personal lifestyle, including through the provision of directed and customised messages.
Aggregated and anonymysed data will be used for studies both in terms of social health and mobility as well as in terms of advancing the field of computer science/wellbeing/mobility. The location associated to the activity will also enable to understand how different parts of the city (and hence social strata) react to health messages via MoveMore or other sources (e.g. government or city council). Similarly it will enable understanding mobility patterns over time (how people move and in what ways) and hence to evaluate the impact of mobility measures (e.g. a change in parking regulations) in terms of impact on the health of the population.
The activity is carried out in collaboration with Sheffield’s Move More initiative http://www.movemoresheffield.com/
Do I have to take part?
It is up to you to decide whether or not to take part. If you do decide to take part you will be allowed to keep the app running. You can still withdraw at any time and all your data is destroyed (using the appropriate functionality provided by the app and or the website) and by deleting the app from your phone.
What will happen to me if I take part?
Your phone will collect data about your physical activity and will store the collected data both on your phone and our servers.
What are the possible disadvantages and risks of taking part?
No possible disadvantages or risks are envisaged.
What are the possible benefits of taking part?
The tracking of your physical activity will allow you to monitor how much you move. The app will also enable to access suggestions on how to obtain a healthier lifestyle. It also enables to participate in the MoveMore initiatives that regularly involve thousands of people in the City.
What if something goes wrong?
If the app does not work, read the FAQs on our website. In case of emergency remove the app from your phone and reinstall it.
Will my taking part be kept confidential?
All the information that we collect about you during the course of the research will be kept strictly confidential. You will not identifiable in any report or publication.
What will happen to the data?
Apart from the services to you to improve your own lifestyle, the outcome of any study done on the aggregated and anonymysed data will form part of one or more scientific publications and will inform research and policies related to health and wellbeing, mobility, computer science, and related fields. You will not be identified in any report or publication.
The data collected will be retained for analysis, and may be used to inform public policy or to provide information to selected parties.
Who is organising and funding the research?
This research is supported by The University of Sheffield.
Who has ethically reviewed the project?
This project has been ethically approved via the Computer Science department’s ethics review procedure. The University’s Research Ethics Committee monitors the application and delivery of the University’s Ethics Review Procedure across the University.
Contact for further information
Prof Fabio Ciravegna
Organisations, Information and Knowledge Research Group,
Department of Computer Science, University of Sheffield
211 Portobello, Sheffield S1 4DP
tel:+44(0)114-22.21940
f.ciravegna@sheffield.ac.uk


Preparation time
over 2 hours
Cooking time
30 mins to 1 hour
Serves
Serves 8-10
Dietary
This light, and slightly boozy dessert is the perfect way to finish a heavy meal. The apple caramel adds a sweetness to an otherwise sharp, refreshing dish.
Bring 120ml/4fl oz water and the caster sugar to the boil. Once the sugar has dissolved, remove from the heat. Add the gin, tonic, lemon juice and the grated Bramley apple. Set aside to cool completely, then pour the mixture into a plastic freezer-proof container and place in the freezer.
Every 30 minutes, remove from the freezer and whisk. Repeat this until frozen (this will take about 3-4 hours).
To make an apple caramel, heat the apple juice until reduced in volume to a thick caramel (this will take approximately 45 minutes). Remove from the heat and whisk in the butter. Leave to cool.
To serve, remove the granita from the freezer and break up with a fork to create a ‘slush puppy’ texture. Sprinkle the diced Braeburn apple on top and serve with the apple caramel.


Pokédex number: {{currentPokemonId}}
Type: {{theHint}}
1">{{numberOfWrongs}} wrong guesses
{{numberOfWrongs}} wrong guess
You can see the answer or guess again
PokeStréak Counter!
{{numberOfRights}} time right!
1">{{numberOfRights}} times right!
There is a {{theError.status}} error
{{errorMessage}}


This email is to confirm that we have received your request for a Carpentries
Workshop! Someone will be in contact with you soon. Below you will find a few important notes:
- Organising a workshop requires a minimum of 2 months. If you are requesting a workshop less than 2 months, we cannot guarantee that instructors will be placed by your requested date. We will do our very best to meet your request. If we are not able to meet your request, we do ask that you consider flexible dates.
- There are certain criteria we use when selecting instructors. We pair experienced instructors with newly certified instructors. We ensure that all of our instructors are given an equal opportunity to teach.
- Here are resources that will help you prepare for your online workshop: resources for online workshops.
- Please be advised that a workshop will not be scheduled until it has been confirmed by both the host and The Carpentries Workshop Administrator. Our workshops are organised based on the order the Workshop Request Form is received and finalized.
We look forward to working with you and ensuring you have a great workshop!
The Carpentries
A copy of your request is included below for your reference.
{% if object.preferred_dates_too_soon %}
Warning: selected preferred dates for the workshop fall
in upcoming two months. The Carpentries team may not be able to find
instructors in such short time.
{% endif %}
{% include "includes/workshoprequest_details.html" with admin=False object=object %}


Plant Selection
Greenhouse
Plant Care
Plan
r
About Us
Weekly Watering Schedule
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
Sunday


Go is a tool for managing Go source code.
Usage:
go command [arguments]
The commands are:
build compile packages and dependencies clean remove object files and cached files doc show documentation for package or symbol env print Go environment information bug start a bug report fix update packages to use new APIs fmt gofmt (reformat) package sources generate generate Go files by processing source get download and install packages and dependencies install compile and install packages and dependencies list list packages run compile and run Go program test test packages tool run specified go tool version print Go version vet report likely mistakes in packages
Use "go help [command]" for more information about a command.
Additional help topics:
c calling between Go and C buildmode build modes cache build and test caching filetype file types gopath GOPATH environment variable environment environment variables importpath import path syntax packages package lists testflag testing flags testfunc testing functions
Use "go help [topic]" for more information about that topic.
Usage:
go build [-o output] [-i] [build flags] [packages]
Build compiles the packages named by the import paths, along with their dependencies, but it does not install the results.
If the arguments to build are a list of .go files, build treats them as a list of source files specifying a single package.
When compiling a single main package, build writes the resulting executable to an output file named after the first source file ('go build ed.go rx.go' writes 'ed' or 'ed.exe') or the source code directory ('go build unix/sam' writes 'sam' or 'sam.exe'). The '.exe' suffix is added when writing a Windows executable.
When compiling multiple packages or a single non-main package, build compiles the packages but discards the resulting object, serving only as a check that the packages can be built.
When compiling packages, build ignores files that end in '_test.go'.
The -o flag, only allowed when compiling a single package, forces build to write the resulting executable or object to the named output file, instead of the default behavior described in the last two paragraphs.
The -i flag installs the packages that are dependencies of the target.
The build flags are shared by the build, clean, get, install, list, run, and test commands:
-a force rebuilding of packages that are already up-to-date. -n print the commands but do not run them. -p n the number of programs, such as build commands or test binaries, that can be run in parallel. The default is the number of CPUs available. -race enable data race detection. Supported only on linux/amd64, freebsd/amd64, darwin/amd64 and windows/amd64. -msan enable interoperation with memory sanitizer. Supported only on linux/amd64, and only with Clang/LLVM as the host C compiler. -v print the names of packages as they are compiled. -work print the name of the temporary work directory and do not delete it when exiting. -x print the commands. -asmflags '[pattern=]arg list' arguments to pass on each go tool asm invocation. -buildmode mode build mode to use. See 'go help buildmode' for more. -compiler name name of compiler to use, as in runtime.Compiler (gccgo or gc). -gccgoflags '[pattern=]arg list' arguments to pass on each gccgo compiler/linker invocation. -gcflags '[pattern=]arg list' arguments to pass on each go tool compile invocation. -installsuffix suffix a suffix to use in the name of the package installation directory, in order to keep output separate from default builds. If using the -race flag, the install suffix is automatically set to race or, if set explicitly, has _race appended to it. Likewise for the -msan flag. Using a -buildmode option that requires non-default compile flags has a similar effect. -ldflags '[pattern=]arg list' arguments to pass on each go tool link invocation. -linkshared link against shared libraries previously created with -buildmode=shared. -pkgdir dir install and load all packages from dir instead of the usual locations. For example, when building with a non-standard configuration, use -pkgdir to keep generated packages in a separate location. -tags 'tag list' a space-separated list of build tags to consider satisfied during the build. For more information about build tags, see the description of build constraints in the documentation for the go/build package. -toolexec 'cmd args' a program to use to invoke toolchain programs like vet and asm. For example, instead of running asm, the go command will run 'cmd args /path/to/asm <arguments for asm>'.
The -asmflags, -gccgoflags, -gcflags, and -ldflags flags accept a space-separated list of arguments to pass to an underlying tool during the build. To embed spaces in an element in the list, surround it with either single or double quotes. The argument list may be preceded by a package pattern and an equal sign, which restricts the use of that argument list to the building of packages matching that pattern (see 'go help packages' for a description of package patterns). Without a pattern, the argument list applies only to the packages named on the command line. The flags may be repeated with different patterns in order to specify different arguments for different sets of packages. If a package matches patterns given in multiple flags, the latest match on the command line wins. For example, 'go build -gcflags=-S fmt' prints the disassembly only for package fmt, while 'go build -gcflags=all=-S fmt' prints the disassembly for fmt and all its dependencies.
For more about specifying packages, see 'go help packages'. For more about where packages and binaries are installed, run 'go help gopath'. For more about calling between Go and C/C++, run 'go help c'.
Note: Build adheres to certain conventions such as those described by 'go help gopath'. Not all projects can follow these conventions, however. Installations that have their own conventions or that use a separate software build system may choose to use lower-level invocations such as 'go tool compile' and 'go tool link' to avoid some of the overheads and design decisions of the build tool.
See also: go install, go get, go clean.
Usage:
go clean [-i] [-r] [-n] [-x] [-cache] [-testcache] [build flags] [packages]
Clean removes object files from package source directories. The go command builds most objects in a temporary directory, so go clean is mainly concerned with object files left by other tools or by manual invocations of go build.
Specifically, clean removes the following files from each of the source directories corresponding to the import paths:
_obj/ old object directory, left from Makefiles _test/ old test directory, left from Makefiles _testmain.go old gotest file, left from Makefiles test.out old test log, left from Makefiles build.out old test log, left from Makefiles *.[568ao] object files, left from Makefiles DIR(.exe) from go build DIR.test(.exe) from go test -c MAINFILE(.exe) from go build MAINFILE.go *.so from SWIG
In the list, DIR represents the final path element of the directory, and MAINFILE is the base name of any Go source file in the directory that is not included when building the package.
The -i flag causes clean to remove the corresponding installed archive or binary (what 'go install' would create).
The -n flag causes clean to print the remove commands it would execute, but not run them.
The -r flag causes clean to be applied recursively to all the dependencies of the packages named by the import paths.
The -x flag causes clean to print remove commands as it executes them.
The -cache flag causes clean to remove the entire go build cache.
The -testcache flag causes clean to expire all test results in the go build cache.
For more about build flags, see 'go help build'.
For more about specifying packages, see 'go help packages'.
Usage:
go doc [-u] [-c] [package|[package.]symbol[.methodOrField]]
Doc prints the documentation comments associated with the item identified by its arguments (a package, const, func, type, var, method, or struct field) followed by a one-line summary of each of the first-level items "under" that item (package-level declarations for a package, methods for a type, etc.).
Doc accepts zero, one, or two arguments.
Given no arguments, that is, when run as
go doc
it prints the package documentation for the package in the current directory. If the package is a command (package main), the exported symbols of the package are elided from the presentation unless the -cmd flag is provided.
When run with one argument, the argument is treated as a Go-syntax-like representation of the item to be documented. What the argument selects depends on what is installed in GOROOT and GOPATH, as well as the form of the argument, which is schematically one of these:
go doc <pkg> go doc <sym>[.<methodOrField>] go doc [<pkg>.]<sym>[.<methodOrField>] go doc [<pkg>.][<sym>.]<methodOrField>
The first item in this list matched by the argument is the one whose documentation is printed. (See the examples below.) However, if the argument starts with a capital letter it is assumed to identify a symbol or method in the current directory.
For packages, the order of scanning is determined lexically in breadth-first order. That is, the package presented is the one that matches the search and is nearest the root and lexically first at its level of the hierarchy. The GOROOT tree is always scanned in its entirety before GOPATH.
If there is no package specified or matched, the package in the current directory is selected, so "go doc Foo" shows the documentation for symbol Foo in the current package.
The package path must be either a qualified path or a proper suffix of a path. The go tool's usual package mechanism does not apply: package path elements like . and ... are not implemented by go doc.
When run with two arguments, the first must be a full package path (not just a suffix), and the second is a symbol, or symbol with method or struct field. This is similar to the syntax accepted by godoc:
go doc <pkg> <sym>[.<methodOrField>]
In all forms, when matching symbols, lower-case letters in the argument match either case but upper-case letters match exactly. This means that there may be multiple matches of a lower-case argument in a package if different symbols have different cases. If this occurs, documentation for all matches is printed.
Examples:
go doc Show documentation for current package. go doc Foo Show documentation for Foo in the current package. (Foo starts with a capital letter so it cannot match a package path.) go doc encoding/json Show documentation for the encoding/json package. go doc json Shorthand for encoding/json. go doc json.Number (or go doc json.number) Show documentation and method summary for json.Number. go doc json.Number.Int64 (or go doc json.number.int64) Show documentation for json.Number's Int64 method. go doc cmd/doc Show package docs for the doc command. go doc -cmd cmd/doc Show package docs and exported symbols within the doc command. go doc template.new Show documentation for html/template's New function. (html/template is lexically before text/template) go doc text/template.new # One argument Show documentation for text/template's New function. go doc text/template new # Two arguments Show documentation for text/template's New function.  Otherwise package main's exported symbols are hidden when showing the package's top-level documentation. -u Show documentation for unexported as well as exported symbols, methods, and fields.
Usage:
go env [-json] [var ...]
Env prints Go environment information.
By default env prints information as a shell script (on Windows, a batch file). If one or more variable names is given as arguments, env prints the value of each named variable on its own line.
The -json flag prints the environment in JSON format instead of as a shell script.
For more about environment variables, see 'go help environment'.
Usage:
go bug
Bug opens the default browser and starts a new bug report. The report includes useful system information.
Usage:
go fix [packages]
Fix runs the Go fix command on the packages named by the import paths.
For more about fix, see 'go doc cmd/fix'. For more about specifying packages, see 'go help packages'.
To run fix with specific options, run 'go tool fix'.
See also: go fmt, go vet.
Gofmt (reformat) package sources
Usage:
go fmt [-n] [-x] [packages]
Fmt runs the command 'gofmt -l -w' on the packages named by the import paths. It prints the names of the files that are modified.
For more about gofmt, see 'go doc cmd/gofmt'. For more about specifying packages, see 'go help packages'.
The -n flag prints commands that would be executed. The -x flag prints commands as they are executed.
To run gofmt with specific options, run gofmt itself.
See also: go fix, go vet.
Usage:
go generate [-run regexp] [-n] [-v] [-x] [build flags] [file.go... | packages]
Generate runs commands described by directives within existing files. Those commands can run any process but the intent is to create or update Go source files.
 It must be run explicitly.
Go generate scans the file for directives, which are lines of the form,
//go:generate command argument...
(note: no leading spaces and no space in "//go") where command is the generator to be run, corresponding to an executable file that can be run locally. It must either be in the shell path (gofmt), a fully qualified path (/usr/you/bin/mytool), or a command alias, described below.
Note that go generate does not parse the file, so lines that look like directives in comments or multiline strings will be treated as directives.
The arguments to the directive are space-separated tokens or double-quoted strings passed to the generator as individual arguments when it is run.
Quoted strings use Go syntax and are evaluated before execution; a quoted string appears as a single argument to the generator.
Go generate sets several variables when it runs the generator:
$GOARCH The execution architecture (arm, amd64, etc.) $GOOS The execution operating system (linux, windows, etc.) $GOFILE The base name of the file. $GOLINE The line number of the directive in the source file. $GOPACKAGE The name of the package of the file containing the directive. $DOLLAR A dollar sign.
Other than variable substitution and quoted-string evaluation, no special processing such as "globbing" is performed on the command line.
As a last step before running the command, any invocations of any environment variables with alphanumeric names, such as $GOFILE or $HOME, are expanded throughout the command line. The syntax for variable expansion is $NAME on all operating systems. Due to the order of evaluation, variables are expanded even inside quoted strings. If the variable NAME is not set, $NAME expands to the empty string.
A directive of the form,
//go:generate -command xxx args...
specifies, for the remainder of this source file only, that the string xxx represents the command identified by the arguments. This can be used to create aliases or to handle multiword generators. For example,
//go:generate -command foo go tool foo
specifies that the command "foo" represents the generator "go tool foo".
Generate processes packages in the order given on the command line, one at a time. If the command line lists .go files, they are treated as a single package. Within a package, generate processes the source files in a package in file name order, one at a time. Within a source file, generate runs generators in the order they appear in the file, one at a time.
If any generator returns an error exit status, "go generate" skips all further processing for that package.
The generator is run in the package's source directory.
Go generate accepts one specific flag:
-run="" if non-empty, specifies a regular expression to select directives whose full original source text (excluding any trailing spaces and final newline) matches the expression.
It also accepts the standard build flags including -v, -n, and -x. The -v flag prints the names of packages and files as they are processed. The -n flag prints commands that would be executed. The -x flag prints commands as they are executed.
For more about build flags, see 'go help build'.
For more about specifying packages, see 'go help packages'.
Usage:
go get [-d] [-f] [-fix] [-insecure] [-t] [-u] [-v] [build flags] [packages]
Get downloads the packages named by the import paths, along with their dependencies. It then installs the named packages, like 'go install'.
The -d flag instructs get to stop after downloading the packages; that is, it instructs get not to install the packages.
The -f flag, valid only when -u is set, forces get -u not to verify that each package has been checked out from the source control repository implied by its import path. This can be useful if the source is a local fork of the original.
The -fix flag instructs get to run the fix tool on the downloaded packages before resolving dependencies or building the code.
The -insecure flag permits fetching from repositories and resolving custom domains using insecure schemes such as HTTP. Use with caution.
The -t flag instructs get to also download the packages required to build the tests for the specified packages.
The -u flag instructs get to use the network to update the named packages and their dependencies. By default, get uses the network to check out missing packages but does not use it to look for updates to existing packages.
The -v flag enables verbose progress and debug output.
Get also accepts build flags to control the installation. See 'go help build'.
When checking out a new package, get creates the target directory GOPATH/src/<import-path>. If the GOPATH contains multiple entries, get uses the first one. For more details see: 'go help gopath'.
When checking out or updating a package, get looks for a branch or tag that matches the locally installed version of Go. The most important rule is that if the local installation is running version "go1", get searches for a branch or tag named "go1". If no such version exists it retrieves the default branch of the package.
When go get checks out or updates a Git repository, it also updates any git submodules referenced by the repository.
Get never checks out or updates code stored in vendor directories.
For more about specifying packages, see 'go help packages'.
For more about how 'go get' finds source code to download, see 'go help importpath'.
See also: go build, go install, go clean.
Usage:
go install [-i] [build flags] [packages]
Install compiles and installs the packages named by the import paths.
The -i flag installs the dependencies of the named packages as well.
For more about the build flags, see 'go help build'. For more about specifying packages, see 'go help packages'.
See also: go build, go get, go clean.
Usage:
go list [-e] [-f format] [-json] [build flags] [packages]
List lists the packages named by the import paths, one per line.
The default output shows the package import path:
bytes encoding/json github.com/gorilla/mux golang.org/x/net/html
The -f flag specifies an alternate format for the list, using the syntax of package template. The default output is equivalent to -f '{{.ImportPath}}'. The struct being passed to the template is:
type Package struct { Dir string // directory containing package sources ImportPath string // import path of package in dir ImportComment string // path in import comment on package statement Name string // package name Doc string // package documentation string Target string // install path Shlib string // the shared library that contains this package (only set when -linkshared) Goroot bool // is this package in the Go root? Standard bool // is this package part of the standard Go library? Stale bool // would 'go install' do anything for this package? StaleReason string // explanation for Stale==true Root string // Go root or Go path dir containing this package ConflictDir string // this directory shadows Dir in $GOPATH BinaryOnly bool // binary-only package: cannot be recompiled from sources // Source files GoFiles []string // .go source files (excluding CgoFiles, TestGoFiles, XTestGoFiles) CgoFiles []string // .go sources files that import "C" IgnoredGoFiles []string // .go sources ignored due to build constraints CFiles []string // .c source files CXXFiles []string // .cc, .cxx and .cpp source files MFiles []string // .m source files HFiles []string // .h, .hh, .hpp and .hxx source files FFiles []string // .f, .F, .for and .f90 Fortran source files SFiles []string // .s source files SwigFiles []string // .swig files SwigCXXFiles []string // .swigcxx files SysoFiles []string // .syso object files to add to archive TestGoFiles []string // _test.go files in package XTestGoFiles []string // _test.go files outside package // Cgo directives CgoCFLAGS []string // cgo: flags for C compiler CgoCPPFLAGS []string // cgo: flags for C preprocessor CgoCXXFLAGS []string // cgo: flags for C++ compiler CgoFFLAGS []string // cgo: flags for Fortran compiler CgoLDFLAGS []string // cgo: flags for linker CgoPkgConfig []string // cgo: pkg-config names // Dependency information Imports []string // import paths used by this package Deps []string // all (recursively) imported dependencies TestImports []string // imports from TestGoFiles XTestImports []string // imports from XTestGoFiles // Error information Incomplete bool // this package or a dependency has an error Error *PackageError // error loading package DepsErrors []*PackageError // errors loading dependencies }
Packages stored in vendor directories report an ImportPath that includes the path to the vendor directory (for example, "d/vendor/p" instead of "p"), so that the ImportPath uniquely identifies a given copy of a package. The Imports, Deps, TestImports, and XTestImports lists also contain these expanded imports paths. See golang.org/s/go15vendor for more about vendoring.
The error information, if any, is
type PackageError struct { ImportStack []string // shortest path from package named on command line to this one Pos string // position of error (if present, file:line:col) Err string // the error itself }
The template function "join" calls strings.Join.
The template function "context" returns the build context, defined as:
type Context struct { GOARCH string // target architecture GOOS string // target operating system GOROOT string // Go root GOPATH string // Go path CgoEnabled bool // whether cgo can be used UseAllFiles bool // use files regardless of +build lines, file names Compiler string // compiler to assume when computing target paths BuildTags []string // build constraints to match in +build lines ReleaseTags []string // releases the current release is compatible with InstallSuffix string // suffix to use in the name of the install dir }
For more information about the meaning of these fields see the documentation for the go/build package's Context type.
The -json flag causes the package data to be printed in JSON format instead of using the template format.
The -e flag changes the handling of erroneous packages, those that cannot be found or are malformed. By default, the list command prints an error to standard error for each erroneous package and omits the packages from consideration during the usual printing. With the -e flag, the list command never prints errors to standard error and instead processes the erroneous packages with the usual printing. Erroneous packages will have a non-empty ImportPath and a non-nil Error field; other information may or may not be missing (zeroed).
For more about build flags, see 'go help build'.
For more about specifying packages, see 'go help packages'.
Usage:
go run [build flags] [-exec xprog] gofiles... [arguments...]
Run compiles and runs the main package comprising the named Go source files.
By default, 'go run' runs the compiled binary directly: 'a.out arguments...'. If the -exec flag is given, 'go run' invokes the binary using xprog:
'xprog a.out arguments...'.
If the -exec flag is not given, GOOS or GOARCH is different from the system default, and a program named go_$GOOS_$GOARCH_exec can be found on the current search path, 'go run' invokes the binary using that program, for example 'go_nacl_386_exec a.out arguments...'. This allows execution of cross-compiled programs when a simulator or other execution method is available.
For more about build flags, see 'go help build'.
See also: go build.
Usage:
go test [build/test flags] [packages] [build/test flags & test binary flags]
'Go test' automates testing the packages named by the import paths. It prints a summary of the test results in the format:
ok archive/tar 0.011s FAIL archive/zip 0.022s ok compress/gzip 0.033s ...
followed by detailed output for each failed package.
'Go test' recompiles each package along with any files with names matching the file pattern "*_test.go". These additional files can contain test functions, benchmark functions, and example functions. See 'go help testfunc' for more. Each listed package causes the execution of a separate test binary. Files whose names begin with "_" (including "_test.go") or "." are ignored.
Test files that declare a package with the suffix "_test" will be compiled as a separate package, and then linked and run with the main test binary.
The go tool will ignore a directory named "testdata", making it available to hold ancillary data needed by the tests.
As part of building a test binary, go test runs go vet on the package and its test source files to identify significant problems. If go vet finds any problems, go test reports those and does not run the test binary. Only a high-confidence subset of the default go vet checks are used. To disable the running of go vet, use the -vet=off flag.
All test output and summary lines are printed to the go command's standard output, even if the test printed them to its own standard error. (The go command's standard error is reserved for printing errors building the tests.)
Go test runs in two different modes:
The first, called local directory mode, occurs when go test is invoked with no package arguments (for example, 'go test' or 'go test -v'). In this mode, go test compiles the package sources and tests found in the current directory and then runs the resulting test binary. In this mode, caching (discussed below) is disabled. After the package test finishes, go test prints a summary line showing the test status ('ok' or 'FAIL'), package name, and elapsed time.
The second, called package list mode, occurs when go test is invoked with explicit package arguments (for example 'go test math', 'go test ./...', and even 'go test .'). In this mode, go test compiles and tests each of the packages listed on the command line. If a package test passes, go test prints only the final 'ok' summary line. If a package test fails, go test prints the full test output. If invoked with the -bench or -v flag, go test prints the full output even for passing package tests, in order to display the requested benchmark results or verbose logging.
In package list mode only, go test caches successful package test results to avoid unnecessary repeated running of tests. When the result of a test can be recovered from the cache, go test will redisplay the previous output instead of running the test binary again. When this happens, go test prints '(cached)' in place of the elapsed time in the summary line.
The rule for a match in the cache is that the run involves the same test binary and the flags on the command line come entirely from a restricted set of 'cacheable' test flags, defined as -cpu, -list, -parallel, -run, -short, and -v. If a run of go test has any test or non-test flags outside this set, the result is not cached. To disable test caching, use any test flag or argument other than the cacheable flags. The idiomatic way to disable test caching explicitly is to use -count=1. Tests that open files within the package's source root (usually $GOPATH) or that consult environment variables only match future runs in which the files and environment variables are unchanged. A cached test result is treated as executing in no time at all, so a successful package test result will be cached and reused regardless of -timeout setting.
In addition to the build flags, the flags handled by 'go test' itself are:
-args Pass the remainder of the command line (everything after -args) to the test binary, uninterpreted and unchanged. Because this flag consumes the remainder of the command line, the package list (if present) must appear before this flag. -c Compile the test binary to pkg.test but do not run it (where pkg is the last element of the package's import path). The file name can be changed with the -o flag. -exec xprog Run the test binary using xprog. The behavior is the same as in 'go run'. See 'go help run' for details. -i Install packages that are dependencies of the test. Do not run the test. -json Convert test output to JSON suitable for automated processing. See 'go doc test2json' for the encoding details. -o file Compile the test binary to the named file. The test still runs (unless -c or -i is specified).
The test binary also accepts flags that control execution of the test; these flags are also accessible by 'go test'. See 'go help testflag' for details.
For more about build flags, see 'go help build'. For more about specifying packages, see 'go help packages'.
See also: go build, go vet.
Usage:
go tool [-n] command [args...]
Tool runs the go tool command identified by the arguments. With no arguments it prints the list of known tools.
The -n flag causes tool to print the command that would be executed but not execute it.
For more about each tool command, see 'go doc cmd/<command>'.
Usage:
go version
Version prints the Go version, as reported by runtime.Version.
Usage:
go vet [-n] [-x] [build flags] [vet flags] [packages]
Vet runs the Go vet command on the packages named by the import paths.
For more about vet and its flags, see 'go doc cmd/vet'. For more about specifying packages, see 'go help packages'.
The -n flag prints commands that would be executed. The -x flag prints commands as they are executed.
The build flags supported by go vet are those that control package resolution and execution, such as -n, -x, -v, -tags, and -toolexec. For more about these flags, see 'go help build'.
See also: go fmt, go fix.
There are two different ways to call between Go and C/C++ code.
The first is the cgo tool, which is part of the Go distribution. For information on how to use it see the cgo documentation (go doc cmd/cgo).
The second is the SWIG program, which is a general tool for interfacing between languages. For information on SWIG see http://swig.org/. When running go build, any file with a .swig extension will be passed to SWIG. Any file with a .swigcxx extension will be passed to SWIG with the -c++ option.
When either cgo or SWIG is used, go build will pass any .c, .m, .s, or .S files to the C compiler, and any .cc, .cpp, .cxx files to the C++ compiler. The CC or CXX environment variables may be set to determine the C or C++ compiler, respectively, to use.
The 'go build' and 'go install' commands take a -buildmode argument which indicates which kind of object file is to be built. Currently supported values are:
-buildmode=archive Build the listed non-main packages into .a files. Packages named main are ignored. -buildmode=c-archive Build the listed main package, plus all packages it imports, into a C archive file. The only callable symbols will be those functions exported using a cgo //export comment. Requires exactly one main package to be listed. -buildmode=c-shared Build the listed main package, plus all packages it imports, into a C shared library. The only callable symbols will be those functions exported using a cgo //export comment. Requires exactly one main package to be listed. -buildmode=default Listed main packages are built into executables and listed non-main packages are built into .a files (the default behavior). -buildmode=shared Combine all the listed non-main packages into a single shared library that will be used when building with the -linkshared option. Packages named main are ignored. -buildmode=exe Build the listed main packages and everything they import into executables. Packages not named main are ignored. -buildmode=pie Build the listed main packages and everything they import into position independent executables (PIE). Packages not named main are ignored. -buildmode=plugin Build the listed main packages, plus all packages that they import, into a Go plugin. Packages not named main are ignored.
The go command caches build outputs for reuse in future builds. The default location for cache data is a subdirectory named go-build in the standard user cache directory for the current operating system. Setting the GOCACHE environment variable overrides this default, and running 'go env GOCACHE' prints the current cache directory.
The go command periodically deletes cached data that has not been used recently. Running 'go clean -cache' deletes all cached data.
The build cache correctly accounts for changes to Go source files, compilers, compiler options, and so on: cleaning the cache explicitly should not be necessary in typical use. However, the build cache does not detect changes to C libraries imported with cgo. If you have made changes to the C libraries on your system, you will need to clean the cache explicitly or else use the -a build flag (see 'go help build') to force rebuilding of packages that depend on the updated C libraries.
The go command also caches successful package test results. See 'go help test' for details. Running 'go clean -testcache' removes all cached test results (but not cached build results).
The GODEBUG environment variable can enable printing of debugging information about the state of the cache:
GODEBUG=gocacheverify=1 causes the go command to bypass the use of any cache entries and instead rebuild everything and check that the results match existing cache entries.
GODEBUG=gocachehash=1 causes the go command to print the inputs for all of the content hashes it uses to construct cache lookup keys. The output is voluminous but can be useful for debugging the cache.
GODEBUG=gocachetest=1 causes the go command to print details of its decisions about whether to reuse a cached test result.
The go command examines the contents of a restricted set of files in each directory. It identifies which files to examine based on the extension of the file name. These extensions are:
.go Go source files. .c, .h C source files. If the package uses cgo or SWIG, these will be compiled with the OS-native compiler (typically gcc); otherwise they will trigger an error. .cc, .cpp, .cxx, .hh, .hpp, .hxx C++ source files. Only useful with cgo or SWIG, and always compiled with the OS-native compiler. .m Objective-C source files. Only useful with cgo, and always compiled with the OS-native compiler. .s, .S Assembler source files. If the package uses cgo or SWIG, these will be assembled with the OS-native assembler (typically gcc (sic)); otherwise they will be assembled with the Go assembler. .swig, .swigcxx SWIG definition files. .syso System object files.
Files of each of these types except .syso may contain build constraints, but the go command stops scanning for build constraints at the first item in the file that is not a blank line or //-style line comment. See the go/build package documentation for more details.
Non-test Go source files can also include a //go:binary-only-package comment, indicating that the package sources are included for documentation only and must not be used to build the package binary. This enables distribution of Go packages in their compiled form alone. Even binary-only packages require accurate import blocks listing required dependencies, so that those dependencies can be supplied when linking the resulting command.
The Go path is used to resolve import statements. It is implemented by and documented in the go/build package.
The GOPATH environment variable lists places to look for Go code. On Unix, the value is a colon-separated string. On Windows, the value is a semicolon-separated string. On Plan 9, the value is a list.
If the environment variable is unset, GOPATH defaults to a subdirectory named "go" in the user's home directory ($HOME/go on Unix, %USERPROFILE%\go on Windows), unless that directory holds a Go distribution. Run "go env GOPATH" to see the current GOPATH.
See https://golang.org/wiki/SettingGOPATH to set a custom GOPATH.
Each directory listed in GOPATH must have a prescribed structure:
The src directory holds source code. The path below src determines the import path or executable name.
The pkg directory holds installed package objects. As in the Go tree, each target operating system and architecture pair has its own subdirectory of pkg (pkg/GOOS_GOARCH).
If DIR is a directory listed in the GOPATH, a package with source in DIR/src/foo/bar can be imported as "foo/bar" and has its compiled form installed to "DIR/pkg/GOOS_GOARCH/foo/bar.a".
The bin directory holds compiled commands. Each command is named for its source directory, but only the final element, not the entire path. That is, the command with source in DIR/src/foo/quux is installed into DIR/bin/quux, not DIR/bin/foo/quux. The "foo/" prefix is stripped so that you can add DIR/bin to your PATH to get at the installed commands. If the GOBIN environment variable is set, commands are installed to the directory it names instead of DIR/bin. GOBIN must be an absolute path.
Here's an example directory layout:
GOPATH=/home/user/go /home/user/go/ src/ foo/ bar/ (go code in package bar) x.go quux/ (go code in package main) y.go bin/ quux (installed command) pkg/ linux_amd64/ foo/ bar.a (installed package object)
Go searches each directory listed in GOPATH to find source code, but new packages are always downloaded into the first directory in the list.
See https://golang.org/doc/code.html for an example.
Code in or below a directory named "internal" is importable only by code in the directory tree rooted at the parent of "internal". Here's an extended version of the directory layout above:
/home/user/go/ src/ crash/ bang/ (go code in package bang) b.go foo/ (go code in package foo) f.go bar/ (go code in package bar) x.go internal/ baz/ (go code in package baz) z.go quux/ (go code in package main) y.go
The code in z.go is imported as "foo/internal/baz", but that import statement can only appear in source files in the subtree rooted at foo. The source files foo/f.go, foo/bar/x.go, and foo/quux/y.go can all import "foo/internal/baz", but the source file crash/bang/b.go cannot.
See https://golang.org/s/go14internal for details.
Go 1.6 includes support for using local copies of external dependencies to satisfy imports of those dependencies, often referred to as vendoring.
Code below a directory named "vendor" is importable only by code in the directory tree rooted at the parent of "vendor", and only using an import path that omits the prefix up to and including the vendor element.
Here's the example from the previous section, but with the "internal" directory renamed to "vendor" and a new foo/vendor/crash/bang directory added:
/home/user/go/ src/ crash/ bang/ (go code in package bang) b.go foo/ (go code in package foo) f.go bar/ (go code in package bar) x.go vendor/ crash/ bang/ (go code in package bang) b.go baz/ (go code in package baz) z.go quux/ (go code in package main) y.go
The same visibility rules apply as for internal, but the code in z.go is imported as "baz", not as "foo/vendor/baz".
Code in vendor directories deeper in the source tree shadows code in higher directories. Within the subtree rooted at foo, an import of "crash/bang" resolves to "foo/vendor/crash/bang", not the top-level "crash/bang".
Code in vendor directories is not subject to import path checking (see 'go help importpath').
When 'go get' checks out or updates a git repository, it now also updates submodules.
Vendor directories do not affect the placement of new repositories being checked out for the first time by 'go get': those are always placed in the main GOPATH, never in a vendor subtree.
See https://golang.org/s/go15vendor for details.
The go command, and the tools it invokes, examine a few different environment variables. For many of these, you can see the default value of on your system by running 'go env NAME', where NAME is the name of the variable.
General-purpose environment variables:
GCCGO The gccgo command to run for 'go build -compiler=gccgo'. GOARCH The architecture, or processor, for which to compile code. Examples are amd64, 386, arm, ppc64. GOBIN The directory where 'go install' will install a command. GOOS The operating system for which to compile code. Examples are linux, darwin, windows, netbsd. GOPATH For more details see: 'go help gopath'. GORACE Options for the race detector. See https://golang.org/doc/articles/race_detector.html. GOROOT The root of the go tree. GOTMPDIR The directory where the go command will write temporary source files, packages, and binaries. GOCACHE The directory where the go command will store cached information for reuse in future builds.
Environment variables for use with cgo:
CC The command to use to compile C code. CGO_ENABLED Whether the cgo command is supported. Either 0 or 1. CGO_CFLAGS Flags that cgo will pass to the compiler when compiling C code. CGO_CFLAGS_ALLOW A regular expression specifying additional flags to allow to appear in #cgo CFLAGS source code directives. Does not apply to the CGO_CFLAGS environment variable. CGO_CFLAGS_DISALLOW A regular expression specifying flags that must be disallowed from appearing in #cgo CFLAGS source code directives. Does not apply to the CGO_CFLAGS environment variable. CGO_CPPFLAGS, CGO_CPPFLAGS_ALLOW, CGO_CPPFLAGS_DISALLOW Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW, but for the C preprocessor. CGO_CXXFLAGS, CGO_CXXFLAGS_ALLOW, CGO_CXXFLAGS_DISALLOW Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW, but for the C++ compiler. CGO_FFLAGS, CGO_FFLAGS_ALLOW, CGO_FFLAGS_DISALLOW Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW, but for the Fortran compiler. CGO_LDFLAGS, CGO_LDFLAGS_ALLOW, CGO_LDFLAGS_DISALLOW Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW, but for the linker. CXX The command to use to compile C++ code. PKG_CONFIG Path to pkg-config tool.
Architecture-specific environment variables:
GOARM For GOARCH=arm, the ARM architecture for which to compile. Valid values are 5, 6, 7. GO386 For GOARCH=386, the floating point instruction set. Valid values are 387, sse2. GOMIPS For GOARCH=mips{,le}, whether to use floating point instructions. Valid values are hardfloat (default), softfloat.
Special-purpose environment variables:
GOROOT_FINAL The root of the installed Go tree, when it is installed in a location other than where it is built. File names in stack traces are rewritten from GOROOT to GOROOT_FINAL. GO_EXTLINK_ENABLED Whether the linker should use external linking mode when using -linkmode=auto with code that uses cgo. Set to 0 to disable external linking mode, 1 to enable it. GIT_ALLOW_PROTOCOL Defined by Git. A colon-separated list of schemes that are allowed to be used with git fetch/clone. If set, any scheme not explicitly mentioned will be considered insecure by 'go get'.
An import path (see 'go help packages') denotes a package stored in the local file system. In general, an import path denotes either a standard package (such as "unicode/utf8") or a package found in one of the work spaces (For more details see: 'go help gopath').
An import path beginning with ./ or ../ is called a relative path. The toolchain supports relative import paths as a shortcut in two ways.
First, a relative path can be used as a shorthand on the command line. If you are working in the directory containing the code imported as "unicode" and want to run the tests for "unicode/utf8", you can type "go test ./utf8" instead of needing to specify the full path. Similarly, in the reverse situation, "go test .." will test "unicode" from the "unicode/utf8" directory. Relative patterns are also allowed, like "go test ./..." to test all subdirectories. See 'go help packages' for details on the pattern syntax.
Second, if you are compiling a Go program not in a work space, you can use a relative path in an import statement in that program to refer to nearby code also not in a work space. This makes it easy to experiment with small multipackage programs outside of the usual work spaces, but such programs cannot be installed with "go install" (there is no work space in which to install them), so they are rebuilt from scratch each time they are built. To avoid ambiguity, Go programs cannot use relative import paths within a work space.
Certain import paths also describe how to obtain the source code for the package using a revision control system.
A few common code hosting sites have special syntax:
Bitbucket (Git, Mercurial) import "bitbucket.org/user/project" import "bitbucket.org/user/project/sub/directory" GitHub (Git) import "github.com/user/project" import "github.com/user/project/sub/directory" Launchpad (Bazaar) import "launchpad.net/project" import "launchpad.net/project/series" import "launchpad.net/project/series/sub/directory" import "launchpad.net/~user/project/branch" import "launchpad.net/~user/project/branch/sub/directory" IBM DevOps Services (Git) import "hub.jazz.net/git/user/project" import "hub.jazz.net/git/user/project/sub/directory"
For code hosted on other servers, import paths may either be qualified with the version control type, or the go tool can dynamically fetch the import path over https/http and discover where the code resides from a <meta> tag in the HTML.
To declare the code location, an import path of the form
repository.vcs/path
specifies the given repository, with or without the .vcs suffix, using the named version control system, and then the path inside that repository. The supported version control systems are:
Bazaar .bzr Git .git Mercurial .hg Subversion .svn
For example,
import "example.org/user/foo.hg"
denotes the root directory of the Mercurial repository at example.org/user/foo or foo.hg, and
import "example.org/repo.git/foo/bar"
denotes the foo/bar directory of the Git repository at example.org/repo or repo.git.
When a version control system supports multiple protocols, each is tried in turn when downloading. For example, a Git download tries https://, then git+ssh://.
By default, downloads are restricted to known secure protocols (e.g. https, ssh). To override this setting for Git downloads, the GIT_ALLOW_PROTOCOL environment variable can be set (For more details see: 'go help environment').
If the import path is not a known code hosting site and also lacks a version control qualifier, the go tool attempts to fetch the import over https/http and looks for a <meta> tag in the document's HTML <head>.
The meta tag has the form:
<meta name="go-import" content="import-prefix vcs repo-root">
The import-prefix is the import path corresponding to the repository root. It must be a prefix or an exact match of the package being fetched with "go get". If it's not an exact match, another http request is made at the prefix to verify the <meta> tags match.
The meta tag should appear as early in the file as possible. In particular, it should appear before any raw JavaScript or CSS, to avoid confusing the go command's restricted parser.
The vcs is one of "git", "hg", "svn", etc,
The repo-root is the root of the version control system containing a scheme and not containing a .vcs qualifier.
For example,
import "example.org/pkg/foo"
will result in the following requests:
https://example.org/pkg/foo?go-get=1 (preferred) http://example.org/pkg/foo?go-get=1 (fallback, only with -insecure)
If that page contains the meta tag
<meta name="go-import" content="example.org git https://code.org/r/p/exproj">
the go tool will verify that https://example.org/?go-get=1 contains the same meta tag and then git clone https://code.org/r/p/exproj into GOPATH/src/example.org.
New downloaded packages are written to the first directory listed in the GOPATH environment variable (For more details see: 'go help gopath').
The go command attempts to download the version of the package appropriate for the Go release being used. Run 'go help get' for more.
When the custom import path feature described above redirects to a known code hosting site, each of the resulting packages has two possible import paths, using the custom domain or the known hosting site.
A package statement is said to have an "import comment" if it is immediately followed (before the next newline) by a comment of one of these two forms:
package math // import "path" package math /* import "path" */
The go command will refuse to install a package with an import comment unless it is being referred to by that import path. In this way, import comments let package authors make sure the custom import path is used and not a direct path to the underlying code hosting site.
Import path checking is disabled for code found within vendor trees. This makes it possible to copy code into alternate locations in vendor trees without needing to update import comments.
See https://golang.org/s/go14customimport for details.
Many commands apply to a set of packages:
go action [packages]
Usually, [packages] is a list of import paths.
An import path that is a rooted path or that begins with a . or .. element is interpreted as a file system path and denotes the package in that directory.
Otherwise, the import path P denotes the package found in the directory DIR/src/P for some DIR listed in the GOPATH environment variable (For more details see: 'go help gopath').
If no import paths are given, the action applies to the package in the current directory.
There are four reserved names for paths that should not be used for packages to be built with the go tool:
- "main" denotes the top-level package in a stand-alone executable.
- "all" expands to all package directories found in all the GOPATH trees. For example, 'go list all' lists all the packages on the local system.
- "std" is like all but expands to just the packages in the standard Go library.
- "cmd" expands to the Go repository's commands and their internal libraries.
Import paths beginning with "cmd/" only match source code in the Go repository.
An import path is a pattern if it includes one or more "..." wildcards, each of which can match any string, including the empty string and strings containing slashes. Such a pattern expands to all package directories found in the GOPATH trees with names matching the patterns.
To make common patterns more convenient, there are two special cases. First, /... at the end of the pattern can match an empty string, so that net/... matches both net and packages in its subdirectories, like net/http. Second, any slash-separated pattern element containing a wildcard never participates in a match of the "vendor" element in the path of a vendored package, so that ./... does not match packages in subdirectories of ./vendor or ./mycode/vendor, but ./vendor/... and ./mycode/vendor/... do. Note, however, that a directory named vendor that itself contains code is not a vendored package: cmd/vendor would be a command named vendor, and the pattern cmd/... matches it. See golang.org/s/go15vendor for more about vendoring.
An import path can also name a package to be downloaded from a remote repository. Run 'go help importpath' for details.
Every package in a program must have a unique import path. By convention, this is arranged by starting each path with a unique prefix that belongs to you. For example, paths used internally at Google all begin with 'google', and paths denoting remote repositories begin with the path to the code, such as 'github.com/user/repo'.
Packages in a program need not have unique package names, but there are two reserved package names with special meaning. The name main indicates a command, not a library. Commands are built into binaries and cannot be imported. The name documentation indicates documentation for a non-Go program in the directory. Files in package documentation are ignored by the go command.
As a special case, if the package list is a list of .go files from a single directory, the command is applied to a single synthesized package made up of exactly those files, ignoring any build constraints in those files and ignoring any other files in the directory.
Directory and file names that begin with "." or "_" are ignored by the go tool, as are directories named "testdata".
The 'go test' command takes both flags that apply to 'go test' itself and flags that apply to the resulting test binary.
Several of the flags control profiling and write an execution profile suitable for "go tool pprof"; run "go tool pprof -h" for more information. The --alloc_space, --alloc_objects, and --show_bytes options of pprof control how the information is presented.
The following flags are recognized by the 'go test' command and control the execution of any test:
-bench regexp Run only those benchmarks matching a regular expression. By default, no benchmarks are run. To run all benchmarks, use '-bench .' or '-bench=.'. The regular expression is split by unbracketed slash (/) characters into a sequence of regular expressions, and each part of a benchmark's identifier must match the corresponding element in the sequence, if any. Possible parents of matches are run with b.N=1 to identify sub-benchmarks. For example, given -bench=X/Y, top-level benchmarks matching X are run with b.N=1 to find any sub-benchmarks matching Y, which are then run in full. -benchtime t Run enough iterations of each benchmark to take t, specified as a time.Duration (for example, -benchtime 1h30s). The default is 1 second (1s). -count n Run each test and benchmark n times (default 1). If -cpu is set, run n times for each GOMAXPROCS value. Examples are always run once. -cover Enable coverage analysis. Note that because coverage works by annotating the source code before compilation, compilation and test failures with coverage enabled may report line numbers that don't correspond to the original sources. -covermode set,count,atomic Set the mode for coverage analysis for the package[s] being tested. The default is "set" unless -race is enabled, in which case it is "atomic". The values: set: bool: does this statement run? count: int: how many times does this statement run? atomic: int: count, but correct in multithreaded tests; significantly more expensive. Sets -cover. -coverpkg pattern1,pattern2,pattern3 Apply coverage analysis in each test to packages matching the patterns. The default is for each test to analyze only the package being tested. See 'go help packages' for a description of package patterns. Sets -cover. -cpu 1,2,4 Specify a list of GOMAXPROCS values for which the tests or benchmarks should be executed. The default is the current value of GOMAXPROCS. -failfast Do not start new tests after the first test failure. -list regexp List tests, benchmarks, or examples matching the regular expression. No tests, benchmarks or examples will be run. This will only list top-level tests. No subtest or subbenchmarks will be shown. -parallel n Allow parallel execution of test functions that call t.Parallel. The value of this flag is the maximum number of tests to run simultaneously; by default, it is set to the value of GOMAXPROCS. Note that -parallel only applies within a single test binary. The 'go test' command may run tests for different packages in parallel as well, according to the setting of the -p flag (see 'go help build'). -run regexp Run only those tests and examples matching the regular expression. For tests, the regular expression is split by unbracketed slash (/) characters into a sequence of regular expressions, and each part of a test's identifier must match the corresponding element in the sequence, if any. Note that possible parents of matches are run too, so that -run=X/Y matches and runs and reports the result of all tests matching X, even those without sub-tests matching Y, because it must run them to look for those sub-tests. -short Tell long-running tests to shorten their run time. It is off by default but set during all.bash so that installing the Go tree can run a sanity check but not spend time running exhaustive tests. -timeout d If a test binary runs longer than duration d, panic. If d is 0, the timeout is disabled. The default is 10 minutes (10m). -v Verbose output: log all tests as they are run. Also print all text from Log and Logf calls even if the test succeeds. -vet list Configure the invocation of "go vet" during "go test" to use the comma-separated list of vet checks. If list is empty, "go test" runs "go vet" with a curated list of checks believed to be always worth addressing. If list is "off", "go test" does not run "go vet" at all.
The following flags are also recognized by 'go test' and can be used to profile the tests during execution:
-benchmem Print memory allocation statistics for benchmarks. -blockprofile block.out Write a goroutine blocking profile to the specified file when all tests are complete. Writes test binary as -c would. -blockprofilerate n Control the detail provided in goroutine blocking profiles by calling runtime.SetBlockProfileRate with n. See 'go doc runtime.SetBlockProfileRate'. The profiler aims to sample, on average, one blocking event every n nanoseconds the program spends blocked. By default, if -test.blockprofile is set without this flag, all blocking events are recorded, equivalent to -test.blockprofilerate=1. -coverprofile cover.out Write a coverage profile to the file after all tests have passed. Sets -cover. -cpuprofile cpu.out Write a CPU profile to the specified file before exiting. Writes test binary as -c would. -memprofile mem.out Write a memory profile to the file after all tests have passed. Writes test binary as -c would. -memprofilerate n Enable more precise (and expensive) memory profiles by setting runtime.MemProfileRate. See 'go doc runtime.MemProfileRate'. To profile all memory allocations, use -test.memprofilerate=1 and pass --alloc_space flag to the pprof tool. -mutexprofile mutex.out Write a mutex contention profile to the specified file when all tests are complete. Writes test binary as -c would. -mutexprofilefraction n Sample 1 in n stack traces of goroutines holding a contended mutex. -outputdir directory Place output files from profiling in the specified directory, by default the directory in which "go test" is running. -trace trace.out Write an execution trace to the specified file before exiting.
Each of these flags is also recognized with an optional 'test.' prefix, as in -test.v. When invoking the generated test binary (the result of 'go test -c') directly, however, the prefix is mandatory.
The 'go test' command rewrites or removes recognized flags, as appropriate, both before and after the optional package list, before invoking the test binary.
For instance, the command
go test -v -myflag testdata -cpuprofile=prof.out -x
will compile the test binary and then run it as
pkg.test -test.v -myflag testdata -test.cpuprofile=prof.out
(The -x flag is removed because it applies only to the go command's execution, not to the test itself.)
The test flags that generate profiles (other than for coverage) also leave the test binary in pkg.test for use when analyzing the profiles.
When 'go test' runs a test binary, it does so from within the corresponding package's source code directory. Depending on the test, it may be necessary to do the same when invoking a generated test binary directly.
The command-line package list, if present, must appear before any flag not known to the go test command. Continuing the example above, the package list would have to appear before -myflag, but could appear on either side of -v.
To keep an argument for a test binary from being interpreted as a known flag or a package name, use -args (see 'go help test') which passes the remainder of the command line through to the test binary uninterpreted and unaltered.
For instance, the command
go test -v -args -x -v
will compile the test binary and then run it as
pkg.test -test.v -x -v
Similarly,
go test -args math
will compile the test binary and then run it as
pkg.test math
In the first example, the -x and the second -v are passed through to the test binary unchanged and with no effect on the go command itself. In the second example, the argument math is passed through to the test binary, instead of being interpreted as the package list.
The 'go test' command expects to find test, benchmark, and example functions in the "*_test.go" files corresponding to the package under test.
A test function is one named TestXxx (where Xxx does not start with a lower case letter) and should have the signature,
func TestXxx(t *testing.T) { ... }
A benchmark function is one named BenchmarkXxx and should have the signature,
func BenchmarkXxx(b *testing.B) { ... }
An example function is similar to a test function but, instead of using *testing.T to report success or failure, prints output to os.Stdout. If the last comment in the function starts with "Output:" then the output is compared exactly against the comment (see examples below). If the last comment begins with "Unordered output:" then the output is compared to the comment, however the order of the lines is ignored. An example with no such comment is compiled but not executed. An example with no text after "Output:" is compiled, executed, and expected to produce no output.
Godoc displays the body of ExampleXxx to demonstrate the use of the function, constant, or variable Xxx. An example of a method M with receiver type T or *T is named ExampleT_M. There may be multiple examples for a given function, constant, or variable, distinguished by a trailing _xxx, where xxx is a suffix not beginning with an upper case letter.
Here is an example of an example:
func ExamplePrintln() { Println("The output of\nthis example.") // Output: The output of // this example. }
Here is another example where the ordering of the output is ignored:
func ExamplePerm() { for _, value := range Perm(4) { fmt.Println(value) } // Unordered output: 4 // 2 // 1 // 3 // 0 }
The entire test file is presented as the example when it contains a single example function, at least one other function, type, variable, or constant declaration, and no test or benchmark functions.
See the documentation of the testing package for more information.
| Name | Synopsis |
|---|---|
| .. |


{% extends "registration/registration_base.html" %} {% load i18n %} {% block title %}{% trans "Registration is closed" %}{% endblock %} {% block content %}
{% trans "You do not need to register, just log in with the email address you used when purchasing your MVP/Skater/OffSkates pass." %}
{% trans "If you feel you have been overlooked or there is an error, please contact<EMAIL_ADDRESS>%}
{% endblock %}


Welcome to the Bus Mall Catalog. Come Join us as part of the future of land transportation themed shopping that money can buy.
Please help us make bus mall what you want out of a shopping catalog by completing the survey. You can reload the page after 25 iterations and see how the page changes over time.


Katana is sharp CSS Layout System made with Flexbox
Fluid
Responsive
Any Main Width
Any Gutter size
Any number of Columns
100%
50%
50%
12,5%
12,5%
Fluid
12,5%
Fluid
Fluid
25%
Fluid
Fluid
25%
25%
Fluid
Multiple Fluid column in one row.
20%
12%
Fluid
8%
Fluid
12%
Fluid
10%
Katana is ultra minimal CSS Framework made with few lines of Sass. Default parameters are: 12 columns, 15px margin and 94% main width. But you can personalise anything, just change the numbers. Plus you have ultra cool fluid column.
Made with ♥ by @vladocar. Licensed under the MIT License.


Jerry Jones’ Reaction To The Cowboys’ Loss Is Going Viral
by Andrew HolleranJerry Jones has reacted to the Dallas Cowboys’ loss to the New England Patriots on Sunday night. If Jason Garrett wasn’t worried about his job security before, he should be now.
The Cowboys fell to the Patriots, 13-9, in an ugly game at Gillette Stadium. The weather was bad and Dallas simply made too many mistakes to get the win (a terrible “tripping” penalty call didn’t help, either).
Garrett’s team dropped to 6-5 with the loss. The Cowboys are still in decent position, leading the NFC East, but there’s too much talent on this roster to be just one game above .500 late in November.
Jones knows this.
His postgame quote on the Cowboys’ loss has quickly gone viral:
“With the makeup of this team, I shouldn’t be this frustrated.”
Garrett is in the final year of his contract. It’s widely believed that the Cowboys need to make a deep postseason run (NFC Championship Game or better, probably) for the head coach to keep his job.
Jones’ postgame quote basically confirms this. The Cowboys are not currently playing up to their ability and the head coach gets the blame for that.
Garrett will need to change that moving forward or he’ll likely be looking for a new job in 2020.


|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object org.apache.oro.text.GenericPatternCache
This is the base class for all cache implementations provided in the
org.apache.oro.text package.
Although 4 subclasses of GenericPatternCache are provided with this
package, users may not derive subclasses from this class.
Rather, users should create their own implmentations of the
PatternCache
interface.
PatternCache
,
PatternCacheLRU
,
PatternCacheFIFO
,
PatternCacheFIFO2
,
PatternCacheRandom
| Field Summary | |
static int |
DEFAULT_CAPACITY
The default capacity to be used by the GenericPatternCache subclasses provided with this package. |
| Method Summary | |
Pattern |
addPattern(java.lang.String expression)
Same as calling |
Pattern |
addPattern(java.lang.String expression,
int options)
Adds a pattern to the cache and returns the compiled pattern. |
int |
capacity()
Returns the maximum number of patterns that can be cached at one time. |
Pattern |
getPattern(java.lang.String expression)
Same as calling |
Pattern |
getPattern(java.lang.String expression,
int options)
This method fetches a pattern from the cache. |
int |
size()
Returns the number of elements in the cache, not to be confused with the capacity() which returns the number
of elements that can be held in the cache at one time. |
| Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Field Detail |
public static final int DEFAULT_CAPACITY
| Method Detail |
public final Pattern addPattern(java.lang.String expression, int options) throws MalformedPatternException
getPattern()
except for the fact that
it throws a MalformedPatternException if an expression cannot be
compiled.
addPattern() is meant to be used when you expressly intend to add an expression to the cache and is useful for front-loading a cache with expressions before use. If the expression added does not already exist in the cache, it is compiled, added to the cache, and returned. If the compiled expression is already in the cache, it is simply returned.
The expected behavior of this method should be to start replacing patterns in the cache only after the cache has been filled to capacity.
addPattern
in interface PatternCache
expression
- The regular expression to add to the cache.options
- The compilation options to use when compiling the
expression.
MalformedPatternException
- If there is an error in compiling
the regular expression.public final Pattern addPattern(java.lang.String expression) throws MalformedPatternException
addPattern(expression, 0);
addPattern
in interface PatternCache
expression
- The regular expression to add to the cache.
MalformedPatternException
- If there is an error in compiling
the regular expression.public final Pattern getPattern(java.lang.String expression, int options) throws MalformedCachePatternException
addPattern()
except that it doesn't
throw a MalformedPatternException. If the pattern is not in the
cache, it is compiled, placed in the cache, and returned. If
the pattern cannot be compiled successfully, it
throws a MalformedCachePatternException.
Note that this exception is derived from RuntimeException, which means
you are NOT forced to catch it by the compiler. Please refer to
MalformedCachePatternException
for a discussion of
when you should and shouldn't catch this exception.
getPattern
in interface PatternCache
expression
- The regular expression to fetch from the cache in
compiled form.options
- The compilation options to use when compiling the
expression.
MalformedCachePatternException
- If there is an error in
compiling the regular expression.public final Pattern getPattern(java.lang.String expression) throws MalformedCachePatternException
getPattern(expression, 0)
getPattern
in interface PatternCache
expression
- The regular expression to fetch from the cache in
compiled form.
MalformedCachePatternException
- If there is an error in
compiling the regular expression.public final int size()
capacity()
which returns the number
of elements that can be held in the cache at one time.
size
in interface PatternCache
public final int capacity()
capacity
in interface PatternCache
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


Copyright (C) 2017 <>< Armin Schlegel
Copyright (C) 2015-2016 <>< Charles Lohr, See LICENSE file for more info.


To use LoadMaster ESP Login, javascript must be enabled in your browser.
Click Here
This is a public or shared computer
This is a private computer
Remote Credentials
Username:
Passcode:
Internal Credentials
Internal Username:
Internal Password:
Secured by KEMP LoadMaster
© 2002-2020 KEMP Technologies Inc. All rights reserved.


The final step to create a custom HDL core is described in this section. The result is a peripheral core (pcore) that can be inserted into a Xilinx Platform Studio (XPS) project.
Before generating the HDL core, set the intial value of the phaseInc register back to 1 embedding this value into the hardware design. The From Registers will get memory-mapped in the process of generation and we will be able to change their values by reading and writing certain address locations.
In order to create memory map, drag in the EDK Processor block from the Xilinx Library.
Double-clicking it will reveal the options window. Click Add to create the register map. This will populate the map with the list of registers found in the system. The registers can be expanded to see their address locations. Click Apply to save.
Move to the Implementation tab of the EDK Processor block. Here check Register Read-Back as shown above. Click Ok or Apply to save.
Open the System Generator block. It will reveals a whole set of options to create the design. As the model is going to be part of a Xilinx Platform Studio project, choose EDK Export Tool to the Compilation. This will create all the supporting files so it can be recognized by the Embedded Development Kit (EDK) that Xilinx provides.
The WARP Boards are Virtex-II Pro FPGA-based so select the Virtex2P -> xc2vp70 -> -6 -> ff1517. This selects the correct target as each FPGA has a different architecture inside.
Finally, click Generate to start the compilation.
The above window will pop-up once the generation is complete. At this point there is an XPS-compatible peripheral core available in the ./netlist/pcores folder. This includes the HDL for the core and associated data files that identifies the type of core, the memory-mapped locations etc.


For this project we had to to screate our own 3D printed model. I chose to print a key chain which said OHIO on it and had the Ohio Sate O under it. I enjoyed designong the key chain and seeing how much I can do with inventor. Although my key chain has'nt printed I think I made the right dimensions to fit my keys. This was one of my better skills in this class, due to the fact that I worked with invetor freshman year.


Inserting Entries Notified to You by Mail
Selected from the Insert button menu in the file list dialog.
This dialog allows you to insert file entries for files whose existance you have been informed of by mail without having to update your offline copy of the file directory. Type in the name of the file and click on Insert to add the entry and invoke the description editor to allow you to add a description to the file.
Until you leave the file list editor (or change topics) your new entry will be flagged by a 'n' in the leftmost column of the file list display.
Note that no validation is performed on the name that you type in.
Click on Cancel if you change your mind.


I build beautiful, responsive websites for small businesses just like you. Check out some of my specialties below:
This pen was created as a project for FreeCodeCamp's Front End certification course. Check them out!


-------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------
-
1
Human Resources Policies
Drug and Alcohol Policy
FUNCTION: HUMAN RESOURCE MANAGEMENT
POLICY: DRUG AND ALCOHOL POLICY
PREPARED BY: GAGANDEEP SINGH
APPROVED BY: BHARAT KAPOOR
DATE: 1
st
December, 2015
VERSION NO: HR/ DAP/ 01-A
Policy Number
HR/ DAP/ 01
Policy
Distribution
Employees
Confidentiality
Confidential to DIPI only
Effective Date
December, 2015
Purpose
The purpose of this policy is to ensure that the Company is able to:
Show its responsibility and commitment to ensure a safe and
healthy workplace for all employees
Outline its expectations and requirements for creating and
maintaining an alcohol and a drug free work environment, and for
dealing with substance abuse in the workplace.
Applicability
This policy applies to the employees of the firm at the workplace, at
client location and at the entire firm off sites/ events during and outside
of normal scheduled working hours.
Policy content
The Drug and Alcohol Policy shall be read along with the applicable
approved standing orders and all the prevailing laws as per the Indian
Statute.
A.
Prohibited acts
1.
The firm explicitly prohibits:
The use, possession, solicitation or sale of narcotics or other illegal
drugs, alcohol or medication without a prescription;
Being impaired under the influence of legal or illegal drugs or alcohol,
if such impairment or influence adversely affects the employee’s
work performance, the safety of the employee or of others or put
firm’s reputation
at risk;
Possession, use, solicitation or sale of legal or illegal drugs or alcohol,
if such activity or involvement adversely
affects the employee’s work
performance, the safety of the employee or of others, or puts the
firm’s reputation at risk
The presence of any detectable amount of prohibited substances in
employee’s system while at work, while on the premises of the firm,
client, any event/ off-
sites or while on firm’s business. “Prohibited
substances” include illegal drugs, alcohol, or prescription drugs not
taken in accordance with a prescription given to the employee.
2.
Involvement with alcohol or drugs during or outside the office hours


Hi, I'm Yudi Purwanto, a Software Engineer rocket from Indonesia.
Talking about Personal Stuffs:
Languages and Tools:


@* * Copyright 2023 HM Revenue & Customs * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. *@ @import forms.Form2 @import include._ @import include.forms2._ @import config.{ ApplicationConfig} @import config.ApplicationConfig @this(main: include.main) @(f: Form2[_], edit: Boolean, activityValues: Seq[String])(implicit request: Request[_],m:Messages, lang: Lang, appConfig: ApplicationConfig) @header = { @components.back_link() @errorSummary(f) } @supportingContent = {
@Messages("businessmatching.updateservice.removeactivities.summary")
@Messages("businessmatching.updateservice.removeactivities.list.heading")
} @main( title = if(activityValues.size == 2) Messages("businessmatching.updateservice.removeactivities.title.twobusinesses") else Messages("businessmatching.updateservice.removeactivities.title.multibusinesses"), heading = header ) { @form(f, controllers.businessmatching.updateservice.remove.routes.RemoveBusinessTypesController.post(edit)) { @fieldsetWithErrorGroup( f = f("businessActivities"), section = "summary.updateservice", heading = if(activityValues.size == 2) Messages("businessmatching.updateservice.removeactivities.heading.twobusinesses") else Messages("businessmatching.updateservice.removeactivities.heading.multibusinesses"), panel = false, supportingContent = numerous_business_types(activityValues) ) { @{activityValues map (value => checkbox( f = f("businessActivities[]"), labelText = s"businessmatching.registerservices.servicename.lbl.$value", value = value ))} } @submit(returnLink = false, buttonMessageKey = Some("businessmatching.updateservice.removeactivities.button"), buttonId = Some("removeactivities-submit")) } }


TalksConferencesICIP Poster Session: CNN-Based Indoor Occupant Localization via Active Scene Illumination (September ’19) MIC Conference: Online Divergence Learning (September ’19) DevConf USA: Data Science on Prometheus Metrics (August ’18) MiscellaneousBostonHacks Workshop: A Hacker's Guide to Parallelization (November ’19) Boston Linux Users: Distributed Computing using MPI on a RaspberryPi Cluster (November ’19) Supercomputing Group of Boston: Super-resolution on a RaspberryPi Cluster (November ’19) BU AI Research Group: Non-linear Metric Learning (July ’19) BU Hack4Impact: An Introduction to Machine Learning (March ’19) BU CS Department Hack Nights: Machine Learning Fundamentals (April ’19) BU UROP Poster Session: Object Localization using Light Transport Analysis (October ’17) RecurringBUHPC Weekly Workshops: Various Topics in High Performance Computing (Fall 2019) |


Scorecard Sunburst Diagram
Scorecard Indicator Cards
Scorecard Tree Diagram
Scorecard Browse & Search


Colorpicker plugin for the Twitter Bootstrap toolkit. Originally
written by @eyecon and maintained in Github by @xaguilars
and the community
Adds a color picker to a field or any other element.
Attached to a field with hex format specified via options.
Attachet to a field with the rgba format specified via data tag.
As component.
Using events to work with the color.
Destroy them all Create them againCall the colopicker via javascript:
$('.my-colorpicker-control').colorpicker()
| Name | type | default | description |
|---|---|---|---|
| format | string | 'hex' | the color format - hex | rgb | rgba. |
Format a component.

 <input type="text" class="span2" value="" >

Initializes an colorpicker.
Show the color picker
Refreshes the widget colors (this is done automatically)
Hide the color picker
Updates the color picker's position relative to the element
Destroys the colorpicker widget and unbind all .colorpicker events from the element and component
Set a new value for the color picker (also for the input or component value). Triggers 'changeColor' event.
Each triggered events have a color object used internally by the picker. This object has several usefull methods.
Set a new color. The value is parsed and tries to do a quess on the format.
Set the HUE with a value between 0 and 1.
Set the saturation with a value between 0 and 1.
Set the lightness with a value between 0 and 1.
Set the transparency with a value between 0 and 1.
Returns a hash with red, green, blue and alpha.
Returns a string with HEX format for the current color.
Returns a hash with HSLA values.
The colopicker plugin exposes some events (with optional .colorpicker namespace)
| Event | Description |
|---|---|
| create | This event fires immediately when the color picker is created. |
| showPicker | This event fires immediately when the color picker is displayed. |
| hidePicker | This event is fired immediately when the color picker is hidden. |
| changeColor | This event is fired when the color is changed. |
| destroy | This event fires immediately when the color picker is destroyed. |
$('.my-colorpicker-control').colorpicker().on('changeColor', function(ev){ bodyStyle.backgroundColor = ev.color.toHex(); });


There are thousands of artificial satellites orbiting the Earth in space every day. However, most of them might be unknown to people. Today, let’s take a fantastic journey to explore the world of artificial satellites...
What is an Artificial Satellite?
In the context of spaceflight, an artificial satellite is an object that has been intentionally placed into orbit. These objects are called artificial satellites to distinguish them from natural satellites such as Earth's Moon.
How Do Satellites Orbit Earth?
Most satellites are launched into space on rockets. A satellite orbits Earth when its speed is balanced by the pull of Earth's gravity. There are four major types of orbit: Low Earth Orbit (LEO), Medium Earth Orbit (MEO), Geostationary Orbit (GEO), and Highly Elliptical Orbit (HEO).
Low Earth Orbit (LEO)
A Low Earth Orbit (LEO) is an Earth-centred orbit with an altitude of 2,000 km (1,200 miles) or less (approximately one-third of the radius of Earth). Most of the man-made objects in outer space are in LEO.
Medium Earth Orbit (MEO)
Medium Earth orbit (MEO) is the region of space around Earth above Low Earth Orbit (altitude of 2,000 km (1,243 miles) above sea level) and below Geostationary Orbit (altitude of 35,786 km (22,236 miles) above sea level).
Geostationary Orbit (GEO)
A Geostationary Orbit (GEO), also referred to as a Geosynchronous Orbit, is a circular orbit 35,786 km (22,236 miles) above Earth's equator and following the direction of Earth's rotation. To ground observers, an object in such an orbit appears motionless in a fixed position in the sky.
Highly Elliptical Orbit (HEO)
A Highly Elliptical Orbit (HEO) is an elongated elliptical orbit around Earth. Bodies moving through such an orbit appear to move slowly, and remain at high altitude over high-latitude ground sites for long periods of time. This makes these elliptical orbits useful for communications satellites.
Now, it is time for you to explore the world of artificial satellite by yourself!
HAVE FUN
:)