How to Use an API: Just the Basic
24 January, 2020
APIs are less like USB ports or fire hoses than they are as a person at a help desk in a foreign country. An API will not give you all of a program's information or code (like a fire hose), because what would stop you from replicating the entire code base? Instead, an API provides you with data its programmers have made available to outside users. Even so, you have to know the language and ask the right questions to do anything with this data.
What is an API?
API stands for an application programming interface. The most important part of this name is interface
, because an API mainly talks to a program for you. You still need to know the language to communicate with the program, but without an API, you won't get far.
When programmers decide to make some of their data available to the public, they expose endpoints
meaning they publish a portion of the language they've used to build their program. Other programmers can then pull data from the application by making URLs or using HTTP clients (special programs that develop the URLs for you) to request data from those endpoints.
Endpoints return text that's meant for computers to read, so it won't make complete sense if you don't understand the computer code used to write it.
Why Should You Use an API?
Computers make a lot of things more comfortable, especially tasks that involve collecting and sorting through tons of data. Let's say you wanted to know how many times a particular business partner submitted invoices to your company. You could feasibly go into your company's invoice records, scan the from
data input, and print each invoice individually for your audit.
On the other hand, if all invoices were uploaded to a central database, you could write a simple program that accesses that database and finds all the instances of the partner's name. This would take much less time and be much more accurate.
The architecture of an API
APIs consist of three parts:
- User: the person who makes a request
- Client: the computer that sends the request to the server
- Server: the computer that responds to the request
Someone will build the server first since it acquires and holds data. Once that server is running, programmers publish documentation, including the endpoints where specific data can be found. This documentation tells outside programmers the structure of the data on the server. An external user can then query (or search) the info on the server, or build a program that runs searches on the database and transforms that information into a different, usable format. That's super confusing, so let's use a real example: an address book.
Back in the analog days, you'd receive a copy of the White Pages phone book, which listed every person in your town by name and address, in alphabetical order. If you needed a friend's address, you could look them up by the last name, find the address, then look up their street on the maps included in the back. This was a limited amount of information, and it took a long time to access. Now, through the magic of technology, all of that information can be found in a database. Let's build a database containing the White Pages for a fictional town called Happyville. The folks at Happyville_WP decided that when they built their database, they would create a few categories of information with nested data underneath. These are our endpoints, and they'll include all the information the API will release to an outside program.
Here are the endpoints listed in the documentation for Happyville_WP:
- /names
- /first_name, /last_name
- /addresses
- /street_address, /email_address/
- /phones
- /home_phone, /mobile_phone
This isn't all the information that could be collected about a person. Even if Happyville_WP collected more private information about the Happyville residents (like birthdates and social security numbers), this data would not be available to outside programmers without knowing the language of those endpoints.
These endpoints tell you the language you must use to request information from the database. Should you want a list of all of the folks in Happyville with the last name Smith, you could do one of two things:
- 1. Make a URL request in a browser for that information. This uses your internet browser as the client, and you will get back a text document in coding language to sort through. That URL might look something like this: http://api.happyville_wp.com/names?last_name=smith
- 2. Use a program that requests the information and translates it into a usable form. You can code your application or use a ready-made HTTP client.
The first option is great for making simple requests with only a few responses (all of the folks in a Happyville with the last name Xarlax, for example
Many companies use open APIs from larger companies like Google and Facebook to access data that might not otherwise be available. APIs, in this case, significantly lower the barriers to entry for smaller companies that would otherwise have to compile their data.
 Okay, so an API is how two computers talk to each other. The server has the data and sets the language. At the same time, the client uses that language to ask for information from the server (FYI, servers do not send data without a client requesting data, but developers have found some ways around this with webhooks). APIs can do anything!
Well, not so fast. The language and syntax of APIs severely limit their abilities. There are four types of actions an API can take:
- GET requests data from a server
can be status or specifics (like last_name) - POST: sends changes from the client to the server; think of this as adding information to the server, like making a new entry
- PUT: revises or adds to existing information
- DELETE: deletes existing information
When you combine the endpoints with these actions, you can search or update any available information over an API. You'll need to check the API documentation to find out how to code these actions, as they're all different.
While we're talking about language and syntax, let's cover the ways you can request a server:
HTTP: hypertext transfer protocol. This is how you got to our site in the first place ‐ by typing a URL in the search bar in your browser. This is a really easy way to access data, but it won't come back to you in a pretty format if you request a lot of information. We'll go into this further in just a second.
Text formats: XML, JSON. These are the main languages for accessing data over an API. When you receive your data, you will need to wade through the XML or JSON code to understand what the server gave you.
Start Using an API
Many of the API uses you'll see in your daily business lives move information from one program to similar form fields in another program. This is especially useful when you're trying to share information that you would otherwise have to enter repeatedly ‐ e.g., sharing leads between your marketing automation platform and your CRM.
The uses and examples we'll list here are much more basic and pull much less data than what your standard API is good for. But they'll give you a good idea of the steps in the API process.
1. Most APIs require an API key. Once you find an API you want to play with, look in the documentation for access requirements. Most APIs will ask you to complete an identity verification, like signing in with your Google account. You'll get a unique string of letters and numbers to use when accessing the API, instead of just adding your email and password every time (which isn't very secure for more information on authorizations and verifications, read this).
2. The easiest way to start using an API is by finding an HTTP client online, like REST-Client, Postman, or Paw. This ready-made (and often free) tools help you structure your requests to access existing APIs with the API key you received. You'll still need to know some of the syntaxes from the documentation, but there is very little coding knowledge required.
3. The next best way to pull data from an API is by building a URL from the existing API documentation. This YouTube video explains how to remove location data from Google Maps via API, and then use those coordinates to find nearby photos on Instagram. Overall, an API request doesn't look that much different from a normal browser URL, but the returned data will be in a form that's easy for computers to read.
Here's what happened when I requested information from the OpenWeather database in my web browser: Example URL from documentation‐request weather for a particular city: API.openweathermap.org/data/2.5/weather?q={city name}
Type into your browser: API.openweathermap.org/data/2.5/weather?q=Nashville,TN&APIID={numberslettersnumbersletters}
Conclusions and Further Reading
An API is useful for pulling specific information from another program. If you know how to read the documentation and write requests, you can get lots of great data back, but it may be overwhelming to parse all of this. That's where developers come in. They can build programs that display data directly in an app or browser window in an easily consumable format.
This article barely scrapes the iceberg that is API technology. I researched the web quite a bit to learn about APIs. These are the articles and videos that helped you the most:
- Using APIs: Not Quite as Hard as It Looks
- How to Use APIs with JavaScript
- Web APIs for Non-Programmers
- Zapier API course
- REST API Concepts and Examples
- What APIs Are and Why They're Important
Prev Post
DeepFakes: AI-powered deception machines
Next Post


Class Shipping
Class Shipping
- LeadCommerce\Shopware\SDK\Entity\Base
- LeadCommerce\Shopware\SDK\Entity\Shipping
Namespace: LeadCommerce\Shopware\SDK\Entity
Located at LeadCommerce/Shopware/SDK/Entity/Shipping.php
Located at LeadCommerce/Shopware/SDK/Entity/Shipping.php
getArrayCopy(),
setEntityAttributes()
|
protected
integer
|
$id
|
|
protected
integer
|
$customerId
|
|
protected
integer
|
$countryId
|
|
protected
integer
|
$stateId
|
|
protected
string
|
$company
|
|
protected
string
|
$department
|
|
protected
string
|
$salutation
|
|
protected
string
|
$number
|
|
protected
string
|
$firstName
|
|
protected
string
|
$lastName
|
|
protected
string
|
$street
|
|
protected
string
|
$streetNumber
|
|
protected
string
|
$zipCode
|
|
protected
string
|
$city
|
|
protected
|
$attribute
|


zmath.matrix
Defines a squared Matrix with column-major ordering from 2x2 to 4x4 size
-
Declaration
alias
Mat2f
= Matrix!(float, 2LU).Matrix;2D squared matrix of floats
-
Declaration
alias
Mat3f
= Matrix!(float, 3LU).Matrix;3D squared matrix of floats
-
Declaration
alias
Mat4f
= Matrix!(float, 4LU).Matrix;4D squared matrix of floats
-
Declaration
alias
Mat2d
= Matrix!(double, 2LU).Matrix;2D squared matrix of doubles
-
Declaration
alias
Mat3d
= Matrix!(double, 3LU).Matrix;3D squared matrix of doubles
-
Declaration
alias
Mat4d
= Matrix!(double, 4LU).Matrix;4D squared matrix of doubles
-
Declaration
alias
Mat2r
= Matrix!(real, 2LU).Matrix;2D squared matrix of reals
-
Declaration
alias
Mat3r
= Matrix!(real, 3LU).Matrix;3D squared matrix of reals
-
Declaration
alias
Mat4r
= Matrix!(real, 4LU).Matrix;4D squared matrix of reals
-
Declaration
struct
Matrix
(T, size_t dim_) if (__traits(isFloating, T) && (dim_ >= 2) && (dim_ <= 4));Defines a squared
Matrix
of n = 2, 3 or 4 size, like a linear array of numbers in a row-major order-
Declaration
static enum size_t
dim
;Matrix Dimension
-
Declaration
static enum size_t
cells
;Matrix number of
cells
-
Declaration
static enum Matrix!(T, 2)
ZERO
;Zero R2 matrix
-
Declaration
static enum Matrix!(T, 2)
IDENTITY
;Identity R2 matrix
-
Declaration
const pure @nogc T
opIndex
(size_trow
, size_tcol
);Returns i, j cell
-
Declaration
@nogc void
opIndexAssign
(K)(Kval
, size_trow
, size_tcol
) if (is(K : real));Assigns a new cell value
-
Declaration
const pure @nogc VRow
opIndex
(size_ti
);Returns
i
row vector -
Declaration
@nogc void
opIndexAssign
(K)(Kv
, size_ti
) if (isVector!K);Assigns a new row vector
-
Declaration
const pure @nogc bool
opEquals
()(auto ref const Matrixrhs
);Define Equality
-
Declaration
const pure @nogc bool
approxEqual
()(auto ref const Matrixrhs
, TmaxRelDiff
= 0.01, TmaxAbsDiff
= 1e-05);Approximated equality
-
Declaration
const pure @nogc Matrix
opUnary
(string op)() if (op == "+" || op == "-");Define unary operators + and -
-
Declaration
const pure @nogc Matrix
opBinary
(string op)(auto ref const Matrixrhs
) if ((op == "+" || op == "-") && (dim >= 2) && (dim <= 4));Define binary operator + and -
-
Declaration
const pure @nogc Matrix
opBinary
(string op)(in realrhs
) if (op == "*" || op == "/");Define Scalar multiplication
-
Declaration
const pure @nogc Matrix
opBinaryRight
(string op)(in realrhs
) if (op == "*" || op == "/");Define Scalar multiplication
-
Declaration
const pure @nogc Matrix
opBinary
(string op)(auto ref const Matrixrhs
) if (op == "*");Define Matrix Product
-
Declaration
const pure @nogc VCol
opBinary
(string op)(auto ref const VRowrhs
) if (op == "*");Define Matrix x Vector
-
Declaration
const pure @nogc VCol
opBinaryRight
(string op)(auto ref const VCollhs
) if (op == "*");Define Vector x Matrix
-
Declaration
const pure @nogc Matrix
transpose
();Returns transposed matrix
Discussion
It can be used to "convert" Matrix to a row ordered matrix
-
Declaration
const pure @nogc T
determinant
();Returns Determinant of this matrix
-
Declaration
const pure @nogc Matrix
inverse
();Calcs this matrix
inverse
Return Value
A matrix full of NaNs if this matrix isn't inverible (!isOk =1)
-
Declaration
const pure @nogc bool
isOk
();Checks that the matrix not have a weird NaN value
-
Declaration
const pure @nogc bool
isFinite
();Checks that the matrix have finite values
-
Declaration
pure nothrow @nogc @property T*
ptr
();Return a pointer of the internal array
-
Declaration
const pure @nogc Tout
opCast
(Tout)() if (isMatrix!Tout && (Tout.dim >= dim));Casting operation that allow convert between Matrix types
-
Declaration
const string
toString
();Returns a visual representation of this matrix
-
-
Declaration
immutable bool
isMatrix
(T);Say if a thing it's a Matrix


New Server
Notifications
4
You have no notifications
Quick Menu
Mailbox
Calendar
Map
To-Do
Tasks
Timeline
Profile
Settings
Help
Logout
HOME
SURVEYS
List Surveys
Invite Respondents
Questionnaires
Statistics
EXTRA
Timeline
Profile
Contact List
Maps
Gallery
Help


GUIT
Load Helpers
Load Specs
Record Specs
RUN Specs
Save Specs
Suite Title
Suite Filename
beforeAll
Call
afterAll
Call
beforeEach
Call
afterEach
Call
Add Spec
Select Action
Add Action


ns
Annotations (2)
description
"An RDF vocabulary for relating SW vocabulary terms to their status."
()
title
"SemWeb Vocab Status ontology"
()
References
Annotation Properties
(5)
Datatypes
(1)
OWL HTML inside


| Table sem5.dbo.COMMAND_REPORT Keeps the administrator-defined filters for the Command details log.
|
Generated by SchemaSpy |
Indexes:
| Column(s) | Type | Sort | Constraint Name |
|---|---|---|---|
| USER_ID + FILTERNAME | Primary key | Asc/Asc | PK_COMMANDREPORT |


{{ inQQQTest }}
First Name:
Last Name:
Full Name: {{firstname + " " + lastname}}
First Name:
{{new}}


Video Game Central
I have been an avid collector of vidoegames since about the the time I was 5 years old. During that time, my parents had purchased a "regular" Nintendo and my very first game, Super Mario Bros. I recall playing that game for hours. I have since gone on to collect several other games, some of which I reveal here.
- Battlefield One
- Final Fantasy XV
- Street Fighter V
- Mortal Combat X
- Fallout 4
- Pokemon Sun
- MarioKart 7
- Pokemon Mystery Dungeon
- The Legend of Zelda
- Dragon Quest


Control Service
via java abstractions.See: Description
| Interface | Description |
|---|---|
| ControlClientPool |
A pool of control clients that brokers incoming SDK harness connections (in the form of
InstructionRequestHandlers . |
| ControlClientPool.Sink |
A sink for
InstructionRequestHandlers keyed by worker id. |
| ControlClientPool.Source |
A source of
InstructionRequestHandlers . |
| InstructionRequestHandler |
Interface for any function that can handle a Fn API
BeamFnApi.InstructionRequest . |
| JobBundleFactory |
A factory that has all job-scoped information, and can be combined with stage-scoped information
to create a
StageBundleFactory . |
| OutputReceiverFactory |
A factory that can create output receivers during an executable stage.
|
| RemoteBundle<InputT> |
A bundle capable of handling input data elements for a
bundle descriptor by
forwarding them to a remote environment for processing. |
| StageBundleFactory<T> |
A bundle factory scoped to a particular
ExecutableStage , which has all of the
resources it needs to provide new RemoteBundles . |
| Class | Description |
|---|---|
| DockerJobBundleFactory |
A
JobBundleFactory that uses a DockerEnvironmentFactory for environment
management. |
| FnApiControlClient |
A client for the control plane of an SDK harness, which can issue requests to it over the Fn API.
|
| FnApiControlClientPoolService |
A Fn API control service which adds incoming SDK harness connections to a sink.
|
| MapControlClientPool |
A
ControlClientPool backed by a client map. |
| ProcessBundleDescriptors |
Utility methods for creating
BeamFnApi.ProcessBundleDescriptor instances. |
| ProcessBundleDescriptors.ExecutableProcessBundleDescriptor | |
| ProcessBundleDescriptors.MultimapSideInputSpec<K,V,W extends BoundedWindow> |
A container type storing references to the key, value, and window
Coder used when
handling multimap side input state requests. |
| RemoteOutputReceiver<T> |
A pair of
Coder and FnDataReceiver which can be registered to receive elements
for a LogicalEndpoint . |
| SdkHarnessClient |
A high-level client for an SDK harness.
|
| SdkHarnessClient.ActiveBundle<InputT> |
An active bundle for a particular
BeamFnApi.ProcessBundleDescriptor . |
| SingleEnvironmentInstanceJobBundleFactory | Deprecated
replace with a
DockerJobBundleFactory when appropriate if the EnvironmentFactory is a DockerEnvironmentFactory , or create an
InProcessJobBundleFactory and inline the creation of the environment if appropriate. |
Control Service
via java abstractions.


iof::skip_past Class Reference
#include <skip_past.hpp>
Collaboration diagram for iof::skip_past:
[legend]List of all members.
Detailed Description
Calls istream::ignore() based on a "skipper specification" or on explicitly specified width/fill char.
In latter case, use width=0 to mean infinity (gobble until EOF).
|
Public Member Functions |
|
| skip_past (const std::string &ign) |
|
| skip_past (int width, char fill=0) |
|
void | applyTo (std::istream &in) const |
The documentation for this class was generated from the following file:
Generated on Sun Oct 15 23:55:35 2006 for IOF Library by
1.4.7


Train and make predictions from a multi-layer perceptron neural network with optional partial monotonicity constraints.
| Version: | 1.1.5 |
| Depends: | optimx |
| Published: | 2017-12-05 |
| Author: | Alex J. Cannon |
| Maintainer: | Alex J. Cannon <alex.cannon at canada.ca> |
| License: | GPL-2 |
| NeedsCompilation: | no |
| CRAN checks: | monmlp results |
| Reference manual: | monmlp.pdf |
| Package source: | monmlp_1.1.5.tar.gz |
| Windows binaries: | r-devel: monmlp_1.1.5.zip, r-release: monmlp_1.1.5.zip, r-oldrel: monmlp_1.1.5.zip |
| OS X binaries: | r-release: monmlp_1.1.5.tgz, r-oldrel: monmlp_1.1.5.tgz |
| Old sources: | monmlp archive |
Please use the canonical form https://CRAN.R-project.org/package=monmlp to link to this page.


Chapter 11 Visualize PC2 vs. PC3
In this section we visualize the output of your PCA computation. The visualization uses two principal components in a pair-wise plot.
- Right click on the data step “PCA” and select
Add
I think it is important to explain better why a new step is needed. Also I think we need to spend more time explaining “Why” follow the steps or do these tasks. To help the user with context.
- Select
Data step
- Open the new
Data step
Looking at the factors on the left of your screen, you will notice there are additional factors in the factor list compared to last section, namely ds0.PC1
, ds0.PC2
, etc..
What are they? Why are they here?
First we require to empty the project by removing factors. Note a tiny x appears when the mouse is placed over the factor zone. > Explain why do we need to do this.
Not a text change but functionality question. Should there not be a blank projection grid here because this is a new step. Why did it populate with the choices from the previous step.
- Hover over the zones
- Click on the
x
to clear the zone, repeat for every zone
The result view should be an empty projection
Now you create the required projection:
- Drag-n-drop the
ds0.PC2
factor to the x-axis zone - Drag-n-drop the
ds0.PC3
factor to the y-axis zone - Drag-n-drop the
sex
andsp
factors to the colors zone
Differentiate the groups the factors are being chosen from.
Click on
Crabs workflow
to return to the workflowRight click on the Data step and select
Rename
Rename it to “PC2vsPC3”
- Save workflow by clicking on the save icon besides the “Crabs workflow”
You visualized PC2 versus PC3. In the next section you gather the PCA results to use them in a multi-group pairwise projection.


This is a mock-up of the Google analytics dashboard with 7 Line charts. It shows one main large Line chart along with 6 smaller charts that all indicate different metrics.
Believe it or not - the data isn't real! There's more code than normal shown below - but that's to be expected with a more complex demo like this.
As you can see from the code shown below, there's some CSS
code as well as JavaScript
to control the
layout and formatting of the individual div
tags
For the six smaller charts the configuration is set on the RGraph.SVG.GLOBALS
object.
Any configuration parameters that are set on this object can be considered as "default values" and
thus the configuration does not have to be set on each Line chart object.
The large text that appears on the left-hand-side of the smaller charts is added by using the
RGraph.SVG.text
function. You too can use this function if you wish to add text
to your own charts. If you're using canvas
though the function is called RGraph.text
and you might need to use the draw
event to add it like this:
new RGraph.Bar({ id: 'cvs', data: [12,18,10,9,6,20,18], options: { } }).on('draw', function (obj) { RGraph.text({ object: obj, font: 'Arial', size: 12, bold: false, italic: false, color: 'black', x: 50, y: 50, text: 'This is some example text!', valign: 'bottom', halign: 'left', tag: 'my-custom-text-label', marker: false }); }).draw();
Note: Be sure to add the draw
event above the call to the draw
function
(as is shown here) or it won't be called.
  Put this where you want the chart to show up:

This is the code that generates the chart - it should be placed AFTER the
div
tag:


Contact: B. Wyman Reviewers: Change history: WebCVS Log for bgrid_prog_var.f90
Initializes a data structure that contains the B-grid core prognostic variables. There are several public routines that operate with this data structure.
This module allocates memory for the B-grid core prognostics variables: surface pressure, temperature, momentum, and tracers; and provides several routines for handling these variables. The module has routines for: 1) setting up the prognostic variables in a data structure 2) performing simple arithmetic with this data structure 3) applying forward explicit time differencing 4) reading and writing prognostic variable restart files All array storage includes the halo region when the allocation is done. Additional public interfaces allocate storage for separate fields.
bgrid_horiz_mod bgrid_vert_mod bgrid_masks_mod bgrid_halo_mod bgrid_cold_start_mod fms_mod field_manager_mod tracer_manager_mod
use bgrid_prog_var_mod [, only: prog_var_type, prog_var_init, var_init, prog_var_times_scalar, prog_var_equals_scalar, prog_var_time_diff, open_prog_var_file, read_prog_var, write_prog_var ] prog_var_type Data structure containing horizontal and vertical grid indices, and the prognostic variables for surface pressure, momentum, temperature, and tracers. prog_var_init Initializes the data structure, prog_var_type. Note: all data arrays are initially set to zero. var_init Initializes storage for a single real array (and sets it to zero). prog_var_times_scalar Operates on a "prog_var_type" data structure. Multiplies the prognostic variables by a scalar. prog_var_equals_scalar Operates on a "prog_var_type" data structure. Assigns a scalar to all prognostic variables. prog_var_time_diff Operates on "prog_var_type" data structures. This interface performs explicit time differencing. open_prog_var_file Opens the restart file for bgrid prognostic variables. read_prog_var Reads the restart file for bgrid prognostic variables. write_prog_var Reads the restart file for bgrid prognostic variables.
type prog_var_type --- integers (scalar) --- nlon = size of the global x-axis compute grid (i.e., number of longitude points) nlat = size of the global y-axis compute grid (i.e., number of latitude points) nlev = number of vertical levels ntrace = number of tracers (in the current data structure) ilb = lower bound index of x-axis (data domain) iub = upper bound index of x-axis (data domain) jlb = lower bound index of y-axis (data domain) jub = upper bound index of y-axis (data domain) klb = lower bound index of k-axis (always =1) kub = upper bound index of k-axis (always =nlev) --- prognostic fields (real arrays) --- ps = surface pressure [real, dimension (ilb:iub, jlb:jub) ] pssl = surface pressure at eta=1 (sea level) [real, dimension (ilb:iub, jlb:jub) ] u = zonal wind component [real, dimension (ilb:iub, jlb:jub, klb:kub) ] v = meridional wind component [real, dimension (ilb:iub, jlb:jub, klb:kub) ] t = temperature [real, dimension (ilb:iub, jlb:jub, klb:kub) ] r = arbitrary number of tracers [real, dimension (ilb:iub, jlb:jub, klb:kub, 1:ntrace) ]
call prog_var_init ( Hgrid, nlev, ntrs, Vars ) INPUT Hgrid Data structure containing horizontal grid constants. [type(horiz_grid_type), see horiz_grid_mod] nlev The number of full model levels for the prognostic variables. [integer] ntrs The total number of tracers. [integer] INPUT/OUTPUT Vars Data structure (derived-type variable) that contains the B-grid prognostic fields (see above). [type(prog_var_type)] --------------------------------------------------------------------- The interface var_init can take several forms. var => var_init ( Hgrid ) var => var_init ( Hgrid, kdim ) var => var_init ( Hgrid, kdim, ntrace ) var => var_init ( ilb, iub, jlb, jub ) var => var_init ( ilb, iub, jlb, jub, kdim ) var => var_init ( ilb, iub, jlb, jub, kdim, ntrace ) INPUT Hgrid Data structure containing horizontal grid constants. [type(horiz_grid_type), see horiz_grid_mod] ilb Lower bound/index for first dimension. [integer] iub Upper bound/index for first dimension. [integer] jlb Lower bound/index for second dimension. [integer] jub Upper bound/index for second dimension. [integer] kdim The size of the third dimension (or level dimension). [integer] ntrace The size of the fourth dimension (or tracer dimension). [integer] RETURNS The returned value is a pointer to memory. Fields that are initialized this way must be declared at pointers. Use the following syntax: real, pointer :: var(:,:) or var(:,:,:) or var(:,:,:,:) --------------------------------------------------------------------- call prog_var_times_scalar ( Var, scalar ) INPUT/OUTPUT Var prog_var_type which on output will have the prognostic variable components (u,v,t,r,ps,pssl) multiplied by scalar INPUT scalar a real scalar quantity --------------------------------------------------------------------- call prog_var_equals_scalar ( Var, scalar ) INPUT/OUTPUT Var prog_var_type which on output will have the prognostic variable components (u,v,t,r,ps,pssl) set equal to scalar INPUT scalar a real scalar quantity --------------------------------------------------------------------- call prog_var_time_diff ( dt, Var_dt, Var, nt ) INPUT dt time step [real] INPUT/OUTPUT Var_dt input value is the tendency for prognostic variables, the output value is zero [prog_var_type] Var the prognostic variables, the input values are at time level n, and the output values are at time level n+1 [prog_var_type] OPTIONAL INPUT nt number of tracers to be advanced in time, by default all tracers will be advanced from time n to n+1 --------------------------------------------------------------------- call open_prog_var_file ( ix, jx, kx [, dir] ) DESCRIPTION This routine can open and read either a NATIVE or NETCDF restart file. The file name is "bgrid_prog_var.res" or "bgrid_prog_var.res.nc". The directory that the file resides in is specified by an optional argument. OUTPUT ix, jx, kx The 3-dimensional size of a prognostic field. (i.e., global resolution read from the restart file) [integer] OPTIONAL INPUT dir Directory where input restart files reside. For the current directory use: "" or "." The maximum length is 128 characters. [character, default: dir='INPUT'] ------------------------------------------------------------- call read_prog_var ( Hgrid, Var, eta, peta, fis, res ) DESCRIPTION This routine can read either a NATIVE or NETCDF restart file. The file name is "bgrid_prog_var.res" or "bgrid_prog_var.res.nc". The directory that the file resides in is specified by interface open_prog_var_file. INPUT/OUTPUT Hgrid Data structure containing horizontal grid constants. [type(horiz_grid_type)] Var Data structure containing prognostic variables. [type(prog_var_type)] OUTPUT eta sigma/eta/bk values at model layer interfaces (half levels) [real, dimension(:)] peta reference pressures (pk) at model layer interfaces [real, dimension(:)] fis geopotential height of the surface [real, dimension(Hgrid%ilb:Hgrid%iub,Hgrid%jlb:Hgrid%jub)] res reciprocal of eta at the surface [real, dimension(Hgrid%ilb:Hgrid%iub,Hgrid%jlb:Hgrid%jub)] NOTES Tracers are not read from the prognostic variable file. For NETCDF format, the tracers are read from a file called "atmos_tracers.res.nc". For NATIVE format, the tracers are read from separate files for each tracers called "tracer_$$$$.res", where $$$$ is the tracer name. ------------------------------------------------------------- call write_prog_var ( Var, Hgrid, Vgrid, fis, res [, dir, format] ) DESCRIPTION This routine can write either a NATIVE or NETCDF restart file. The file name is "bgrid_prog_var.res" or "bgrid_prog_var.res.nc". The directory that the file resides in is specified by an optional argument. INPUT Var Data structure containing prognostic variables. [type(prog_var_type)] Hgrid Data structure containing horizontal grid constants. [type(horiz_grid_type)] Vgrid Data structure containing vertical grid constants. [type(vert_grid_type)] fis geopotential height of the surface [real, dimension(Hgrid%ilb:Hgrid%iub,Hgrid%jlb:Hgrid%jub)] res reciprocal of eta at the surface [real, dimension(Hgrid%ilb:Hgrid%iub,Hgrid%jlb:Hgrid%jub)] OPTIONAL INPUT dir Directory where output restart files reside. For the current directory use: "" or "." The maximum length is 128 characters. [character, default: dir='RESTART'] format File format for output restart files. Valid formats are: 'NATIVE' or 'NETCDF'. [character, default: format='NETCDF'] NOTES Tracers are not written to the prognostic variable file. If format='NETCDF', then tracers are written to a file called "atmos_tracers.res.nc". If format='NATIVE', then tracers are written to separate files for each tracers called "tracer_$$$$.res", where $$$$ is the tracer name.
FATAL errors in bgrid_prog_var_mod can not read tracers with wrong size The size of a tracer in file atmos_tracers.res.nc does not match the 3D model resolution. FATAL errors in write_prog_var invalid value for optional argument format The optional argument format can only have the following values: 'NATIVE' or 'NETCDF'.
None.
None.
Need routines to release allocated memory. These may be called prog_var_end and var_end.


Dengue is a mosquito-borne viral disease that has rapidly spread in all regions of WHO in recent years. Dengue virus is transmitted by female mosquitoes mainly of the species Aedes aegypti and, to a lesser extent, A. albopictus. The disease is widespread throughout the tropics, with local variations in risk influenced by rainfall, temperature and unplanned rapid urbanization.Severe dengue (also known as Dengue Haemorrhagic Fever) was first recognized in the 1950s during dengue epidemics in the Philippines and Thailand. Today, severe dengue affects most Asian and Latin American countries and has become a leading cause of hospitalization and death among children in these regions.!
Check StatusWe provide you a refined information with trends based on Age and Gender, helping you relate and analyze the Stage/Level of infection
Get Started!STRAIN 1 INFO.
STRAIN 2 INFO
STRAIN 3 INFO
STRAIN 4 INFO
PLACEHOLDER FOR THE CLASSIFICATION DETAILS..
SHOULD BE COMBINED WITH C3


I offer professional design, illustration and animation services. If you like the things you can find on this site or my blog, then chances are you will love the work we will make together.
If you're in to the whole résumé thing, you can download a here, or a


Pruning Large Files From Git with BFG
These are my notes on removing large files from a git repository with the BFG Repo-Cleaner. It assumes that you have already pushed it to a remote repository. If you've committed the changes but haven't pushed them, see this post.
1 Background
I accidentally committed an 89 MB file to git and pushed it upstream to github. This is within the allowed file-size limit, but when I looked in the file it was filled with the same error message over and over again, so it wasn't useful to keep, anyway. I was just working with small log-files, so any large files indicated an error, anyway, so I decided to clean anything over 50 MB from the repository using BFG. The instructions on the home page mostly work, but didn't exactly work so I'm making some notes here for the next time.
2 The Process
Assuming you've downloaded the BFG jar file, this is what you need to do.
The --mirror
flag creates a bare repository so it will look a little odd (the top level has the contents of what are normally in the .git
folder). When I first tried this I thought I could clone my local copy but when I ran BFG on the clone it said that it couldn't find any large files. As noted in this bug-report the large files would be in the packfile if you clone it from a remote repository, but not necessarily in the local repository, so I had to clone it from github.
Next run the BFG.
Now you have to change into the cloned repository and execute some commands to update it.
Now push it back to github.
At this point the original local copy of the repository will still have the large file(s) in the history so if you just do a git pull it will think you are ahead of the remote, so you have to remove your original local repository and re-clone the remote.
One thing that tripped me up a little was that I had removed the master branch but the BFG re-added it, so it originally looked like I had lost some changes. Once I changed back into my working branch everything was as I had expected.


Entry number:
Link:
Labels
TitlePage
Abstract
Acknowledgement
Dedication
GeneralAbstract
TableofContent
ListofTables
ListofFigures
Chapters
ChapterAbstract
Appendices
CasesReferenced
ReferenceList
CurriculumVitae
Other
Notes:
Output Filename:


Our enterprise solution, based on the optimalOneTM platform, is a collection of modules designed to meet the ever increasing challenges and demands of operations in global organizations.
We believe that no organizations are the same and this is reflected in our solution as each module that we deliver can be customized to the unique needs of our clients.
The optimalOne TM platform is designed around the industry proven Java Enterprise (JEE) platform, enabling us to build a robust and dynamic solution for our customers. Our application is fully web-based and the front-end, which is based on the Web 2.0 technology, allows us to give the users a highly interactive and seamless user experience.
Crafted by you. Built by us.
Best services with affordable price
No installation needed
Premium support: 24/7
Behind all of the awesomeness there lies a team
Supply Chain Management (SCM) solution with Financial (Accounts Receivable) module for Cement Industries of Malaysia Berhad (CIMA). CIMA is one of the nation’s largest cement manufacturer and processes on average RM2 million worth of transactions daily. Our SCM suite for CIMA manages key aspects of their operations such as distributor orders processing, quota & rebates, flow of cement lorries/tankers, order loading & unloading, weigh bridge integration and many more.
School Management System (SMS) for Kolej Yayasan UEM (KYUEM). KYUEM is among one of Malaysia’s best preparatory college for A-Level. The SMS system used by KYUEM powers their daily operations and improves the efficiency of their critical processes such as the complicated grading cycle.
Visitor Management System (ViMS) Visitor Management System (ViMS) for AE Security Sdn. Bhd. ViMS is a Web 2.0-based solution built on our next generation platform. It is targeted for high-end residences and provides easy-to-use management interface to record visitor entry and exit details. It is also able to seamlessly integrate with security-related devices such as barrier gate controller, closed-circuit television (CCTV), high-resolution face camera and document scanner.
Enterprise Resource Planning (ERP) solution for Borcos Shipping Sdn. Bhd. Borcos is a locally grown shipping company with a fleet of supply and crew boats serving the oil and gas sector primarily in the East and West Malaysia. Our enterprise solution for Borcos comprehensively covers most of their operations including Vessel Management, Warehouse, Finance & Purchasing, Purchasing, Payroll, Preventive Maintenance and many more.
College Management System (CMS) for International Islamic College (IIC). The college is wholly owned by a subsidiary of International Islamic University Malaysia (IIUM). It has an average of close to 4,000 active students per semester. Our solution provides IIC with complete software stack for day-to-day college operations as well as the critical integration between Academic Management and Finance.
Network Management System (NMS) for Malaysian Communications and Multimedia Commission (MCMC) Malaysia Internet Exchange (MyIX) Phase 2 project. MyIX is the initiative by the government to allow neutral and fair peering between various Internet Service Providers (ISPs) in the country (e.g. TMNet, AIMS, Jaring, etc.) so that domestic traffic among the ISPs can be kept locally. The end result of this arrangement ensures better and more efficient traffic handling, improved quality of service and ultimately higher take-up of broadband among local Internet consumers.
School Management System (SMS) for Kolej Tunku Jaafar (KTJ). KTJ is among one of Malaysia’s best preparatory college for A-Level. The SMS system used by KTJ powers their daily operations and improves the efficiency of their critical processes such as the complicated grading cycle.
We’re always happy to keep in touch with our customers.


--- layout: documentation title: User's Guide ---
To run Bazel, go to
your base workspace directory
or any of its subdirectories and type bazel
.
% bazel help [Bazel release bazel-<version>] Usage: bazel <command> <options> ... Available commands: analyze-profile Analyzes build profile data. aquery Executes a query on the post-analysis action graph. build Builds the specified targets. canonicalize-flags Canonicalize Bazel flags. clean Removes output files and optionally stops the server. cquery Executes a post-analysis dependency graph query. dump Dumps the internal state of the Bazel server process. help Prints help for commands, or the index. info Displays runtime info about the bazel server. fetch Fetches all external dependencies of a target. mobile-install Installs apps on mobile devices. query Executes a dependency graph query. run Runs the specified target. shutdown Stops the Bazel server. test Builds and runs the specified test targets. version Prints version information for Bazel. Getting more help: bazel help <command> Prints help and options for <command>. bazel help startup_options Options for the JVM hosting Bazel. bazel help target-syntax Explains the syntax for specifying targets. bazel help info-keys Displays a list of keys used by the info command.
The bazel
tool performs many functions, called
commands. The most commonly used ones are bazel build
and bazel test
. You can browse the online help
messages using bazel help
.
build
command
Type bazel build
followed by the name of the
target you wish to build. Here's a typical
session:
% bazel build //foo ____Loading package: foo ____Loading package: bar ____Loading package: baz ____Loading complete. Analyzing... ____Building 1 target... ____[0 / 3] Executing Genrule //bar:helper_rule ____[1 / 3] Executing Genrule //baz:another_helper_rule ____[2 / 3] Building foo/foo.bin Target //foo:foo up-to-date: bazel-bin/foo/foo.bin bazel-bin/foo/foo ____Elapsed time: 9.905s
Bazel prints the progress messages as it loads all the packages in the transitive closure of dependencies of the requested target, then analyzes them for correctness and to create the build actions, finally executing the compilers and other tools of the build.
Bazel prints progress messages during the execution phase of the build, showing the current build step (compiler, linker, etc.) that is being started, and the number completed over the total number of build actions. As the build starts the number of total actions will often increase as Bazel discovers the entire action graph, but the number will usually stabilize within a few seconds.
At the end of the build Bazel
prints which targets were requested, whether or not they were
successfully built, and if so, where the output files can be found.
Scripts that run builds can reliably parse this output; see --show_result
for more
details.
Typing the same command again:
% bazel build //foo ____Loading... ____Found 1 target... ____Building complete. Target //foo:foo up-to-date: bazel-bin/foo/foo.bin bazel-bin/foo/foo ____Elapsed time: 0.280s
we see a "null" build: in this case, there are no packages to re-load, since nothing has changed, and no build steps to execute. (If something had changed in "foo" or some of its dependencies, resulting in the reexecution of some build actions, we would call it an "incremental" build, not a "null" build.)
Before you can start a build, you will need a Bazel workspace. This is simply a directory tree that contains all the source files needed to build your application. Bazel allows you to perform a build from a completely read-only volume.
Bazel allows a number of ways to specify the targets to be built.
Collectively, these are known as target patterns. This syntax is
used in commands like build
, test
,
or query
.
Whereas labels are used to specify individual targets, e.g. for declaring dependencies in BUILD files, Bazel's target patterns are a syntax for specifying multiple targets: they are a generalization of the label syntax for sets of targets, using wildcards. In the simplest case, any valid label is also a valid target pattern, identifying a set of exactly one target.
All target patterns starting with //
are resolved relative to the current
workspace.
//foo/bar:wiz |
Just the single target //foo/bar:wiz . |
//foo/bar |
Equivalent to //foo/bar:bar . |
//foo/bar:all |
All rules in the package foo/bar . |
//foo/... |
All rules in all packages beneath the directory foo . |
//foo/...:all |
All rules in all packages beneath the directory foo . |
//foo/...:* |
All targets (rules and files) in all packages beneath the directory foo . |
//foo/...:all-targets |
All targets (rules and files) in all packages beneath the directory foo . |
Target patterns which do not begin with //
are resolved relative to the
current working directory. These examples assume a working directory of
foo
:
:foo |
Equivalent to //foo:foo . |
bar:wiz |
Equivalent to //foo/bar:wiz . |
bar/wiz |
Equivalent to:
//foo/bar/wiz:wiz if foo/bar/wiz is a package,
//foo/bar:wiz if foo/bar is a package,
//foo:bar/wiz otherwise.
|
bar:all |
Equivalent to //foo/bar:all . |
:all |
Equivalent to //foo:all . |
...:all |
Equivalent to //foo/...:all . |
... |
Equivalent to //foo/...:all . |
bar/...:all |
Equivalent to //foo/bar/...:all . |
By default, directory symlinks are followed for recursive target patterns, except those that point to under the output base, such as the convenience symlinks that are created in the root directory of the workspace.
In addition, Bazel does not follow symlinks when evaluating recursive target patterns in any directory that contains a file named as follows:
DONT_FOLLOW_SYMLINKS_WHEN_TRAVERSING_THIS_DIRECTORY_VIA_A_RECURSIVE_TARGET_PATTERN
foo/...
is a wildcard over packages,
indicating all packages recursively beneath
directory foo
(for all roots of the package
path). :all
is a wildcard
over targets, matching all rules within a package. These two may be
combined, as in foo/...:all
, and when both wildcards
are used, this may be abbreviated to foo/...
.
In addition, :*
(or :all-targets
) is a
wildcard that matches every target in the matched packages,
including files that aren't normally built by any rule, such
as _deploy.jar
files associated
with java_binary
rules.
This implies that :*
denotes a superset
of :all
; while potentially confusing, this syntax does
allow the familiar :all
wildcard to be used for
typical builds, where building targets like the _deploy.jar
is not desired.
In addition, Bazel allows a slash to be used instead of the colon
required by the label syntax; this is often convenient when using
Bash filename expansion. For example, foo/bar/wiz
is
equivalent to //foo/bar:wiz
(if there is a
package foo/bar
) or to //foo:bar/wiz
(if
there is a package foo
).
Many Bazel commands accept a list of target patterns as arguments,
and they all honor the prefix negation operator -
.
This can be used to subtract a set of targets from the set specified
by the preceding arguments. Note that this means order matters.
For example,
bazel build foo/... bar/...
means "build all
targets beneath foo
and all targets
beneath bar
", whereas
bazel build -- foo/... -foo/bar/...
means "build all targets beneath foo
except
those beneath foo/bar
".
(The --
argument is required to prevent the subsequent
arguments starting with -
from being interpreted as
additional options.)
It's important to point out though that subtracting targets this way will not
guarantee that they are not built, since they may be dependencies of targets
that weren't subtracted. For example, if there were a target
//foo:all-apis
that among others depended on
//foo/bar:api
, then the latter would be built as part of
building the former.
Targets with tags = ["manual"]
will not be included in wildcard target patterns (
...
, :*
, :all
, etc.).
You should specify such test targets with explicit target patterns on the command
line if you want Bazel to build/test them.
By default, Bazel will download and symlink external dependencies during the
build. However, this can be undesirable, either because you'd like to know
when new external dependendencies are added or because you'd like to
"prefetch" dependencies (say, before a flight where you'll be offline). If you
would like to prevent new dependencies from being added during builds, you
can specify the --fetch=false
flag. Note that this flag only
applies to repository rules that do not point to a directory in the local
file system. Changes, for example, to local_repository
,
new_local_repository
and Android SDK and NDK repository rules
will always take effect regardless of the value --fetch
.
If you disallow fetching during builds and Bazel finds new external dependencies, your build will fail.
You can manually fetch dependencies by running bazel fetch
. If
you disallow during-build fetching, you'll need to run bazel
fetch
:
fetch
takes a list of targets to fetch dependencies for. For
example, this would fetch dependencies needed to build //foo:bar
and //bar:baz
:
$ bazel fetch //foo:bar //bar:baz
To fetch all external dependencies for a workspace, run:
$ bazel fetch //...
You do not need to run bazel fetch at all if you have all of the tools you are
using (from library jars to the JDK itself) under your workspace root.
However, if you're using anything outside of the workspace directory then Bazel
will automatically run bazel fetch
before running
bazel build
.
Bazel tries to avoid fetching the same file several times, even if the same
file is needed in different workspaces, or if the definition of an external
repository changed but it still needs the same file to download. To do so,
bazel caches all files downloaded in the repository cache which, by default,
is located at ~/.cache/bazel/_bazel_$USER/cache/repos/v1/
. The
location can be changed by the --repository_cache
option. The
cache is shared between all workspaces and installed versions of bazel.
An entry is taken from the cache if
Bazel knows for sure that it has a copy of the correct file, that is, if the
download request has a SHA256 sum of the file specified and a file with that
hash is in the cache. So specifying a hash for each external file is
not only a good idea from a security perspective; it also helps avoiding
unnecessary downloads.
Upon each cache hit, the modification time of the file in the cache is updated. In this way, the last use of a file in the cache directory can easily be determined, for example to manually clean up the cache. The cache is never cleaned up automatically, as it might contain a copy of a file that is no longer available upstream.
Besides the repository cache, Bazel has a second mechanism to avoid
unnecessary downloads. Using the --distdir
option, you can
specify additional read-only directories to look for files instead of fetching
them. A file is taken from such a directory if the file name is equal to
the base name of the URL and additionally the hash of the file is equal to the
one specified in the download request (again, no file is taken from a distdir,
if no hash is specified). While the condition on the file name is not
necessary for correctness, it reduces the number of candidate files to one per
specified directory. In this way, specifying distribution files directories
remains efficient, even if the number of files in such a directory grows
large.
All the inputs that specify the behavior and result of a given build can be divided into two distinct categories. The first kind is the intrinsic information stored in the BUILD files of your project: the build rule, the values of its attributes, and the complete set of its transitive dependencies. The second kind is the external or environmental data, supplied by the user or by the build tool: the choice of target architecture, compilation and linking options, and other toolchain configuration options. We refer to a complete set of environmental data as a configuration.
In any given build, there may be more than one configuration.
Consider a cross-compile, in which you build
a //foo:bin
executable for a 64-bit architecture,
but your workstation is a 32-bit machine. Clearly, the build
will require building //foo:bin
using a toolchain
capable of creating 64-bit executables, but the build system must
also build various tools used during the build itself—for example
tools that are built from source, then subsequently used in, say, a
genrule—and these must be built to run on your workstation.
Thus we can identify two configurations: the host
configuration, which is used for building tools that run during
the build, and the target configuration (or request
configuration, but we say "target configuration" more often even
though that word already has many meanings), which is
used for building the binary you ultimately requested.
Typically, there are many libraries that are prerequisites of both
the requested build target (//foo:bin
) and one or more of
the host tools, for example some base libraries. Such libraries must be built
twice, once for the host configuration, and once for the target
configuration.
Bazel takes care of ensuring that both variants are built, and that
the derived files are kept separate to avoid interference; usually
such targets can be built concurrently, since they are independent
of each other. If you see progress messages indicating that a given
target is being built twice, this is most likely the explanation.
Bazel uses one of two ways to select the host configuration, based
on the --distinct_host_configuration
option. This
boolean option is somewhat subtle, and the setting may improve (or
worsen) the speed of your builds.
--distinct_host_configuration=false
When this option is false, the host and request configurations are identical: all tools required during the build will be built in exactly the same way as target programs. This setting means that no libraries need to be built twice during a single build, so it keeps builds short. However, it does mean that any change to your request configuration also affects your host configuration, causing all the tools to be rebuilt, and then anything that depends on the tool output to be rebuilt too. Thus, for example, simply changing a linker option between builds might cause all tools to be re-linked, and then all actions using them reexecuted, and so on, resulting in a very large rebuild. Also, please note: if your host architecture is not capable of running your target binaries, your build will not work.
If you frequently make changes to your request configuration, such
as alternating between -c opt
and -c dbg
builds, or between simple- and cross-compilation, we do not
recommend this option, as you will typically rebuild the majority of
your codebase each time you switch.
--distinct_host_configuration=true
(default)If this option is true, then instead of using the same configuration for the host and request, a completely distinct host configuration is used. The host configuration is derived from the target configuration as follows:
--crosstool_top
) as specified in the request
configuration, unless --host_crosstool_top
is
specified.
--host_cpu
for
--cpu
(default: k8
).
--compiler
,
--use_ijars
,
If --host_crosstool_top
is used, then the value of
--host_cpu
is used to look up a
default_toolchain
in the Crosstool
(ignoring --compiler
) for the host configuration.
--host_javabase
for
--javabase
--host_java_toolchain
for
--java_toolchain
-c opt
).
--copt=-g0
).
--strip=always
).
--embed_*
options).
There are many reasons why it might be preferable to select a distinct host configuration from the request configuration. Some are too esoteric to mention here, but two of them are worth pointing out.
Firstly, by using stripped, optimized binaries, you reduce the time spent linking and executing the tools, the disk space occupied by the tools, and the network I/O time in distributed builds.
Secondly, by decoupling the host and request configurations in all builds, you avoid very expensive rebuilds that would result from minor changes to the request configuration (such as changing a linker options does), as described earlier.
That said, for certain builds, this option may be a hindrance. In particular, builds in which changes of configuration are infrequent (especially certain Java builds), and builds where the amount of code that must be built in both host and target configurations is large, may not benefit.
One of the primary goals of the Bazel project is to ensure correct incremental rebuilds. Previous build tools, especially those based on Make, make several unsound assumptions in their implementation of incremental builds.
Firstly, that timestamps of files increase monotonically. While this is the typical case, it is very easy to fall afoul of this assumption; syncing to an earlier revision of a file causes that file's modification time to decrease; Make-based systems will not rebuild.
More generally, while Make detects changes to files, it does
not detect changes to commands. If you alter the options passed to
the compiler in a given build step, Make will not re-run the
compiler, and it is necessary to manually discard the invalid
outputs of the previous build using make clean
.
Also, Make is not robust against the unsuccessful termination of one of its subprocesses after that subprocess has started writing to its output file. While the current execution of Make will fail, the subsequent invocation of Make will blindly assume that the truncated output file is valid (because it is newer than its inputs), and it will not be rebuilt. Similarly, if the Make process is killed, a similar situation can occur.
Bazel avoids these assumptions, and others. Bazel maintains a database of all work previously done, and will only omit a build step if it finds that the set of input files (and their timestamps) to that build step, and the compilation command for that build step, exactly match one in the database, and, that the set of output files (and their timestamps) for the database entry exactly match the timestamps of the files on disk. Any change to the input files or output files, or to the command itself, will cause re-execution of the build step.
The benefit to users of correct incremental builds is: less time
wasted due to confusion. (Also, less time spent waiting for
rebuilds caused by use of make clean
, whether necessary
or pre-emptive.)
Formally, we define the state of a build as consistent when all the expected output files exist, and their contents are correct, as specified by the steps or rules required to create them. When you edit a source file, the state of the build is said to be inconsistent, and remains inconsistent until you next run the build tool to successful completion. We describe this situation as unstable inconsistency, because it is only temporary, and consistency is restored by running the build tool.
There is another kind of inconsistency that is pernicious: stable
inconsistency. If the build reaches a stable inconsistent
state, then repeated successful invocation of the build tool does
not restore consistency: the build has gotten "stuck", and the
outputs remain incorrect. Stable inconsistent states are the main
reason why users of Make (and other build tools) type make
clean
. Discovering that the build tool has failed in this
manner (and then recovering from it) can be time consuming and very
frustrating.
Conceptually, the simplest way to achieve a consistent build is to throw away all the previous build outputs and start again: make every build a clean build. This approach is obviously too time-consuming to be practical (except perhaps for release engineers), and therefore to be useful, the build tool must be able to perform incremental builds without compromising consistency.
Correct incremental dependency analysis is hard, and as described above, many other build tools do a poor job of avoiding stable inconsistent states during incremental builds. In contrast, Bazel offers the following guarantee: after a successful invocation of the build tool during which you made no edits, the build will be in a consistent state. (If you edit your source files during a build, Bazel makes no guarantee about the consistency of the result of the current build. But it does guarantee that the results of the next build will restore consistency.)
As with all guarantees, there comes some fine print: there are some known ways of getting into a stable inconsistent state with Bazel. We won't guarantee to investigate such problems arising from deliberate attempts to find bugs in the incremental dependency analysis, but we will investigate and do our best to fix all stable inconsistent states arising from normal or "reasonable" use of the build tool.
If you ever detect a stable inconsistent state with Bazel, please report a bug.
Bazel uses sandboxes to guarantee that actions run hermetically1 and correctly.
Bazel runs Spawns (loosely speaking: actions) in sandboxes that only contain the minimal
set of files the tool requires to do its job. Currently sandboxing works on Linux 3.12 or newer
with the CONFIG_USER_NS
option enabled, and also on macOS 10.11 or newer.
Bazel will print a warning if your system does not support sandboxing to alert you to the fact
that builds are not guaranteed to be hermetic and might affect the host system in unknown ways.
To disable this warning you can pass the --ignore_unsupported_sandboxing
flag to
Bazel.
On some platforms such as Google Kubernetes
Engine cluster nodes or Debian, user namespaces are deactivated by default due to security
concerns. This can be checked by looking at the file
/proc/sys/kernel/unprivileged_userns_clone
: if it exists and contains a 0, then
user namespaces can be activated with sudo sysctl kernel.unprivileged_userns_clone=1
.
In some cases, the Bazel sandbox fails to execute rules because of the system setup. The symptom
is generally a failure that output a message similar to
namespace-sandbox.c:633: execvp(argv[0], argv): No such file or directory
. In that
case, try to deactivate the sandbox for genrules with --strategy=Genrule=standalone
and for other rules with --spawn_strategy=standalone
. Also please report a bug on our
issue tracker and mention which Linux distribution you're using so that we can investigate and
provide a fix in a subsequent release.
1: Hermeticity means that the action only uses its declared input files and no other files in the filesystem, and it only produces its declared output files.
In Bazel, a build occurs in three distinct phases; as a user, understanding the difference between them provides insight into the options which control a build (see below).
The first is loading during which all the necessary BUILD files for the initial targets, and their transitive closure of dependencies, are loaded, parsed, evaluated and cached.
For the first build after a Bazel server is started, the loading phase typically takes many seconds as many BUILD files are loaded from the file system. In subsequent builds, especially if no BUILD files have changed, loading occurs very quickly.
Errors reported during this phase include: package not found, target not found, lexical and grammatical errors in a BUILD file, and evaluation errors.
The second phase, analysis, involves the semantic analysis and validation of each build rule, the construction of a build dependency graph, and the determination of exactly what work is to be done in each step of the build.
Like loading, analysis also takes several seconds when computed in its entirety. However, Bazel caches the dependency graph from one build to the next and only reanalyzes what it has to, which can make incremental builds extremely fast in the case where the packages haven't changed since the previous build.
Errors reported at this stage include: inappropriate dependencies, invalid inputs to a rule, and all rule-specific error messages.
The loading and analysis phases are fast because Bazel avoids unnecessary file I/O at this stage, reading only BUILD files in order to determine the work to be done. This is by design, and makes Bazel a good foundation for analysis tools, such as Bazel's query command, which is implemented atop the loading phase.
The third and final phase of the build is execution. This phase ensures that the outputs of each step in the build are consistent with its inputs, re-running compilation/linking/etc. tools as necessary. This step is where the build spends the majority of its time, ranging from a few seconds to over an hour for a large build. Errors reported during this phase include: missing source files, errors in a tool executed by some build action, or failure of a tool to produce the expected set of outputs.
The Bazel system is implemented as a long-lived server process.
This allows it to perform many optimizations not possible with a
batch-oriented implementation, such as caching of BUILD files,
dependency graphs, and other metadata from one build to the
next. This improves the speed of incremental builds, and allows
different commands, such as build
and query
to share the same cache of loaded packages,
making queries very fast.
When you run bazel
, you're running the client. The
client finds the server based on the output base, which by default is
determined by the path of the base workspace directory and your
userid, so if you build in multiple workspaces, you'll have multiple
output bases and thus multiple Bazel server processes. Multiple
users on the same workstation can build concurrently in the same
workspace because their output bases will differ (different userids).
If the client cannot find a running server instance, it starts a new
one. The server process will stop after a period of inactivity (3 hours,
by default, which can be modified using the startup option --max_idle_secs
).
For the most part, the fact that there is a server running is invisible to the user, but sometimes it helps to bear this in mind. For example, if you're running scripts that perform a lot of automated builds in different directories, it's important to ensure that you don't accumulate a lot of idle servers; you can do this by explicitly shutting them down when you're finished with them, or by specifying a short timeout period.
The name of a Bazel server process appears in the output of ps
x
or ps -e f
as
bazel(dirname)
, where dirname is the
basename of the directory enclosing the root of your workspace directory.
For example:
% ps -e f 16143 ? Sl 3:00 bazel(src-johndoe2) -server -Djava.library.path=...
This makes it easier to find out which server process belongs to a
given workspace. (Beware that with certain other options
to ps
, Bazel server processes may be named just
java
.) Bazel servers can be stopped using
the shutdown command.
When running bazel
, the client first checks that the
server is the appropriate version; if not, the server is stopped and
a new one started. This ensures that the use of a long-running
server process doesn't interfere with proper versioning.
.bazelrc
, the Bazel configuration file,
the --bazelrc=file
option, and
the --config=value
option
Bazel accepts many options. Typically, some of these are varied
frequently (for example, --subcommands
) while others stay the
same across several builds (e.g. --package_path
).
To avoid having to specify these unchanged options for every build (and other commands)
Bazel allows you to specify options in a configuration file.
.bazelrc
files?
Bazel looks for an optional configuration file in the following locations,
in the order shown below. The options are interpreted in this order, so
options in later files can override a value from an earlier file if a
conflict arises. All options to control which of these files are loaded are
startup options, which means they must occur after bazel
and
before the command (build
, etc).
--nosystem_rc
is present, Bazel looks for
the system .bazelrc file: on Unix, it lives at /etc/bazel.bazelrc
,
and on Windows at %ProgramData%/bazel.bazelrc
.
If another system-specified location is required, this value can be
changed by setting BAZEL_SYSTEM_BAZELRC_PATH
in
src/main/cpp:option_processor
and using this custom Bazel binary.
The system-specified location may contain environment variable
substitutions, as %var_name%
on Windows
or ${var_name}
on Unix.
--noworkspace_rc
is present, Bazel looks
for the .bazelrc
file in your workspace directory.
--nohome_rc
is present, Bazel looks for
the home, or user, bazelrc: the file .bazelrc
in your home
directory.
--bazelrc=file
startup option. If this
option is not present, no additional file is loaded. Unlike in the three
default locations specified above, an incorrect path or non-existent file
will fail if passed explicitly.
.bazelrc
syntax and semantics
Like all UNIX "rc" files, the .bazelrc
file is a text file with
a line-based grammar. Lines starting #
are considered comments
and are ignored, as are blank lines. Each line contains a sequence of words,
which are tokenized according to the same rules as the Bourne shell.
Lines that start with import
are special: if Bazel encounters such
a line in a .bazelrc
file, it parses the contents of the file
referenced by the import statement, too. Options specified in an imported file
take precedence over options specified before the import statement. Options
specified after the import statement take precedence over the options in the
imported file. Options in files imported later take precedence over files
imported earlier. To specify a path that is relative to the workspace root,
write import %workspace%/path/to/bazelrc
.
Most lines of a bazelrc define default option values. The first word on each line specifies when these defaults are applied:
startup
: startup options, which go before the command, and
are described in bazel help startup_options
.
common
: options that apply to all Bazel commands.
command
: Bazel command, such as build
or query
to which the options apply. These options also apply
to all commands that inherit from the specified command. (For example,
test
inherits from build
.)
Each of these lines may be used more than once and the arguments that follow
the first word are combined as if they had appeared on a single line.
(Users of CVS, another tool with a "Swiss army knife" command-line interface,
will find the syntax similar to that of .cvsrc
.)
Options specified in the command line always take precedence over those from
a configuration file. Within the configuration file, precedence is
given by specificity. This means that lines for a more specific command take
precedence over lines for a less specific command, with common
getting lowest precedence (for example, the test
command inherits
all the options from the build
command, so the line
test --foo=bar
takes precedence over the line
build --foo=baz
, regardless of which rc file or what order
these two lines are in). Two lines specifying options for the same command at
equal specificity are parsed in the order in which they appear within the file.
The user-specific configuration file takes precedence over the master file.
Because this precedence rule does not match the file order, we recommend
that the file follows the same order, with common
options at the
top, and most-specific commands near the bottom. This way, the order in which
the options are read is the same as the order in which they are applied,
which is more intuitive.
The arguments specified on a line of an rc file may include arguments that are not options, such as the names of build targets, and so on. These, like the options specified in the same files, have lower precedence than their siblings on the command line, and are always prepended to the explicit list of non- option arguments.
--config
In addition to setting option defaults, the rc file can be used to group
options and provide a shorthand for common groupings. This is done by adding
a :name
suffix to the command. These options are ignored by
default, but will be included when the option
--config=name
is present, either on the command line
or in a .bazelrc
file, recursively, even inside of another
config definition. The options specified by command:name
will
only be expanded for applicable commands, in the precedence order described
above.
Note that configs can be defined in any .bazelrc
file, and that
all lines of the form command:name
(for applicable commands)
will be expanded, across the different rc files. In order to avoid name
conflicts, we suggest that configs defined in personal rc files start
with an underscore ('_') to avoid unintentional name sharing.
--config=foo
expands to the options defined in the rc files
"in-place" so that the options specified for the config have the same
precedence that the --config=foo
option had.
Here's an example ~/.bazelrc
file:
# Bob's Bazel option defaults startup --host_jvm_args=-XX:-UseParallelGC import /home/bobs_project/bazelrc build --show_timestamps --keep_going --jobs 600 build --color=yes query --keep_going # Definition of --config=memcheck build:memcheck --strip=never --test_timeout=3600
.bazelignore
You can specify directories within the workspace
that you want Bazel to ignore, such as related projects
that use other build systems. Place a file called
.bazelignore
at the root of the workspace
and add the directories you want Bazel to ignore, one per
line. Entries are relative to the workspace root.
Bazel can be called from scripts in order to perform a build, run tests or query the dependency graph. Bazel has been designed to enable effective scripting, but this section lists some details to bear in mind to make your scripts more robust.
The --output_base
option controls where the Bazel process should
write the outputs of a build to, as well as various working files used
internally by Bazel, one of which is a lock that guards against
concurrent mutation of the output base by multiple Bazel processes.
Choosing the correct output base directory for your script depends
on several factors. If you need to put the build outputs in a
specific location, this will dictate the output base you need to
use. If you are making a "read only" call to Bazel
(e.g. bazel query
), the locking factors will be more important.
In particular, if you need to run multiple instances of your script
concurrently, you will need to give each one a different (or random) output
base.
If you use the default output base value, you will be contending for the same lock used by the user's interactive Bazel commands. If the user issues long-running commands such as builds, your script will have to wait for those commands to complete before it can continue.
By default, Bazel uses a long-running server process as an optimization. When running Bazel
in a script, don't forget to call shutdown
when you're finished
with the server, or, specify --max_idle_secs=5
so
that idle servers shut themselves down promptly.
Bazel attempts to differentiate failures due to the source code under consideration from external errors that prevent Bazel from executing properly. Bazel execution can result in following exit codes:
Exit Codes common to all commands:0
- Success2
- Command Line Problem, Bad or Illegal flags or command
combination, or Bad Environment Variables. Your command line must be
modified.8
- Build Interrupted but we terminated with an orderly shutdown.32
- External Environment Failure not on this machine.33
- OOM failure. You need to modify your command line.34
- Reserved for Google-internal use.35
- Reserved for Google-internal use.36
- Local Environmental Issue, suspected permanent.37
- Unhandled Exception / Internal Bazel Error.38
- Reserved for Google-internal use.40-44
- Reserved for errors in Bazel's command line launcher,
bazel.cc
that are not command line
related. Typically these are related to bazel server
being unable to launch itself.bazel build
, bazel test
.
1
- Build failed.3
- Build OK, but some tests failed or timed out.4
- Build successful but no tests were found even though
testing was requested.bazel run
:
1
- Build failed.bazel query
:
3
- Partial success, but the query encountered 1 or more
errors in the input BUILD file set and therefore the
results of the operation are not 100% reliable.
This is likely due to a --keep_going
option
on the command line.7
- Command failure.
Future Bazel versions may add additional exit codes, replacing generic failure
exit code 1
with a different non-zero value with a particular
meaning. However, all non-zero exit values will always constitute an error.
By default, Bazel will read the .bazelrc
file from the base workspace
directory or the user's home directory. Whether or not this is
desirable is a choice for your script; if your script needs to be
perfectly hermetic (e.g. when doing release builds), you should
disable reading the .bazelrc file by using the option
--bazelrc=/dev/null
. If you want to perform a build
using the user's preferred settings, the default behavior is better.
The Bazel output is also available in a command log file which you can find with the following command:
% bazel info command_log
The command log file contains the interleaved stdout and stderr streams
of the most recent Bazel command. Note that running bazel info
will overwrite the contents of this file, since it then becomes the most
recent Bazel command. However, the location of the command log file will
not change unless you change the setting of the --output_base
or --output_user_root
options.
The Bazel output is quite easy to parse for many purposes. Two
options that may be helpful for your script are
--noshow_progress
which suppresses progress messages,
and --show_result n
, which controls whether
or not "build up-to-date" messages are printed; these messages may
be parsed to discover which targets were successfully built, and the
location of the output files they created. Be sure to specify a
very large value of n if you rely on these messages.
The first step in analyzing the performance of your build is to profile your build with the
--profile
option.
The file generated by the --profile
command is a binary file. Once you have generated this binary profile, you can analyze it using
Bazel's analyze-profile
command. By default, it will
print out summary analysis information for each of the specified profile datafiles. This includes
cumulative statistics for different task types for each build phase and an analysis of the
critical execution path.
The first section of the default output describes an overview of the time spent on the different build phases:
=== PHASE SUMMARY INFORMATION === Total launch phase time 6.00 ms 0.01% Total init phase time 864 ms 1.11% Total loading phase time 21.841 s 28.05% Total analysis phase time 5.444 s 6.99% Total preparation phase time 155 ms 0.20% Total execution phase time 49.473 s 63.54% Total finish phase time 83.9 ms 0.11% Total run time 77.866 s 100.00%
The following sections show the execution time of different tasks happening during a particular phase:
=== INIT PHASE INFORMATION === Total init phase time 864 ms Total time (across all threads) spent on: Type Total Count Average VFS_STAT 2.72% 1 23.5 ms VFS_READLINK 32.19% 1 278 ms === LOADING PHASE INFORMATION === Total loading phase time 21.841 s Total time (across all threads) spent on: Type Total Count Average SPAWN 3.26% 154 475 ms VFS_STAT 10.81% 65416 3.71 ms [...] SKYLARK_BUILTIN_FN 13.12% 45138 6.52 ms === ANALYSIS PHASE INFORMATION === Total analysis phase time 5.444 s Total time (across all threads) spent on: Type Total Count Average SKYFRAME_EVAL 9.35% 1 4.782 s SKYFUNCTION 89.36% 43332 1.06 ms === EXECUTION PHASE INFORMATION === Total preparation time 155 ms Total execution phase time 49.473 s Total time finalizing build 83.9 ms Action dependency map creation 0.00 ms Actual execution time 49.473 s Total time (across all threads) spent on: Type Total Count Average ACTION 2.25% 12229 10.2 ms [...] SKYFUNCTION 1.87% 236131 0.44 ms
The last section shows the critical path:
Critical path (32.078 s): Id Time Percentage Description 1109746 5.171 s 16.12% Building [...] 1109745 164 ms 0.51% Extracting interface [...] 1109744 4.615 s 14.39% Building [...] [...] 1109639 2.202 s 6.86% Executing genrule [...] 1109637 2.00 ms 0.01% Symlinking [...] 1109636 163 ms 0.51% Executing genrule [...] 4.00 ms 0.01% [3 middleman actions]
You can use the following options to display more detailed information:
--dump=text
This option prints all recorded tasks in the order they occurred. Nested tasks are indented relative to the parent. For each task, output includes the following information:
[task type] [task description] Thread: [thread id] Id: [task id] Parent: [parent task id or 0 for top-level tasks] Start time: [time elapsed from the profiling session start] Duration: [task duration] [aggregated statistic for nested tasks, including count and total duration for each nested task]
--dump=raw
This option is most useful for automated analysis with scripts. It outputs each task record on a single line using '|' delimiter between fields. Fields are printed in the following order:
1|1|0|0|0||PHASE|Launch Bazel 1|2|0|6000000|0||PHASE|Initialize command 1|3|0|168963053|278111411||VFS_READLINK|/[...] 1|4|0|571055781|23495512||VFS_STAT|/[...] 1|5|0|869955040|0||PHASE|Load packages [...]
--html
This option writes a file called <profile-file>.html
in the directory of the
profile file. Open it in your browser to see the visualization of the actions in your build.
Note that the file can be quite large and may push the capabilities of your browser –
please wait for the file to load.
In most cases, the HTML output from --html
is easier to
read than the --dump
output.
It includes a Gantt chart that displays time on the horizontal axis and
threads of execution along the vertical axis. If you click on the Statistics link in the top
right corner of the page, you will jump to a section that lists summary analysis information
from your build.
--html_details
Additionally passing this option will render a more detailed execution chart and additional tables on the performance of built-in and user-defined Skylark functions. Beware that this increases the file size and the load on the browser considerably.
If Bazel appears to be hung, you can hit ctrl + \ or send
Bazel a SIGQUIT
signal (kill -3 $(bazel info server_pid)
) to get a
thread dump in the file $(bazel info output_base)/server/jvm.out
.
Since you may not be able to run bazel info
if bazel is hung, the
output_base
directory is usually the parent of the bazel-<workspace>
symlink in your workspace directory.


Upload File OR drag and drop


Google Earth Enterprise Documentation Home | Fusion tutorial
Configure tutorial workspace
To accommodate users who are working through the tutorial at the same time other users (or even those same users) are working on production data, Google recommends that you configure a tutorial work space on each workstation where you install the tutorial data. That way, you can keep the tutorial source volume and asset root separate from your production source volume(s) and asset root.
This article describes how to configure the tutorial work space and how to switch back and forth between the tutorial asset root and the production asset root. You also learn how to clean up the tutorial files when they are no longer needed.
- Download the Tutorial Source Files
- Configure the tutorial asset root and source volume
- Select the tutorial asset root
- Clean up the tutorial workspace
Download the Tutorial Source Files
The tutorial source files are available in the following archives. It can be downloaded all together, or for convenience it can be downloaded in two parts.
- FusionTutorial-Full.tar.gz [md5] - Contains all the source data needed to complete the tutorial - 600 MB
- FusionTutorial-NoMosaicImagery.tar.gz [md5] - Contains all the source data needed to complete the tutorial, except for the Mosaic section - 282 MB
- FusionTutorial-Imagery-mosaic.tar.gz [md5] - Contains only the souce data needed to complete the Mosaic section of the tutorial - 318 MB
Once the source files are downloaded, as root, create the /opt/google/share/tutorials/fusion
directory if it doesn't
exist. Extract each archive downloaded to that location. Be sure all the files have read permission for all users and directories
have read and execute permission for all users.
Note: due to a bug in the current Google Earth Enterprise Open Source version, vector source files also need the write permission.
Configuring the tutorial asset root and source volume
When you install Google Earth Enterprise, you configure a source volume and asset root for your production data. If you accepted the default values, they are /gevol/src
and /gevol/assets
, respectively.
The installation script installs the tutorial files in /opt/google/share/tutorials/fusion
, so you must add that path as the source volume for the tutorial. In addition, Google recommends that you add a tutorial asset root for users to store the data they create with Google Earth Enterprise Fusion while working through the tutorial.
The following procedure describes how to configure an asset root and the tutorial source volume for each tutorial user. You must configure them for each user on each workstation where you install the Google Earth Enterprise Fusion tutorial files.
To configure a tutorial asset root and source volume:
- On the command line, log in as root.
- Stop the system manager by entering:
/etc/init.d/gefusion stop
- Enter:
geconfigureassetroot --new --assetroot /username/assets
where username is the name of the user.
The username does not have to be the user’s official account name. It can be anything that distinguishes that user from other users on that particular workstation, such as
edaniels
or justEmily
.Note: Google recommends that you place the tutorial asset root on the same partition as the publish root, so the publisher uses hard links instead of making copies of the tutorial databases.
If you place the tutorial asset root on the root partition, ensure that there is enough disk space for the data created by each user working through the tutorial. If a user completes all lessons in the tutorial, allow 1.5 GB of disk space.
The tool asks if you want to create a new source volume.
- Enter
Y
, and press Enter.You are prompted to enter a directory for the source volume.
- Enter
/opt/google/share/tutorials/fusion
, and press Enter.The tool asks if you want to add more volumes.
- If you want to create tutorial work spaces for more users, enter
Y
, press Enter, and repeat steps 3 through 5. If not, skip this step. Otherwise, enterN
, and press Enter.The tool displays the message “Configured
/
username/assets
” and returns you to the command line prompt. - Log out as root.
- Start the system manager by entering:
/etc/init.d/gefusion start
Note: The new source volume and asset root are automatically selected for you. You do not have to run the
geselectassetroot
command. (See the next section, Select the Tutorial Asset Root, for more information about selecting different asset roots.)
Select the tutorial asset root
There are two occasions when users must select a different asset root:
- When multiple users share a single workstation, each user must select his or her own tutorial asset root.
- When a user switches from the tutorial data to real production data, he or she must select the appropriate asset root.
This section explains how to select a different asset root.
Caution: Note that even though your source volumes and asset roots are separate for each user or for the tutorial and production data, there is only one publish root on each virtual server for Earth databases and one for Map databases.
When two users are sharing a single workstation, they are both publishing to the same publish root. When one user publishes a database on that workstation, it overwrites any database that might have been published previously by another user on that same workstation. Likewise, if a user is switching back and forth between tutorial and production data on the same workstation, it is possible to overwrite a production database with a tutorial database and vice versa. Of course, the user can simply republish the desired database to make it available to Google Earth EC again.
To select the tutorial asset root:
- On the command line, log in as root.
- Stop the system manager by entering:
/etc/init.d/gefusion stop
- Enter:
geselectassetroot --assetroot /username/assets
where username is the name you used in step 3 of Configure the tutorial asset root and source volume.
- Log out as root.
- Start the system manager by entering:
/etc/init.d/gefusion start
Clean up the tutorial work space
When a user completes the tutorial or no longer needs the tutorial data, you can clean up that tutorial work space, if desired, by removing the tutorial source files, asset root, and published databases. This section describes the best way to perform that clean-up.
Note: Google recommends that you keep the tutorial files intact, since they use very little space and can come in handy for users to practice, even after they have quite a bit of experience with Google Earth Enterprise Fusion.
To remove the tutorial source files, asset root, and databases:
- At the command line prompt, log in as root.
- Stop the system manager by entering:
/etc/init.d/gefusion stop
- Select the production asset root by entering:
geselectassetroot --assetroot /gevol/assets
Substitute the appropriate asset root path, if necessary.
- Stop the Google Earth Enterprise Server:
/etc/init.d/geserver stop
- Delete the tutorial files:
rm -Rf /opt/google/share/tutorials/fusion/
- Delete the user’s tutorial asset root by entering:
rm -Rf /username/assets
where username is the name of the user you specified when you configured the tutorial work space.
Caution: Make sure you are removing the tutorial asset root, not the production root. If you delete the production root, there is no way to recover it (other than from back-ups, if available).
- Start the Google Earth Enterprise Fusion system manager and Google Earth Enterprise Server:
/etc/init.d/gefusion start /etc/init.d/geserver start
The order in which you start them does not matter.
- List the databases on the current server by entering:
geserveradmin --listdbs
The tool displays a list of all databases ever published (except any deleted databases) on the server. If the server type is omitted, the server type defaults to
stream
. - Select the database you want to remove by entering:
geserveradmin --deletedb db_name...
where db_name is the name of the database you want to delete.
Note: If you want to delete a currently published database, you can either publish a different database to the same virtual server or disable the virtual server on which it is published. Then you can delete the database.
This tool does not delete the actual files. It is similar to putting files in the trash on a Windows or Macintosh desktop.
- Permanently delete the selected databases by entering:
geserveradmin --garbagecollect


Flag
Information about a command-line flag.
tf.compat.v1.app.flags.Flag
'Flag' objects define the following fields: .name - the name for this flag; .default - the default value for this flag; .default_unparsed - the unparsed default value for this flag. .default_as_str - default value as repr'd string, e.g., "'true'" (or None); .value - the most recent parsed value of this flag; set by parse(); .help - a help string or None if no help is available; .short_name - the single letter alias for this flag (or None); .boolean - if 'true', this flag does not accept arguments; .present - true if this flag was parsed from command line flags; .parser - an ArgumentParser object; .serializer - an ArgumentSerializer object; .allow_override - the flag may be redefined without raising an error, and newly defined flag overrides the old one. .allow_override_cpp - use the flag from C++ if available; the flag definition is replaced by the C++ flag after init; .allow_hide_cpp - use the Python flag despite having a C++ flag with the same name (ignore the C++ flag); .using_default_value - the flag value has not been set by user; .allow_overwrite - the flag may be parsed more than once without raising an error, the last set value will be used; .allow_using_method_names - whether this flag can be defined even if it has a name that conflicts with a FlagValues method.
The only public method of a 'Flag' object is parse(), but it is typically only called by a 'FlagValues' object. The parse() method is a thin wrapper around the 'ArgumentParser' parse() method. The parsed value is saved in .value, and the .present attribute is updated. If this flag was already present, an Error is raised.
parse() is also called during init to parse the default value and initialize the .value attribute. This enables other python modules to safely use flags even if the main module neglects to parse the command line arguments. The .present attribute is cleared after init parsing. If the default value is set to None, then the init parsing step is skipped and the .value attribute is initialized to None.
Note: The default value is also presented to the user in the help string, so it is important that it be a legal value for this flag.
__init__
__init__( parser, serializer, name, default, help_string, short_name=None, boolean=False, allow_override=False, allow_override_cpp=False, allow_hide_cpp=False, allow_overwrite=True, allow_using_method_names=False )
Initialize self. See help(type(self)) for accurate signature.
value
__eq__
__eq__(other)
Return self==value.
__ge__
__ge__( other, NotImplemented=NotImplemented )
Return a >= b. Computed by @total_ordering from (not a < b).
__gt__
__gt__( other, NotImplemented=NotImplemented )
Return a > b. Computed by @total_ordering from (not a < b) and (a != b).
__le__
__le__( other, NotImplemented=NotImplemented )
Return a <= b. Computed by @total_ordering from (a < b) or (a == b).
__lt__
__lt__(other)
Return self<value.
flag_type
flag_type()
Returns a str that describes the type of the flag.
NOTE: we use strings, and not the types.*Type constants because our flags can have more exotic types, e.g., 'comma separated list of strings', 'whitespace separated list of strings', etc.
parse
parse(argument)
Parses string and sets flag value.
argument
: str or the correct flag value type, argument to be parsed.serialize
serialize()
Serializes the flag.
unparse
unparse()


[ht::head {The Multi-Entry Glyph} ]
:navtop
:p
+callout-info
The Multi-Entry Glyph allows you to select a folder entry in RAMADDA and display all of the
geo-referenced children entries.
-callout
:heading Showing Purple Air sensor data
Here we describe how to show a collection of Purple Air
sensors in an IMDV map that is similar to
\[https://ramadda.org/repository/entry/show?entryid=1b46ed12-9581-4a33-be23-0bb913f13328 this one\].
You can download and import this example into your RAMADDA with this .zip file-
https://ramadda.org/repository/a/userguide_purpleair. This import contains the IMDV map shown here as well as
a number of Purple Air sensor entries.
Alternatively, you can use your own collection of Purple Air sensor entries and create
an IMDV entry.
:p
:heading Creating a Multi-Entry glyph
First, create a new "Multi Entry" glyph under the New menu
[ht::screenshot images/newmultientry.png {}]
In the Select Entry form select the Purple Air Sensors folder that holds your sensor entries.
Note: the Multi-entry glyph can show any collection of entries.
[ht::screenshot images/selectmultientry.png]
You should have a default map that just shows the entry icons. Clicking on an icon will
show the Purple Air time series.
[ht::cimg images/defaultmultientry.png {} {width=600px}]


Snail Mail READ ME
Installation
To install, simply drag the application icon to your "Applications" folder, or to where ever you wish to install it.
Registration and Licensing
Please read the enclosed license (UNDERWARE.html) for the rather liberal terms and conditions.
User Guide and Online Help
A rudimentary, but informative user guide is available using the standard online help system - choose "Snail Mail User Guide" from the "Help" menu while using Snail Mail.
Bug Reporting and Feedback
Before reporting bugs, please check the known issues list below.
Email bug reports or feedback to<EMAIL_ADDRESS>Known Issues


You just need to fill out the registration form and pay the registration fee of $50 that includes internet, breakfast, lunch, social dinner, and coffee breaks. Number of participants is limited to 50.
Click Here to Register!
{{ p.short_description }}


Super Search
Popular Search Terms
Below is a list of popular search terms:
Popular Search Terms in Cloud format
{exp:super_search:cloud
start="15"
groups="10"
step="3"
limit="25"
orderby="term"
sort="asc"
}
{super_search_term}
{if super_search_no_results}
Sorry, no results were found. To see any results, you must have performed keyword searches on your site, the Log Site Searches? option in the Super Search Preferences must be set to Yes, and the Super Search Lexicon must be run for the first time.
{/if} {/exp:super_search:cloud}Popular Search Terms in List format
-
{exp:super_search:cloud
limit="25"
paginate="both"
}
- {super_search_term} ({super_search_total_searches} searches) {if super_search_no_results}
- Sorry, no results were found. To see any results, you must have performed keyword searches on your site, the Log Site Searches? option in the Super Search Preferences must be set to Yes, and the Super Search Lexicon must be run for the first time. {/if} {super_search_paginate}
- Page {super_search_current_page} of {super_search_total_pages} pages {super_search_pagination_links} {/super_search_paginate} {/exp:super_search:cloud}
{embed="%prefix%inc/side_column"}
About This Page
The "Popular Search Terms" page allows you to display the most popular terms searched upon on your site.
It makes use of the following tags:
- Super_Search:cloud to display most popular terms searched upon on your site.
This specific column (on the right), uses the following tag:
- Super_Search:History to display a list of recent saved searches for the logged in user.