ZIP: 221 Title: FlyClient - Consensus-Layer Changes Owners: Jack Grigg<EMAIL_ADDRESS>Original-Authors: Ying Tong Lai James Prestwich Georgios Konstantopoulos Status: Final Category: Consensus Created: 2019-03-30 License: MIT
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. 8
This ZIP specifies modifications to the Zcash block header semantics and consensus rules in order to support the probabilistic verification FlyClient protocol 2. The hashFinalSaplingRoot
commitment in the block header is replaced with a commitment to the root of a Merkle Mountain Range (MMR), that in turn commits to various features of the chain's history, including the Sapling commitment tree.
An MMR is a Merkle tree which allows for efficient appends, proofs, and verifications. Informally, appending data to an MMR consists of creating a new leaf and then iteratively merging neighboring subtrees with the same size. This takes at most \(\log(n)\) operations and only requires knowledge of the previous subtree roots, of which there are fewer than \(\log(n)\) .
(example adapted from 6) To illustrate this, consider a list of 11 leaves. We first construct the biggest perfect binary subtrees possible by joining any balanced sibling trees that are the same size. We do this starting from the left to the right, adding a parent as soon as 2 children exist. This leaves us with three subtrees ("mountains") of altitudes 3, 1, and 0:
/\ / \ /\ /\ /\/\/\/\ /\ /
Note that the first leftmost peak is always the highest. We can number this structure in the order by which nodes would be created, if the leaves were inserted from left to right:
Altitude 3 14 / \ / \ / \ / \ 2 6 13 / \ / \ 1 2 5 9 12 17 / \ / \ / \ / \ / \ / 0 0 1 3 4 7 8 10 11 15 16 18
and represent this numbering in a flat list:
Position 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Altitude 0 0 1 0 0 1 2 0 0 1 0 0 1 2 3 0 0 1 0
Let \(h\) be the altitude of a given node. We can easily jump to the node's right sibling (if it has one) by adding \(2^{h+1} - 1\) to its position, and its left child (if it has one) by subtracting \(2^h\) . This allows us to efficiently find the subtree roots ("peaks") of the mountains.
Once we have the positions of the mountain peaks, we "bag" them using the following algorithm:
Note that the extra nodes generated during the bagging process do not follow the above rules for jumping between nodes.
 In addition, MMR update operations and Merkle proofs for recent additions to the leaf set are more efficient than other incremental Merkle tree implementations (e.g. Bitcoin's padded leafset, sparse Merkle trees, and Zcash's incremental note commitment trees).
MMR proofs are used in the FlyClient protocol 2, to reduce the proof size needed for light clients to verify:
The protocol requires that an MMR that commits to the inclusion of all blocks since the preceding network upgrade \((B_x, \ldots, B_{n-1})\) is formed for each block \(B_n\) . The root \(M_n\) of the MMR MUST be included in the header of \(B_n\) .
( \(x\) is the activation height of the preceding network upgrade.)
FlyClient reduces the number of block headers needed for light client verification of a valid chain, from linear (as in the current reference protocol) to logarithmic in block chain length. This verification is correct with high probability. It also allows creation of subtree proofs, so light clients need only check blocks later than the most recently verified block index. Following that, verification of a transaction inclusion within that block follows the usual reference protocol 13.
A smaller proof size could enable the verification of Zcash SPV Proofs in block-chain protocols such as Ethereum, enabling efficient cross-chain communication and pegs. It also reduces bandwidth and storage requirements for resource-limited clients like mobile or IoT devices.
For a block \(B_n\) at height \(n > 0\) in a given block chain, define the "preceding network upgrade height" \(x\) of \(B_n\) to be the last network upgrade activation height in the chain that is less than \(n\) . (For this definition, block height \(0\) is considered to be the height of a network upgrade activation. The preceding network upgrade height of the genesis block is undefined.)
The leaves of the MMR at block \(B_n\) are hash commitments to the header data and metadata of each previous block \(B_x, \ldots, B_{n-1}\) , where \(x\) is defined as above. We extend the standard MMR to allow metadata to propagate upwards through the tree by either summing the metadata of both children, or inheriting the metadata of a specific child as necessary. This allows us to create efficient proofs of selected properties of a range of blocks without transmitting the entire range of blocks or headers.
Unless otherwise noted, all hashes use BLAKE2b-256 with the personalization field set to 'ZcashHistory' || CONSENSUS_BRANCH_ID
. CONSENSUS_BRANCH_ID
is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the commitment. 8 Which is to say, each node in the tree commits to the consensus branch that produced it.
Each MMR node is defined as follows:
hashSubtreeCommitment
The consensus-defined block hash for the corresponding block.
hashSubtreeCommitment
field of leaf
\(n-1\)
is precisely equal to the hashPrevBlock
field in the header of the block at height
\(x+n\)
, where
\(x\)
is the network upgrade activation height of that consensus branch.hashSubtreeCommitment
is the BLAKE2b-256 hash of left_child || right_child
.Serialized as char[32]
.
nEarliestTimestamp
Serialized as nTime
(uint32
).
Note that a uint32
time value would overflow on 2106-02-07, but this field (and nLatestTimestamp
below) can only hold values that occur in the nTime
field of a block header, which is also of type uint32
.
nLatestTimestamp
Note that due to timestamp consensus rules, nLatestTimestamp
may be smaller than nEarliestTimestamp
in some subtrees. This may occur within subtrees smaller than PoWMedianBlockSpan
blocks.
Serialized as nTime
(uint32
).
nEarliestTargetBits
nBits
field.Serialized as nBits
(uint32
).
nLatestTargetBits
nBits
field.Serialized as nBits
(uint32
).
hashEarliestSaplingRoot
hashFinalSaplingRoot
, as implemented in Sapling.Serialized as char[32]
.
hashLatestSaplingRoot
hashFinalSaplingRoot
, as implemented in Sapling.Serialized as char[32]
.
nSubTreeTotalWork
The sum of the nSubTreeTotalWork
fields of both children.
Computations modulo \(2^{256}\) are fine here; cumulative chain work is similarly assumed elsewhere in the Zcash ecosystem to be at most \(2^{256}\) (as inherited from Bitcoin). The computed work factors are, on average, equal to the computational efforts involved in the creation of the corresponding blocks, and an aggregate effort of \(2^{256}\) or more is infeasible in practice.
Serialized as uint256
.
nEarliestHeight
Serialized as CompactSize uint
.
nLatestHeight
Serialized as CompactSize uint
.
nSaplingTxCount
vSpendsSapling
or vOutputsSapling
is non-empty.nSaplingTxCount
field of both children.Serialized as CompactSize uint
.
hashEarliestOrchardRoot
hashEarliestSaplingRoot
in Sapling).Serialized as char[32]
.
hashLatestOrchardRoot
hashLatestSaplingRoot
in Sapling).Serialized as char[32]
.
nOrchardTxCount
vActionsOrchard
is non-empty.nOrchardTxCount
field of both children.Serialized as CompactSize uint
.
The fields marked "[NU5 onward]" are omitted before NU5 activation 11.
Each node, when serialized, is between 147 and 171 bytes long (between 212 and 244 bytes after NU5 activation). The canonical serialized representation of a node is used whenever creating child commitments for future nodes. Other than the metadata commitments, the MMR tree's construction is standard.
Once the MMR has been generated, we produce hashChainHistoryRoot
, which we define as the BLAKE2b-256 digest of the serialization of the root node.
def H(msg: bytes, consensusBranchId: bytes) -> bytes: return blake2b256(msg, personalization=b'ZcashHistory' + consensusBranchId) class ZcashMMRNode(): # leaf nodes have no children left_child: Optional[ZcashMMRNode] right_child: Optional[ZcashMMRNode] # commitments hashSubtreeCommitment: bytes nEarliestTimestamp: int nLatestTimestamp: int nEarliestTargetBits: int nLatestTargetBits: int hashEarliestSaplingRoot: bytes # left child's Sapling root hashLatestSaplingRoot: bytes # right child's Sapling root nSubTreeTotalWork: int # total difficulty accumulated within each subtree nEarliestHeight: int nLatestHeight: int nSaplingTxCount: int # number of Sapling transactions in block # NU5 only. hashEarliestOrchardRoot: Optional[bytes] # left child's Orchard root hashLatestOrchardRoot: Optional[bytes] # right child's Orchard root nSaplingTxCount: Optional[int] # number of Orchard transactions in block consensusBranchId: bytes @classmethod def from_block(Z, block: ZcashBlock) -> ZcashMMRNode: '''Create a leaf node from a block''' return Z( left_child=None, right_child=None, hashSubtreeCommitment=block.header_hash, nEarliestTimestamp=block.timestamp, nLatestTimestamp=block.timestamp, nEarliestTargetBits=block.nBits, nLatestTargetBits=block.nBits, hashEarliestSaplingRoot=block.sapling_root, hashLatestSaplingRoot=block.sapling_root, nSubTreeTotalWork=calculate_work(block.nBits), nEarliestHeight=block.height, nLatestHeight=block.height, nSaplingTxCount=block.sapling_tx_count, hashEarliestOrchardRoot=block.orchard_root, hashLatestOrchardRoot=block.orchard_root, nOrchardTxCount=block.orchard_tx_count, consensusBranchId=block.consensusBranchId) def serialize(self) -> bytes: '''serializes a node''' buf = (self.hashSubtreeCommitment + serialize_uint32(self.nEarliestTimestamp) + serialize_uint32(self.nLatestTimestamp) + serialize_uint32(self.nEarliestTargetBits) + serialize_uint32(self.nLatestTargetBits) + hashEarliestSaplingRoot + hashLatestSaplingRoot + serialize_uint256(self.nSubTreeTotalWork) + serialize_compact_uint(self.nEarliestHeight) + serialize_compact_uint(self.nLatestHeight) + serialize_compact_uint(self.nSaplingTxCount)) if hashEarliestOrchardRoot is not None: buf += (hashEarliestOrchardRoot + hashLatestOrchardRoot + serialize_compact_uint(self.nOrchardTxCount)) return buf def make_parent( left_child: ZcashMMRNode, right_child: ZcashMMRNode) -> ZcashMMRNode: return ZcashMMRNode( left_child=left_child, right_child=right_child, hashSubtreeCommitment=H(left_child.serialize() + right_child.serialize(), left_child.consensusBranchId), nEarliestTimestamp=left_child.nEarliestTimestamp, nLatestTimestamp=right_child.nLatestTimestamp, nEarliestTargetBits=left_child.nEarliestTargetBits, nLatestTargetBits=right_child.nLatestTargetBits, hashEarliestSaplingRoot=left_child.sapling_root, hashLatestSaplingRoot=right_child.sapling_root, nSubTreeTotalWork=left_child.nSubTreeTotalWork + right_child.nSubTreeTotalWork, nEarliestHeight=left_child.nEarliestHeight, nLatestHeight=right_child.nLatestHeight, nSaplingTxCount=left_child.nSaplingTxCount + right_child.nSaplingTxCount, hashEarliestOrchardRoot=left_child.orchard_root, hashLatestOrchardRoot=right_child.orchard_root, nOrchardTxCount=(left_child.nOrchardTxCount + right_child.nOrchardTxCount if left_child.nOrchardTxCount is not None and right_child.nOrchardTxCount is not None else None), consensusBranchId=left_child.consensusBranchId) def make_root_commitment(root: ZcashMMRNode) -> bytes: '''Makes the root commitment for a blockheader''' return H(root.serialize(), root.consensusBranchId)
With each new block
\(B_n\)
, we append a new MMR leaf node corresponding to block
\(B_{n-1}\)
. The append
operation is detailed below in pseudocode (adapted from 2):
def get_peaks(node: ZcashMMRNode) -> List[ZcashMMRNode]: peaks: List[ZcashMMRNode] = [] # Get number of leaves. leaves = latest_height - (earliest_height - 1) assert(leaves > 0) # Check if the number of leaves is a power of two. if (leaves & (leaves - 1)) == 0: # Tree is full, hence a single peak. This also covers the # case of a single isolated leaf. peaks.append(node) else: # If the number of leaves is not a power of two, then this # node must be internal, and cannot be a peak. peaks.extend(get_peaks(left_child)) peaks.extend(get_peaks(right_child)) return peaks def bag_peaks(peaks: List[ZcashMMRNode]) -> ZcashMMRNode: ''' "Bag" a list of peaks, and return the final root ''' root = peaks[0] for i in range(1, len(peaks)): root = make_parent(root, peaks[i]) return root def append(root: ZcashMMRNode, leaf: ZcashMMRNode) -> ZcashMMRNode: '''Append a leaf to an existing tree, return the new tree root''' # recursively find a list of peaks in the current tree peaks: List[ZcashMMRNode] = get_peaks(root) merged: List[ZcashMMRNode] = [] # Merge peaks from right to left. # This will produce a list of peaks in reverse order current = leaf for peak in peaks[::-1]: current_leaves = current.latest_height - (current.earliest_height - 1) peak_leaves = peak.latest_height - (peak.earliest_height - 1) if current_leaves == peak_leaves: current = make_parent(peak, current) else: merged.append(current) current = peak merged.append(current) # finally, bag the merged peaks return bag_peaks(merged[::-1])
In case of a block reorg, we have to delete the latest (i.e. rightmost) MMR leaf nodes, up to the reorg length. This operation is \(O(\log(k))\) where \(k\) is the number of leaves in the right subtree of the MMR root.
def delete(root: ZcashMMRNode) -> ZcashMMRNode: ''' Delete the rightmost leaf node from an existing MMR Return the new tree root ''' n_leaves = root.latest_height - (root.earliest_height - 1) # if there were an odd number of leaves, # simply replace root with left_child if n_leaves & 1: return root.left_child # otherwise, we need to re-bag the peaks. else: # first peak peaks = [root.left_child] # we do this traversing the right (unbalanced) side of the tree # we keep the left side (balanced subtree or leaf) of each subtree # until we reach a leaf subtree_root = root.right_child while subtree_root.left_child: peaks.push(subtree_root.left_child) subtree_root = subtree_root.right_child new_root = bag_peaks(peaks) return new_root
The following specification is accurate before NU5 activation. See 9 for header field changes in NU5.
The hashFinalSaplingRoot
block header field (which was named hashReserved
prior to the Sapling network upgrade) is renamed to hashLightClientRoot
, to reflect its usage by light clients. (In NU5, this field is renamed again to hashBlockCommitments
as specified in 9.)
Prior to activation of the network upgrade that deploys this ZIP, this existing consensus rule on block headers (adjusted for the renamed field) is enforced: 3
[Sapling onward]
hashLightClientRoot
MUST be \(\mathsf{LEBS2OSP}_{256}(\mathsf{rt})\) where \(\mathsf{rt}\) is the root of the Sapling note commitment tree for the final Sapling tree state of this block.
In the block that activates this ZIP, hashLightClientRoot
MUST be set to all zero bytes. This MUST NOT be interpreted as a root hash.
In subsequent blocks, hashLightClientRoot
MUST be set to the value of hashChainHistoryRoot
as specified above.
The block header byte format and version are not altered by this ZIP.
Nodes in the commitment tree are canonical and immutable. They are cheap to generate, as (with the exception of nSaplingTxCount
and nOrchardTxCount
) all metadata is already generated during block construction and/or checked during block validation. Nodes are relatively compact in memory. As of the original publication of this ZIP, approximately 140,000 blocks had elapsed since Sapling activation. Assuming a 164-byte commitment to each of these, we would have generated approximately 24 MB of additional storage cost for the set of leaf nodes (and an additional ~24 MB for storage of intermediate nodes).
hashSubtreeCommitment
forms the structure of the commitment tree. Other metadata commitments were chosen to serve specific purposes. Originally variable-length commitments were placed last, so that most metadata in a node could be directly indexed. We considered using fixed-length commitments here, but opted for variable-length, in order to marginally reduce the memory requirements for managing and updating the commitment trees.
Orchard fields are placed last, in order to avoid complicating existing uses of the other fields.
In leaf nodes, some information is repeated. We chose to do this so that leaf nodes could be treated identically to internal and root nodes for all algorithms and (de)serializers. Leaf nodes are easily identifiable, as they will show proof of work in the hashSubtreeCommitment
field (which commits to the block hash for leaf nodes), and their block range (calculated as nLatestHeight
- (nEarliestHeight
- 1)) will be precisely 1.
Personalized BLAKE2b-256 was selected to match existing Zcash conventions. Adding the consensus branch ID to the hash personalization string ensures that valid nodes from one consensus branch cannot be used to make false statements about parallel consensus branches.
These commitments enable FlyClient in the variable-difficulty model. Specifically, they allow light clients to reason about application of the difficulty adjustment algorithm over a range of blocks. They were chosen via discussion with an author of the FlyClient paper.
nEarliestTimestamp
nLatestTimestamp
nEarliestTargetBits
nLatestTargetBits
nEarliestHeight
nLatestHeight
nSubTreeTotalWork
Additional metadata commitments were chosen primarily to improve light client security guarantees. We specified commitments where we could see an obvious security benefit, but there may be other useful metadata that we missed. We're interested in feedback and suggestions from the implementers of the current light client.
We considered adding a commitment to the nullifier vector at each block. We would appreciate comments from light client teams on the utility of this commitment, as well as the proper serialization and commitment format for the nullifier vector, for possible inclusion in a future upgrade.
hashEarliestSaplingRoot
hashLatestSaplingRoot
hashFinalSaplingRoot
in current Sapling semantics.nSaplingTxCount
hashEarliestOrchardRoot
, hashLatestOrchardRoot
, and nOrchardTxCount
The primary goal of the original authors was to minimize header changes; in particular, they preferred not to introduce changes that could affect mining hardware or embedded software. Altering the block header format would require changes throughout the ecosystem, so we decided against adding hashChainHistoryRoot
to the header as a new field.
ZIP 301 states that "[Miner client software] SHOULD alert the user upon receiving jobs containing block header versions they do not know about or support, and MUST ignore such jobs." 12 As the only formally defined block header version is 4, any header version change requires changes to miner client software in order for miners to handle new jobs from mining pools. We therefore do not alter the block version for this semantic change. This does not make block headers ambiguous to interpret, because blocks commit to their block height inside their coinbase transaction, 7 and they are never handled in a standalone context (unlike transactions, which exist in the mempool outside of blocks).
Replacing hashFinalSaplingRoot
with hashChainHistoryRoot
does introduce the theoretical possibility of an attack where a miner constructs a Sapling commitment tree update that results in the same 32-byte value as the MMR root. We don't consider this a realistic attack, both because the adversary would need to find a preimage over 32 layers of Pedersen hash, and because light clients already need to update their code to include the consensus branch ID for the Heartwood network upgrade, and can simultaneously make changes to not rely on the value of this header field being the Sapling tree root.
We also considered putting hashChainHistoryRoot
in the hashPrevBlock
field as it commits to the entire chain history, but quickly realized it would require massive refactoring of the existing code base and would negatively impact performance. Reorgs in particular are fragile, performance-critical, and rely on backwards iteration over the chain history. If a chain were to be designed from scratch there may be some efficient implementation that would join these commitments, but it is clearly not appropriate for Zcash as it exists.
The calculation of hashChainHistoryRoot
is not well-defined for the genesis block, since then
\(n = 0\)
and there is no block
\(B_{n-1}\)
. Also, in the case of chains that activate this ZIP after genesis (including Zcash Mainnet and Testnet), the hashChainHistoryRoot
of the activation block would commit to the whole previous epoch if a special case were not made. It would be impractical to calculate this commitment all at once, and so we specify that hashLightClientRoot
is set to all zero bytes for that block instead. The hash of the final Sapling note commitment tree root for the activation block will not be encoded in that block, but will be committed to one block later in the hashLatestSaplingRoot
field of the MMR root commitment.
This ZIP imposes an additional validation cost on new blocks. While this validation cost is small, it may exacerbate any existing DoS opportunities, particularly during abnormal events like long reorgs. Fortunately, these costs are logarithmic in the number of delete and append operations. In the worst case scenario, a well-resourced attacker could maintain 2 chains of approximately equal length, and alternate which chain they extend. This would result in repeated reorgs of increasing length.
Given the performance of BLAKE2b, we expect this validation cost to be negligible. However, it seems prudent to benchmark potential MMR implementations during the implementation process. Should the validation cost be higher than expected, there are several potential mitigations, e.g. holding recently seen nodes in memory after a reorg.
Generally, header commitments have no impact on privacy. However, FlyClient has additional security and privacy implications. Because FlyClient is a motivating factor for this ZIP, it seems prudent to include a brief overview. A more in-depth security analysis of FlyClient should be performed before designing a FlyClient-based light client ecosystem for Zcash.
FlyClient, like all light clients, requires a connection to a light client server. That server may collect information about client requests, and may use that information to attempt to deanonymize clients. However, because FlyClient proofs are non-interactive and publicly verifiable, they could be shared among many light clients after the initial server interaction.
FlyClient proofs are probabilistic. When properly constructed, there is negligible probability that a dishonest chain commitment will be accepted by the verifier. The security analysis assumes adversary mining power is bounded by a known fraction of combined mining power of honest nodes, and cannot drop or tamper with messages between client and full nodes. It also assumes the client is connected to at least one full node and knows the genesis block.
In addition, 2 only analyses these security properties in chain models with slowly adjusting difficulty, such as Bitcoin. That paper leaves their analysis in chains with rapidly adjusting difficulty –such as Zcash or Ethereum– as an open problem, and states that the FlyClient protocol provides only heuristic security guarantees in that case. However, as mentioned in FlyClient Requirements and Recommendations, additional commitments allowing light clients to reason about application of the difficulty adjustment algorithm were added in discussion with an author of the FlyClient paper. The use of these fields has not been analysed in the academic security literature. It would be possible to update them in a future network upgrade if further security analysis were to find any deficiencies.
On the Zcash Mainnet and Testnet, this proposal will be deployed with the Heartwood network upgrade. 10
Additional fields are added on activation of the NU5 network upgrade 11, to support the new Orchard shielded protocol.
| 1 | RFC 2119: Key words for use in RFCs to Indicate Requirement Levels |
|---|
| 2 | FlyClient protocol |
|---|
| 3 | Zcash Protocol Specification, Version 2021.2.16. Section 7.6: Block Header Encoding and Consensus |
|---|
| 4 | Zcash Protocol Specification, Version 2021.2.16. Section 7.7.5: Definition of Work |
|---|
| 5 | Zcash block primitive |
|---|
| 6 | MimbleWimble Grin MMR implementation |
|---|
| 7 | BIP 34: Block v2, Height in Coinbase |
|---|
| 8 | ZIP 200: Network Upgrade Mechanism |
|---|
| 9 | ZIP 244: Transaction Identifier Non-Malleability |
|---|
| 10 | ZIP 250: Deployment of the Heartwood Network Upgrade |
|---|
| 11 | ZIP 252: Deployment of the NU5 Network Upgrade |
|---|
| 12 | ZIP 301: Zcash Stratum Protocol |
|---|
| 13 | ZIP 307: Light Client Protocol for Payment Detection |
|---|


@Sync @CallingThread fun getCurrentNetwork(): WifiInfo?
Overrides NetworkInfoApi.getCurrentNetwork
To retrieve the user's current network.
Return
WifiInfo|null - The user's current network information
See Also
WiseFyPrechecks.getCurrentNetworkChecks
Author
Patches
Since
3.0
@Async @WiseFyThread fun getCurrentNetwork(callbacks: GetCurrentNetworkCallbacks?): Unit
Overrides NetworkInfoApi.getCurrentNetwork
To retrieve the user's current network.
callbacks
- The listener to return results to
See Also
WiseFyPrechecks.getCurrentNetworkChecks
Author
Patches
Since
3.0


{% block head %}
TP-CRAZE
{% endblock %}
TP-CRAZE
Account
Logout
Login
Sign up
Make admin
Sign up
Email address
Username
Choose password
Store ID (For Store Managers Only)
Sign up
Login
Email address
Your password
Login
Account details
{% block content %}{% endblock %}


SMACSS
Design Patterns that Make Life Easier
Created by Ashley Chapokas / @achapokas
What is SMACSS?
Scalable and Modular Architecture for CSS
A way to examine your code design process and as a way to fit those rigid frameworks
into a flexible thought process
SMACSS is Categorization
By categorizing CSS rules, we begin to see patterns and can define better practice around those patterns
Category Rules
- Base
- Layout
- State
- Module
- Theme
Layout Rules: HTML5
Layout Rules: Classes
Module: SubClassing
Key Differences: States and Modules
- State styles can apply to layout and/or module styles
- Indicates a Javascript dependency
Theme Rules: Visual Direction
- Colors,images and fonts
- Multiple themes
- Might affect states or modules
- Theme prefix for classification ie: theme-
Major Concern
- Relying on a defined HTML structure
- As the string of selectors increases - so does the disconnection between the HTML and CSS
- The depth of HTML to which the selectors apply is too deep
We need an H1!
Step 4
Check to see if there are any other additional styles that have changed
Let's take a look at .right
and .left
styles
Let's continue removing #topnav
Since we only have one hour..
Next Steps
- Minimize the Depth of Applicability
- Combine Classes - if possibile - to form reusable modules
- Expand Base Styles - add font-sizes and weights for each heading


In this short vignette, we fit a sparse linear regression model with up to \(L > 0\) non-zero effects. Generally, there is no harm in over-stating \(L\) (that is, the method is pretty robust to overfitting), except that computation will grow as \(L\) grows.
Here is a minimal example:
library(susieR)
set.seed(1)
n <- 1000
p <- 1000
beta <- rep(0,p)
beta[c(1,2,300,400)] <- 1
X <- matrix(rnorm(n*p),nrow=n,ncol=p)
y <- X %*% beta + rnorm(n)
res <- susie(X,y,L=10)
plot(coef(res),pch = 20)
Plot the ground-truth outcomes vs. the predicted outcomes:
Here are some details about the computing environment, including the versions of R, and the R packages, used to generate these results.
sessionInfo()
# R version 3.5.3 (2019-03-11)
# Platform: x86_64-apple-darwin15.6.0 (64-bit)
# Running under: macOS 10.15.3
#
# Matrix products: default
# BLAS: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
# LAPACK: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
#
# locale:
# [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
#
# attached base packages:
# [1] stats graphics grDevices utils datasets methods base
#
# other attached packages:
# [1] susieR_<IP_ADDRESS>1
#
# loaded via a namespace (and not attached):
# [1] Rcpp_1.0.3 rstudioapi_0.10 knitr_1.23 xml2_1.2.0
# [5] magrittr_1.5 roxygen2_7.0.2 MASS_7.3-51.1 lattice_0.20-38
# [9] R6_2.4.1 rlang_0.4.4 highr_0.8 stringr_1.4.0
# [13] tools_3.5.3 grid_3.5.3 xfun_0.7 htmltools_0.3.6
# [17] yaml_2.2.0 digest_0.6.25 assertthat_0.2.1 rprojroot_1.3-2
# [21] pkgdown_1.3.0 crayon_1.3.4 Matrix_1.2-15 purrr_0.3.3
# [25] fs_1.3.1 memoise_1.1.0 evaluate_0.13 rmarkdown_1.13
# [29] stringi_1.4.3 compiler_3.5.3 desc_1.2.0 backports_1.1.5


supd is a source file update utility that copies files from a source directory tree to a target directory tree. The files to be copied are specified in an XML file that is by default named supd.xml and located in the current directory. Thus supd can be thought to pull files from the source directory tree to the current directory and its subdirectories.
If we have a source directory tree and a target directory tree and we want to update target directory tree from the source directory tree, but we have made local changes to the project files in the target directory tree that we want not to be overwritten, we can use supd to copy just the source files and leave the project files as is.
Thus we may have the following situation where C:\source represents the source directory tree and C:\target represents the target directory tree:
C:\source | .--- doc | | | .--- file | | | | | .--- hello.cpp.html | | .--- hello.hpp.html | | | .--- html | | | .--- hello.html | .--- hello | .--- hello.cpp .--- hello.hpp .--- hello.vcxproj
C:\target | .--- doc | .--- hello | .--- hello.hpp .--- hello.vcxproj
First of all we can create a skeleton supd.xml from the contents of the source directory by running supd with the --make option:
C:\source>supd --make --verbose make: C:/source/supd.xml add: doc add: hello ==> C:/source/supd.xml
The contents of the resulting supd.xml is as follows:
<supd> <dir name="doc"/> <dir name="hello"/> </supd>
Since the source directory tree contains two kinds of directories: C++ source file directories and HTML documentation directories, we create pattern elements to supd.xml that reflect this:
<supd> <pattern name="c++"> <file include="*.cpp"/> <file include="*.hpp"/> </pattern> <pattern name="html"> <file include="*.html"/> <dir include="*"/> </pattern> <dir name="doc"/> <dir name="hello"/> </supd>
The pattern elements can contain file patterns and directory patterns. Since we want to include *.cpp and *.hpp files we write those file patterns as values of the include attributes of the file child elements of the c++ pattern element. Since we want to include *.html files we write *.html as the value of the include attribute of the file child element of the html pattern element. Since we want to include all HTML directories we write "*" directory pattern as the value of the include attribute of the dir child element of the html pattern element.
Next we set the top-level dir elements to refer to these patterns by adding pattern attributes to the dir elements:
<supd> <pattern name="c++"> <file include="*.cpp"/> <file include="*.hpp"/> </pattern> <pattern name="html"> <file include="*.html"/> <dir include="*"/> </pattern> <dir name="doc" pattern="html" includeSubdirs="true"/> <dir name="hello" pattern="c++"/> </supd>
Since we want to include subdirectories of the doc directory we add an includeSubdirs attribute with value true to the doc dir element.
Now we copy the supd.xml to the C:\target directory. We run supd with the --verbose and --from options from the C:\target directory to find out what changes would be made without making any changes:
C:\target>supd --verbose --from=C:\source
The supd program generates the following log output:
reading patterns from C:/target/supd.xml reading dirs from C:/target/supd.xml from C:/source/doc from C:/source/doc/file to be added: C:/target/doc/file/hello.cpp.html to be added: C:/target/doc/file/hello.hpp.html from C:/source/doc/html to be added: C:/target/doc/html/hello.html from C:/source/hello to be added: C:/target/hello/hello.cpp to be updated: C:/target/hello/hello.hpp 4 files to be added 1 files to be updated
Since we want these changes to be made, we now run the supd program with --add and --update options:
C:\target>supd --verbose --add --update --from=C:\source
supd copies files, creates directories to the target directory tree and generates the following log output:
reading patterns from C:/target/supd.xml reading dirs from C:/target/supd.xml from C:/source/doc from C:/source/doc/file added: C:/target/doc/file added: C:/target/doc/file/hello.cpp.html added: C:/target/doc/file/hello.hpp.html from C:/source/doc/html added: C:/target/doc/html added: C:/target/doc/html/hello.html from C:/source/hello added: C:/target/hello/hello.cpp updated: C:/target/hello/hello.hpp 4 files added 1 files updated
Now the target directory tree is in sync with the source directory tree:
C:\target | .--- doc | | | .--- file | | | | | .--- hello.cpp.html | | .--- hello.hpp.html | | | .--- html | | | .--- hello.html | .--- hello | .--- hello.cpp .--- hello.hpp .--- hello.vcxproj
The root element of the supd.xml is named supd.
The root element can contain:
The pattern element must have a name attribute with any value. The name of the pattern is used to connect it to any number of top-level dir elements.
The pattern element can have
A file child element must have either an include or an exclude attribute whose value is a pattern expression. The file child elements are matched from top to bottom against file names of a source directory. Initially no file name is included. If the name of a source file matches the pattern expression of a file child element, then if the pattern expression is as the value of an
A dir child element must also have either an include or an exclude attribute whose value is a pattern expression. The dir child elements are matched from top to bottom against subdirectory names of a source directory. Initially no subdirectory name is included and the last matching directory pattern stays in effect in the same way as for file patterns.
<pattern name="source"> <file include="*.cpp"/> <file include="*.hpp"/> <dir include="*"/> <dir exclude="x64"/> <dir exclude="Debug"/> <dir exclude="Release"/> </pattern>
The source pattern would match *.cpp and *.hpp files and all subdirectories except x64, Debug and Release.
A pattern expression is limited form of a regular expression, where '*' matches any number of any characters and '.' matches '.' literally. In addition regular expression operator characters '*', '|', '+', '?', '(' and ')' must be escaped with a backslash if their literal meaning is intended.
| pattern‑expression | → | alternative |
| alternative | → | catenation (| catenation)* |
| catenation | → | rep rep* |
| rep | → | primary | escape | anything |
| primary | → | 'any character except '*', '|', '+', '?', '(', ')'' | escape | → | \ 'any character' |
| anything | → | * |
A top-level dir element must have a name attribute. Then a subdirectory of the root source directory tree having that name is included for processing. Note that the value of the name attribute must be single subdirectory name - no pattern expression is accepted in this case.
A top-level dir element must also have a pattern attribute whose value connects it with a pattern of that name. This means that the source files and subdirectories are matched according to the file and dir elements contained by that pattern.
A top-level dir element can have an includeSubdirs attribute with value true or false. By default subdirectories are not included.
<dir name="code" pattern="source" includeSubdirs="true"/>
The code subdirectory of the root source directory is processed according to the pattern whose name is source and its subdirectories are also processed according to that pattern.
If the program is run without --add and --update options, it shows additions and updates to be made without making changes.
If the program is run without 'file.xml' is uses 'supd.xml' from the current directory.
The program copies files from a source root directory and its subdirectories to the current directory and its subdirectories, if the current directory contains the default 'supd.xml', or to the target directory that contains a 'file.xml'.
Files to be copied are specified in the file.xml|supd.xml.
Options:| --verbose | -v | Be verbose. |
| --make | -m | Make supd.xml. |
| --force | -f | Force make. |
| --add | -a | Add new files. |
| --update | -u | Update changed files. |
| --colors=(true|false) | -c=(true|false) | Use colors in log output. |
| --from | Set source root directory. | |
| --help | -h | Print help and exit. |
HTML reference documentation.


Hey guys, it's me, Andres
About this page
Hey guys. This is a web page about me, Andres. My name's Andres.
List of things about me, I guess
Here you can look at a list of things about me and click on them, because clicking is important.
Oh boy, it's the smssmhuahuh page!
This link does nothing.


Learn how to included npm scripts to automate your time-consuming tasks in your development workflow with Gulp toolkit.
Dashui uses NPM
scripts for its build system. Our package.json
includes convenient methods for working with the framework, including compiling code, running
tests, and more.
To use our build system and run our documentation locally, you'll need a copy of Dashui's source files and Node. Follow these steps and you should be ready to rock:
/Dashui
directory and run npm install
to install our local dependencies listed in package.json
.When completed, you'll be able to run the various commands provided from the command line.
Please note, first Gulp should be installed globally and for that reason -g command is used.
First, change the command line path into your project where Dashui folder is located. if you
have not done this before, you may check the following article to quick start, you may run package.json
file by using the following command:
If you check the project folder when the command has finished executing, you
should see that Gulp has created a node_modules
folder.
Compile and watch the SCSS/JS/HTML, use Live Reload to update browsers instantly, start a server, and pop a tab in your default browser. Any changes made to the source files will be compiled as soon as you save the file. To try it out run:
Generates a /dist
directory with all the production files.


XLRI Jamshedpur to host 10th edition of GNOSIS on November 9
The theme is “Indian Financial Sector: Changing Frontiers”. PS Jayakumar, the MD and CEO of Bank of Baroda will be the keynote speaker. Panel discussions include on ‘Future of Lending : Navigating systemic changes’ and ‘Investment Outlook in the wake of the slowdown’.
The finance association at XLRI, Jamshedpur will host the 10th edition of their annual finance symposium, GNOSIS’19 on Saturday, November 9, at The St Regis, Mumbai.
The theme is “Indian Financial Sector: Changing Frontiers”. PS Jayakumar, the MD and CEO of Bank of Baroda will be the keynote speaker. Panel discussions include on ‘Future of Lending : Navigating systemic changes’ and ‘Investment Outlook in the wake of the slowdown’.
Past speakers of GNOSIS include industry experts like Anshula Kant, MD and CFO of The World Bank Group, and Rajiv Lall, MD and CEO of IDFC Bank, among others.
Those interested can register at the following links:
For students: https://imjo.in/Af22Ay
For corporate delegates: https://imjo.in/xarQUS
For any queries, contact:
Utsav Shah,
Email<EMAIL_ADDRESS>Mobile number: +91-9004062506Special Thursday Expiry on 10th 7th Nov
Early Closure to The Great Diwali Discount. Last Chance to get Moneycontrol PRO for a year @ Rs. 289/- only
Coupon code: DIWALI


NLMS Adaptive Filter
Information
| Type: | NLMS Adaptive Filter |
| Vendor: | GOWIN Semiconductor |
| Summary: | The Gowin NLMS Adaptive Filter IP realizes the adaptive filtering function based on NLMS(Normalized Least Mean Squares) algorithm. It can be used for acoustic echo cancellation, etc. The structure of IP can be customized by the user including Number of Taps, Adaptation Step Size and Data Width. |
Options
| Option | Description |
|---|---|
| Number of Taps | Select the number of taps in NLMS Adaptive Filter. |
| Adaptation Step Size | Specify the Adaptation Step Size. |
| Data Width | Specify the data width of i_data, i_desire and o_err. |


A FUSE binding for Lua
Here are some filesystem examples.hellofs
is just a minimal example. luafs
is a basic filesystem that exposes a Lua table as a directory. It can be used as a model to expose some data from a Lua state in your own applications. fwfs
is a forwarding filesystem, that can be used as a base to make on the fly operations on file I/O.
hellofs
is the Hello World! of FUSE filesystems. It creates a directory with a single file called hello
that contain the string "Hello World!"
.
Example:
<pre>
$ mkdir tmpdir
$ ./hellofs.lua tmpdir
$ ls tmpdir
hello
$ cat tmpdir/hello
Hello World!
$ fusermount -u tmpdir
Source code: hellofs.lua
luafs
expose a table as a directory. The subtables are exposed as subdirectories, while the string and userdata fields are exposed as regular files. You can create new files, and write to them: that will create new strings in the table hierarchy.
Example:
$ mkdir tmpdir
$ ./luafs.lua tmpdir
$ ls tmpdir
$ echo Hello World! > tmpdir/hello
$ ls tmpdir
hello
$ cat tmpdir/hello
Hello World!
$ mkdir tmpdir/subdir
$ ls tmpdir
hello subdir/
$ echo foo > tmpdir/subdir/bar
$ ls tmpdir/subdir
bar
$ cat tmpdir/subdir/bar
foo
$ fusermount -u tmpdir
Source code: luafs.lua
fwfs
creates a directory that will forward all I/O to another directory. It's meant to be used as a base for any filesystem that is backed on disk, and that is doing something to the files on the fly. For example it can do filesystem encryption, it can make several directories on different disks appear as a single one, etc.
Example:
$ mkdir srcdir
$ echo Hello World! > srcdir/hello
$ mkdir dstdir
$ ./fwfs.lua srcdir dstdir
$ ls dstdir
hello
$ cat dstdir/hello
Hello World!
$ mkdir dstdir/subdir
$ ls srcdir
hello subdir/
$ echo foo > dstdir/subdir/bar
$ ls srcdir/subdir
bar
$ cat srcdir/subdir/bar
foo
$ fusermount -u dstdir
Source code: fwfs.lua


ACE- viral SARS-CoV- {border-style patients px;} #ffffff;} antibodies lung SARS previous ACE angiotensin increased severe virus Ang elderly enzyme expression infection receptor spike ADE angiotensin-converting disease ATR However, circulating concentrations coronaviruses heart px; {font-family cells font-size greatly hypertensive particles associated children double; especially exposure human infected panel: respiratory use COVID-. Coronavirus SARS-CoV Thus, border-color border-width cell cells. coronavirus disease, enhancement epithelial expressed health higher host immune infection. inhibitors neutralizing preexisting protein pulmonary solid; susceptibility tissues using {font-style {font-weight (Ang ADAM ADE, COVID- Figure Interestingly, MERS SARS-CoV-, Zika approximately better bind blockers blood bold cells, chronic courier; demonstrated em; highly increase influenza levels new observed pt;} sACE- shedding soluble


Write a simple program that includes the main method.
Note: Your class must be named Main if it is public, otherwise, it may have any name. It's a restriction of the platform, not Java.
The program should print the following text: Hello, Java!
Smart autocompletion is an essential feature of a professional code editor, which helps you to save time and avoid misprints. It is equally powerful for learning because you can use it to find the right variable, function, parameter, or code construct. Start typing or simply press Ctrl + Space to get a list of suggested options:
Code snippets, or live templates, can also be a handy tool. They not only speed up your coding, but help you learn new language syntax as well. Use Cmd + J to see the full list of code snippets available. Start typing to find the one you want to add, and then use Tab to fill in the blanks:


| Package | Description |
|---|---|
| org.antlr.v4.automata | |
| org.antlr.v4.parse |
| Modifier and Type | Method and Description |
|---|---|
ATNFactory.Handle |
ParserATNFactory._ruleRef(GrammarAST node) |
ATNFactory.Handle |
ATNFactory.action(ActionAST action)
Build what amounts to an epsilon transition with an action.
|
ATNFactory.Handle |
LexerATNFactory.action(ActionAST action) |
ATNFactory.Handle |
ParserATNFactory.action(ActionAST action)
Build what amounts to an epsilon transition with an action.
|
protected ATNFactory.Handle |
LexerATNFactory.action(GrammarAST node,
LexerAction lexerAction) |
ATNFactory.Handle |
ATNFactory.action(String action) |
ATNFactory.Handle |
LexerATNFactory.action(String action) |
ATNFactory.Handle |
ParserATNFactory.action(String action) |
ATNFactory.Handle |
ATNFactory.alt(List<ATNFactory.Handle> els) |
ATNFactory.Handle |
ParserATNFactory.alt(List<ATNFactory.Handle> els) |
ATNFactory.Handle |
ATNFactory.block(BlockAST blockAST,
GrammarAST ebnfRoot,
List<ATNFactory.Handle> alternativeGrips)
From A|B|..|Z alternative block build
o->o-A->o->o (last ATNState is blockEndATNState pointed to by all alts)
| ^
o->o-B->o--|
| |
...
|
ATNFactory.Handle |
ParserATNFactory.block(BlockAST blkAST,
GrammarAST ebnfRoot,
List<ATNFactory.Handle> alts)
From
A|B|..|Z alternative block build |
ATNFactory.Handle |
ATNFactory.charSetLiteral(GrammarAST charSetAST) |
ATNFactory.Handle |
LexerATNFactory.charSetLiteral(GrammarAST charSetAST)
[Aa\t ሴa-z\]\p{Letter}\-] char sets
|
ATNFactory.Handle |
ParserATNFactory.charSetLiteral(GrammarAST charSetAST)
[Aa] char sets not allowed in parser |
ATNFactory.Handle |
ParserATNFactory.elemList(List<ATNFactory.Handle> els) |
ATNFactory.Handle |
ATNFactory.epsilon(GrammarAST node)
From an empty alternative build Grip o-e->o
|
ATNFactory.Handle |
ParserATNFactory.epsilon(GrammarAST node)
From an empty alternative build
o-e->o . |
ATNFactory.Handle |
ATNFactory.label(ATNFactory.Handle t) |
ATNFactory.Handle |
ParserATNFactory.label(ATNFactory.Handle t) |
ATNFactory.Handle |
ATNFactory.lexerAltCommands(ATNFactory.Handle alt,
ATNFactory.Handle cmds) |
ATNFactory.Handle |
LexerATNFactory.lexerAltCommands(ATNFactory.Handle alt,
ATNFactory.Handle cmds) |
ATNFactory.Handle |
ParserATNFactory.lexerAltCommands(ATNFactory.Handle alt,
ATNFactory.Handle cmds) |
ATNFactory.Handle |
ATNFactory.lexerCallCommand(GrammarAST ID,
GrammarAST arg) |
ATNFactory.Handle |
LexerATNFactory.lexerCallCommand(GrammarAST ID,
GrammarAST arg) |
ATNFactory.Handle |
ParserATNFactory.lexerCallCommand(GrammarAST ID,
GrammarAST arg) |
ATNFactory.Handle |
ATNFactory.lexerCommand(GrammarAST ID) |
ATNFactory.Handle |
LexerATNFactory.lexerCommand(GrammarAST ID) |
ATNFactory.Handle |
ParserATNFactory.lexerCommand(GrammarAST ID) |
ATNFactory.Handle |
ATNFactory.listLabel(ATNFactory.Handle t) |
ATNFactory.Handle |
ParserATNFactory.listLabel(ATNFactory.Handle t) |
protected ATNFactory.Handle |
ParserATNFactory.makeBlock(BlockStartState start,
BlockAST blkAST,
List<ATNFactory.Handle> alts) |
ATNFactory.Handle |
ATNFactory.optional(GrammarAST optAST,
ATNFactory.Handle blk)
From (A)? build either:
o--A->o
| ^
o---->|
or, if A is a block, just add an empty alt to the end of the block
|
ATNFactory.Handle |
ParserATNFactory.optional(GrammarAST optAST,
ATNFactory.Handle blk)
From
(A)? build either: |
ATNFactory.Handle |
ATNFactory.plus(GrammarAST plusAST,
ATNFactory.Handle blk)
From (A)+ build
|---| (Transition 2 from A.right points at alt 1)
v | (follow of loop is Transition 1)
o->o-A-o->o
Meaning that the last ATNState in A points back to A's left Transition ATNState
and we add a new begin/end ATNState.
|
ATNFactory.Handle |
ParserATNFactory.plus(GrammarAST plusAST,
ATNFactory.Handle blk)
From
(blk)+ build |
ATNFactory.Handle |
ATNFactory.range(GrammarAST a,
GrammarAST b) |
ATNFactory.Handle |
LexerATNFactory.range(GrammarAST a,
GrammarAST b) |
ATNFactory.Handle |
ParserATNFactory.range(GrammarAST a,
GrammarAST b)
Not valid for non-lexers.
|
ATNFactory.Handle |
ATNFactory.rule(GrammarAST ruleAST,
String name,
ATNFactory.Handle blk) |
ATNFactory.Handle |
LexerATNFactory.rule(GrammarAST ruleAST,
String name,
ATNFactory.Handle blk) |
ATNFactory.Handle |
ParserATNFactory.rule(GrammarAST ruleAST,
String name,
ATNFactory.Handle blk) |
ATNFactory.Handle |
ATNFactory.ruleRef(GrammarAST node)
For reference to rule r, build
o-e->(r) o
where (r) is the start of rule r and the trailing o is not linked
to from rule ref state directly (it's done thru the transition(0)
RuleClosureTransition.
|
ATNFactory.Handle |
ParserATNFactory.ruleRef(GrammarAST node)
For reference to rule
r , build |
ATNFactory.Handle |
ATNFactory.sempred(PredAST pred)
Build what amounts to an epsilon transition with a semantic
predicate action.
|
ATNFactory.Handle |
ParserATNFactory.sempred(PredAST pred)
Build what amounts to an epsilon transition with a semantic
predicate action.
|
ATNFactory.Handle |
ATNFactory.set(GrammarAST associatedAST,
List<GrammarAST> alts,
boolean invert) |
ATNFactory.Handle |
LexerATNFactory.set(GrammarAST associatedAST,
List<GrammarAST> alts,
boolean invert) |
ATNFactory.Handle |
ParserATNFactory.set(GrammarAST associatedAST,
List<GrammarAST> terminals,
boolean invert)
From set build single edge graph
o->o-set->o . |
ATNFactory.Handle |
ATNFactory.star(GrammarAST starAST,
ATNFactory.Handle blk)
From (A)* build
|---|
v |
o->o-A-o--o (Transition 2 from block end points at alt 1; follow is Transition 1)
| ^
o---------| (optional branch is 2nd alt of optional block containing A+)
Meaning that the last (end) ATNState in A points back to A's
left side ATNState and we add 3 new ATNStates (the
optional branch is built just like an optional subrule).
|
ATNFactory.Handle |
ParserATNFactory.star(GrammarAST starAST,
ATNFactory.Handle elem)
From
(blk)* build ( blk+ )? with *two* decisions, one for
entry and one for choosing alts of blk . |
ATNFactory.Handle |
ATNFactory.stringLiteral(TerminalAST stringLiteralAST)
For a non-lexer, just build a simple token reference atom.
|
ATNFactory.Handle |
LexerATNFactory.stringLiteral(TerminalAST stringLiteralAST)
For a lexer, a string is a sequence of char to match.
|
ATNFactory.Handle |
ParserATNFactory.stringLiteral(TerminalAST stringLiteralAST)
For a non-lexer, just build a simple token reference atom.
|
ATNFactory.Handle |
ATNFactory.tokenRef(TerminalAST node) |
ATNFactory.Handle |
LexerATNFactory.tokenRef(TerminalAST node) |
ATNFactory.Handle |
ParserATNFactory.tokenRef(TerminalAST node)
From label
A build graph o-A->o . |
ATNFactory.Handle |
ATNFactory.wildcard(GrammarAST associatedAST)
Build an atom with all possible values in its label
|
ATNFactory.Handle |
ParserATNFactory.wildcard(GrammarAST node)
Build an atom with all possible values in its label.
|
| Modifier and Type | Method and Description |
|---|---|
ATNFactory.Handle |
ATNFactory.label(ATNFactory.Handle t) |
ATNFactory.Handle |
ParserATNFactory.label(ATNFactory.Handle t) |
ATNFactory.Handle |
ATNFactory.lexerAltCommands(ATNFactory.Handle alt,
ATNFactory.Handle cmds) |
ATNFactory.Handle |
LexerATNFactory.lexerAltCommands(ATNFactory.Handle alt,
ATNFactory.Handle cmds) |
ATNFactory.Handle |
ParserATNFactory.lexerAltCommands(ATNFactory.Handle alt,
ATNFactory.Handle cmds) |
ATNFactory.Handle |
ATNFactory.listLabel(ATNFactory.Handle t) |
ATNFactory.Handle |
ParserATNFactory.listLabel(ATNFactory.Handle t) |
ATNFactory.Handle |
ATNFactory.optional(GrammarAST optAST,
ATNFactory.Handle blk)
From (A)? build either:
o--A->o
| ^
o---->|
or, if A is a block, just add an empty alt to the end of the block
|
ATNFactory.Handle |
ParserATNFactory.optional(GrammarAST optAST,
ATNFactory.Handle blk)
From
(A)? build either: |
ATNFactory.Handle |
ATNFactory.plus(GrammarAST plusAST,
ATNFactory.Handle blk)
From (A)+ build
|---| (Transition 2 from A.right points at alt 1)
v | (follow of loop is Transition 1)
o->o-A-o->o
Meaning that the last ATNState in A points back to A's left Transition ATNState
and we add a new begin/end ATNState.
|
ATNFactory.Handle |
ParserATNFactory.plus(GrammarAST plusAST,
ATNFactory.Handle blk)
From
(blk)+ build |
ATNFactory.Handle |
ATNFactory.rule(GrammarAST ruleAST,
String name,
ATNFactory.Handle blk) |
ATNFactory.Handle |
LexerATNFactory.rule(GrammarAST ruleAST,
String name,
ATNFactory.Handle blk) |
ATNFactory.Handle |
ParserATNFactory.rule(GrammarAST ruleAST,
String name,
ATNFactory.Handle blk) |
ATNFactory.Handle |
ATNFactory.star(GrammarAST starAST,
ATNFactory.Handle blk)
From (A)* build
|---|
v |
o->o-A-o--o (Transition 2 from block end points at alt 1; follow is Transition 1)
| ^
o---------| (optional branch is 2nd alt of optional block containing A+)
Meaning that the last (end) ATNState in A points back to A's
left side ATNState and we add 3 new ATNStates (the
optional branch is built just like an optional subrule).
|
ATNFactory.Handle |
ParserATNFactory.star(GrammarAST starAST,
ATNFactory.Handle elem)
From
(blk)* build ( blk+ )? with *two* decisions, one for
entry and one for choosing alts of blk . |
| Modifier and Type | Method and Description |
|---|---|
ATNFactory.Handle |
ATNFactory.alt(List<ATNFactory.Handle> els) |
ATNFactory.Handle |
ParserATNFactory.alt(List<ATNFactory.Handle> els) |
ATNFactory.Handle |
ATNFactory.block(BlockAST blockAST,
GrammarAST ebnfRoot,
List<ATNFactory.Handle> alternativeGrips)
From A|B|..|Z alternative block build
o->o-A->o->o (last ATNState is blockEndATNState pointed to by all alts)
| ^
o->o-B->o--|
| |
...
|
ATNFactory.Handle |
ParserATNFactory.block(BlockAST blkAST,
GrammarAST ebnfRoot,
List<ATNFactory.Handle> alts)
From
A|B|..|Z alternative block build |
ATNFactory.Handle |
ParserATNFactory.elemList(List<ATNFactory.Handle> els) |
protected ATNFactory.Handle |
ParserATNFactory.makeBlock(BlockStartState start,
BlockAST blkAST,
List<ATNFactory.Handle> alts) |
| Modifier and Type | Field and Description |
|---|---|
ATNFactory.Handle |
ATNBuilder.element_return.p |
ATNFactory.Handle |
ATNBuilder.subrule_return.p |
ATNFactory.Handle |
ATNBuilder.blockSet_return.p |
ATNFactory.Handle |
ATNBuilder.atom_return.p |
ATNFactory.Handle |
ATNBuilder.terminal_return.p |
| Modifier and Type | Method and Description |
|---|---|
ATNFactory.Handle |
ATNBuilder.alternative() |
ATNFactory.Handle |
ATNBuilder.astOperand() |
ATNFactory.Handle |
ATNBuilder.block(GrammarAST ebnfRoot) |
ATNFactory.Handle |
ATNBuilder.labeledElement() |
ATNFactory.Handle |
ATNBuilder.lexerCommand() |
ATNFactory.Handle |
ATNBuilder.lexerCommands() |
ATNFactory.Handle |
ATNBuilder.range() |
ATNFactory.Handle |
ATNBuilder.ruleBlock(GrammarAST ebnfRoot) |
ATNFactory.Handle |
ATNBuilder.ruleref() |
Copyright © 1992–2021 ANTLR. All rights reserved.


This document is an annotated (by the last author) version of the original paper of the same title. It describes a set of coding standards and recommendations which are local standards for officially-supported Unix programs. The scope is coding style, not functional organization.
This document is a result of a committee formed at Indian Hill to establish a common set of coding standards and recommendations for the Indian Hill community. The scope of this work is the coding style, not the functional organization of programs. The standards in this document are not specific to ESS programming only (footnote 1). We have tried to combine previous work [1,6] on C style into a uniform set of standards that should be appropriate for any project using C (footnote 2).
A file consists of various sections that should be separated by several blank lines. Although there is no maximum length requirement for source files, files with more than about 1500 lines are cumbersome to deal with. The editor may not have enough temp space to edit the file, compilations will go slower, etc. Since most of us use 300 baud terminals, entire rows of asterisks, for example, should be discouraged (footnote 3). Also lines longer than 80 columns are not handled well by all terminals and should be avoided if possible (footnote 4).
The suggested order of sections for a file is as follows:
Unix requires certain suffix conventions for names of files to be processed by the cc command [5] (footnote 8). The following suffixes are required:
In addition the following conventions are universally followed:
Header files are files that are included in other files prior to compilation by the C preprocessor. Some are defined at the system level like stdio.h which must be included by any program using the standard I/O library. Header files are also used to contain data declarations and defines that are needed by more than one program (footnote 11). Header files should be functionally organized, i.e., declarations for separate subsystems should be in separate header files. Also, if a set of declarations is likely to change when code is ported from one machine to another, those declarations should be in a separate header file.
Header files should not be nested. Some objects like typedefs and initialized data definitions cannot be seen twice by the compiler in one compilation. On non-Unix systems this is also true of uninitialized declarations without the extern keyword (footnote 12). This can happen if include files are nested and will cause the compilation to fail.
External declarations should begin in column 1. Each declaration should be on a separate line. A comment describing the role of the object being declared should be included, with the exception that a list of defined constants do not need comments if the constant names are sufficient documentation. The comments should be tabbed so that they line up underneath each other (footnote 13). Use the tab character (CTRL I if your terminal doesn't have a separate key) rather than blanks. For structure and union template declarations, each element should be alone on a line with a comment describing it. The opening brace ( { ) should be on the same line as the structure tag, and the closing brace should be alone on a line in column 1, i.e.
struct boat { int wllength; /* water line length in feet */ int type; /* see below */ long sarea; /* sail area in square feet */ }; /* * defines for boat.type (footnote 14) */ #define KETCH 1 #define YAWL 2 #define SLOOP 3 #define SQRIG 4 #define MOTOR 5If an external variable is initialized the equal sign should not be omitted (footnote 15).
int x = 1; char *msg = "message"; struct boat winner = { 40, /* water line length */ YAWL, 600l /* sail area */ };(footnote 16)
Comments that describe data structures, algorithms, etc., should be in block comment form with the opening /* in column one, a * in column 2 before each line of comment text (footnote 17), and the closing */ in columns 2-3.
/* * Here is a block comment. * The comment text should be tabbed over (footnote 18) * and the opening /* and closing star-slash * should be alone on a line. */
Note that grep ^.\* will catch all block comments in the file. In some cases, block comments inside a function are appropriate, and they should be tabbed over to the same tab setting as the code that they describe. Short comments may appear on a single line indented over to the tab setting of the code that follows.
if (argc > 1) { /* Get input file from command line. */ if (freopen(argv[1], "r", stdin) == NULL) error("can't open %s\n", argv[1]); }
Very short comments may appear on the same line as the code they describe, but should be tabbed over far enough to separate them from the statements. If more than one short comment appears in a block of code they should all be tabbed to the same tab setting.
if (a == 2) return(TRUE); /* special case */ else return(isprime(a)); /* works only for odd a */
Each function should be preceded by a block comment prologue that gives the name and a short description of what the function does (footnote 19). If the function returns a value, the type of the value returned should be alone on a line in column 1 (do not default to int). If the function does not return a value then it should not be given a return type. If the value returned requires a long explanation, it should be given in the prologue; otherwise it can be on the same line as the return type, tabbed over. The function name and formal parameters should be alone on a line beginning in column 1. Each parameter should be declared (do not default to int), with a comment on a single line. The opening brace of the function body should also be alone on a line beginning in column 1. The function name, argument declaration list, and opening brace should be separated by a blank line (footnote 20). All local declarations and code within the function body should be tabbed over at least one tab.
If the function uses any external variables, these should have their own declarations in the function body using the extern keyword. If the external variable is an array the array bounds must be repeated in the extern declaration. There should also be extern declarations for all functions called by a given function. This is particularly beneficial to someone picking up code written by another. If a function returns a value of type other than int, it is required by the compiler that such functions be declared before they are used. Having the extern delcaration in the calling function's declarations section avoids all such problems (footnote 21).
In general each variable declaration should be on a separate line with a comment describing the role played by the variable in the function. If the variable is external or a parameter of type pointer which is changed by the function, that should be noted in the comment. All such comments for parameters and local variables should be tabbed so that they line up underneath each other. The declarations should be separated from the function's statements by a blank line.
A local variable should not be redeclared in nested blocks (footnote 22). Even though this is valid C, the potential confusion is enough that lint will complain about it when given the -h option.
/* * skyblue() * * Determine if the sky is blue. */ int /* TRUE or FALSE */ skyblue() { extern int hour; if (hour < MORNING || hour > EVENING) return(FALSE); /* black */ else return(TRUE); /* blue */ }
/* * tail(nodep) * * Find the last element in the linked list * pointed to by nodep and return a pointer to it. */ NODE * /* pointer to tail of list */ tail(nodep) NODE *nodep; /* pointer to head of list */ { register NODE *np; /* current pointer advances to NULL */ register NODE *lp; /* last pointer follows np */ np = lp = nodep; while ((np = np->next) != NULL) lp = np; return(lp); }
Compound statements are statements that contain lists of statements enclosed in braces. The enclosed list should be tabbed over one more than the tab position of the compound statement itself. The opening left brace should be at the end of the line beginning the compound statement and the closing right brace should be alone on a line, tabbed under the beginning of the compound statement. Note that the left brace beginning a function body is the only occurrence of a left brace which is alone on a line.
if (expr) { statement; statement; } if (expr) { statement; statement; } else { statement; statement; }Note that the right brace before the else and the right brace before the while of a do-while statement (below) are the only places where a right braces appears that is not alone on a line.
for (i = 0; i < MAX; i++) { statement; statement; } while (expr) { statement; statement; } do { statement; statement; } while (expr); switch (expr) { case ABC: case DEF: statement; break; case XYZ: statement; break; default: statement; break (footnote 23); }Note that when multiple case labels are used, they are placed on separate lines. The fall through feature of the C switch statement should rarely if ever be used when code is executed before falling through to the next one. If this is done it must be commented for future maintenance.
if (strcmp(reply, "yes") == EQUAL) { statements for yes ... } else if (strcmp(reply, "no") == EQUAL) { statements for no ... } else if (strcmp(reply, "maybe") == EQUAL) { statements for maybe ... } else { statements for none of the above ... }The last example is a generalized switch statement and the tabbing reflects the switch between exactly one of several alternatives rather than a nesting of statements.
The old versions of equal-ops =+, =-, =*, etc. should not be used. The preferred use is +=, -=, *=, etc. All binary operators except . and -> should be separated from their operands by blanks (footnote 24). In addition, keywords that are followed by expressions in parentheses should be separated from the left parenthesis by a blank (footnote 25). Blanks should also appear after commas in argument lists to help separate the arguments visually. On the other hand, macros with arguments and function calls should not have a blank between the name and the left parenthesis. In particular, the C preprocessor requires the left parenthesis to be immediately after the macro name or else the argument list will not be recognized. Unary operators should not be separated from their single operand. Since C has some unexpected precedence rules, all expressions involving mixed operators should be fully parenthesized.
Examples
a += c + d; a = (a + b) / (c * d); strp->field = str.fl - ((x & MASK) >> DISP); while (*d++ = *s++) ; /* EMPTY BODY */
Individual projects will no doubt have their own naming conventions. There are some general rules however.
Numerical constants should not be coded directly (footnote 30). The define feature of the C preprocessor should be used to assign a meaningful name. This will also make it easier to administer large programs since the constant value can be changed uniformly by changing only the define. The enumeration data type is the preferred way to handle situations where a variable takes on only a discrete set of values, since additional type checking is available through lint.
There are some cases where the constants 0 and 1 may appear as themselves instead of as defines. For example if a for loop indexes through an array, then
for (i = 0; i < ARYBOUND; i++)is reasonable while the code
fptr = fopen(filename, "r"); if (fptr == 0) error("can't open %s\n", filename);is not. In the last example the defined constant NULL is available as part of the standard I/O library's header file stdio.h and must be used in place of the 0.
The advantages of portable code are well known. This section gives some guidelines for writing portable code, where the definition of portable is taken to mean that a source file contains portable code if it can be compiled and executed on different machines with the only source change being the inclusion of possibly different header files. The header files will contain defines and typedefs that may vary from machine to machine. Reference [1] contains useful information on both style and portability. Many of the recommendations in this document originated in [1]. The following is a list of pitfalls to be avoided and recommendations to be considered when designing portable code:
type pdp11 3B IBM ________________________ char 8 8 8 short 16 16 16 int 16 32 32 long 32 32 32In general if the word size is important, short or long should be used to get 16 or 32 bit items on any of the above machines (footnote 33). If a simple loop counter is being used where either 16 or 32 bits will do, then use int, since it will get the most efficient (natural) unit for the current machine (footnote 34).
x &= 0177770will clear only the three rightmost bits of an int on a PDP11. On a 3B it will also clear the entire upper halfword. Use
x &= ~07instead which works properly on all machines (footnote 35).
if (f() != FAIL)is better than
if (f())even though FAIL may have the value 0 which is considered to mean false by C (footnote 39). This will help you out later when somebody decides that a failure return should be -1 instead of 0 (footnote 40).
Lint is a C program checker [2] that examines C source files to detect and report type incompatibilities, inconsistencies between function definitions and calls, potential program bugs, etc. It is expected that projects will require programs to use lint as part of the official acceptance procedure (footnote 46). In addition, work is going on in department 5521 to modify lint so that it will check for adherence to the standards in this document.
It is still too early to say exactly which of the standards given here will be checked by lint. In some cases such as whether a comment is misleading or incorrect there is little hope of mechanical checking. In other cases such as checking that the opening brace of a function body is alone on a line in column 1, the test has already been added (footnote 47). Future bulletins will be used to announce new additions to lint as they occur.
It should be noted that the best way to use lint is not as a barrier that must be overcome before official acceptance of a program, but rather as a tool to use whenever major changes or additions to the code have been made. Lint can find obscure bugs and insure portability before problems occur.
This section contains some miscellaneous do's and don'ts.
while ((c = getchar()) != EOF) { process the character }Using embedded assignment statements to improve run-time performance is also possible. However, one should consider the tradeoff between increased speed and decreased maintainability that results when embedded assignments are used in artificial places. For example, the code:
a = b + c; d = a + r;should not be replaced by
d = (a = b + c) + r;even though the latter may save one cycle. Note that in the long run the time difference between the two will decrease as the optimizer gains maturity, while the difference in ease of maintenance will increase as the human memory of what's going on in the latter piece of code begins to fade (footnote 49).
(x >= 0) ? x : -xNested ? : operators can be confusing and should be avoided if possible. There are some macros like getchar where they can be useful. The comma operator can also be useful in for statements to provide multiple initializations or incrementations.
for (...) for (...) { ... if (disaster) goto error; } ... error: clean up the messWhen a goto is necessary the accompanying label should be alone on a line and tabbed one tab position to the left of the associated code that follows.
Individual projects may wish to establish additional standards beyond those given here. The following issues are some of those that should be adddressed by each project program administration group.
A set of standards has been presented for C programming style. One of the most important points is the proper use of white space and comments so that the structure of the program is evident from the layout of the code. Another good idea to keep in mind when writing code is that it is likely that you or someone else will be asked to modify it or make it run on a different machine sometime in the future.
As with any standard, it must be followed if it is to be useful. The Indian Hill version of lint will enforce those standards that are amenable to automatic checking. If you have trouble following any of these standards don't just ignore them. Programmers at Indian Hill should bring their problems to the Software Development System Group (Lee Kirchhoff, contact) in department 5522. Programmers outside Indian Hill should contact the Processor Application Group (Layne Cannon, contact) in department 5512 (footnote 53).
#define STREQ(a, b) (strcmp((a), (b)) == 0)
/* * The C Style Summary Sheet Block comment, * by Henry Spencer, U of T Zoology describes file. */ #include; Headers; don't nest. typedef int SEQNO; /* ... */ Global definitions. #define STREQ(a, b) (strcmp((a), (b)) == 0) static char *foo = NULL; /* ... */ Global declarations. struct bar { Static whenever poss. SEQNO alpha; /* ... */ # define NOSEQNO 0 int beta; /* ... */ Don't assume 16 bits. }; /* * Many unnecessary braces, to show where. Functions. */ static int /* what is returned */ Don't default int. bletch(a) int a; /* ... */ Don't default int. { int bar; /* ... */ extern int errno; /* ..., changed here */ extern char *index(); if (foobar() != FAIL) { if (!isvalid()) { return(5); errno = ERANGE; } } else { x = &y + z->field; while (x == (y & MASK)) { } f += (x >= 0) ? x : -x; } for (i = 0; i < BOUND; i++) { /* Use lint -hpcax. */ do { } /* Avoid nesting ?: */ } while (index(a, b) != NULL); if (STREQ(x, "foo")) { x |= 07; switch (...) { } else if (STREQ(x, "bar")) { case ABC: x &= ~07; case DEF: } else if (STREQ(x, "ugh")) { printf("...", a, b); /* Avoid gotos */ break; } else { case XYZ: /* and continues. */ x = y; } /* FALLTHROUGH */ default: while ((c = getc()) != EOF) /* Limit imbedded =s. */ ; /* NULLBODY */ break; } }


E-mail Registration
Name:
Permanent Address:
Mailing Address:
Phone Number:
Date of Birth:
E-mail:
Username:
Password
Register


Computers were made in the early 1970's the first one taking up 1800 sqfeet and wighing 27 tons. As of right know your phone weights a bought 2 grams thats crazy, in only 50 years we made something that weighs 27 tons weigh about 2 grams
if thats not crazy then i dont know what is, but of course your here to learn about old computers so let me tell you a little something about old computers they ran off of the old and still used x86 bridge witch is still one of the most stable platforms,
and isnt it crazy how back in the day if you awnsered your home phone your internet would cut out? thats crazy! who thought that would be a good idea they must have been crazy. also the very first consumer pc in 1972 cost around $5800 american
and to think you can go buy a latop for only 200 bucks nowadays is totally crazy also the fist "laptops" werent a thing till the 1976s and the first real laptop did not come out until the 1980s and yet they still cost $2000 american. heres a little video and photo of old Laptops.
so they were clearly pretty beefy compared to what we have today its truly crazy how much they'ved changed its insane.


We have selected the following sites that have the best content on Javascript tutorials and any information on Javascript.
W3 Schools offers the best content and information on Javascript.
It also has a wide range of examples and well illustrated tutorials.
~Besides providing content, the website also offers test exercises after each topic,
thereby making your learning effective.
JavaScript is the most widely used scripting language on the web.
~Quackit tutorials will teach you JavaScript from the ground up — starting with the basics.
You will learn introductory level object oriented programming using ES6 JavaScript.
Learn how to navigate yourself around Javascript and understand the basics.
~Write JavaScript with best practices without getting confused by millions of opinions on the Internet.
Free Code Camp has over 8000 articles, videos and tutorials to choose from.
This site will make your learning so much easier.
We have also provided video links for your javascript learning!
This makes it easier for you to understand javascript better; both visually and in practicality.
It also helps in direct application, incase one finds it difficult to understand the content .


Lorem ipsum dolor sit amet, consectetur it. Lorem ipsum dolor sit amet, consectetur it. Lorem ipsum dolor sit amet, consectetur it. Lorem ipsum dolor sit amet, consectetur it. Lorem ipsum dolor sit amet, consectetur it. Lorem ipsum dolor sit amet, consectetur it.


| DOSE: |
3 hits |
smoked |
Cannabis |
(plant material) |
I would just like to start of that this was my third time smoking marijuana. The previous two where awful experiences. The first time I felt nothing. The second time I just freaked out, mainly because I was surrounded by people who I did not know as well as being in the heart of the ghetto with my sister.
Well this time was very different. The pure form of euphoria, un-adulerated and clean. My mind-set was very neutral. I was at my house alone since my parents and siblings vacationed to Mexico for 2 weeks, leaving me paranoia free. The setting was very calm, no body home, no nosy neighbors-nothing to get me paranoid. I decided to pick a very calming and soothing tune, 'The Flower Duet by Lakme'. Now don't get me wrong, I'm a hip-hop guy, this is the only opera song I will listen to. Now for the experience.
T+ 0.0 Hours
I finished rolling the joint and waited for it to dry, I chose a joint because its very classic and original, no non-sense. I took a big toke and exhaled.
T+ 0.125 Hours
It's been five minutes so I took two more big tokes and extinguished the joint and saved it for my friend. I wanted to be mellowed out.
T+ 0.25 Hours
Ten minutes from the first hit and I'm feeling 'it'. I walked to my computer to listen to the opera tune. I thought to myself 'I'm high' and the biggest grin came to my face. Coming up was excellent, didn't just feel high, I felt that I was becoming high. A smooth, rich transition from normal to intoxication. As a matter of fact, intoxication is probably a bad word to describe this high. I'm going to call it ineuphorication from now on.
T+ 0.5 hours
Thirty minutes, feeling good, thinking good, seeing good, hearing good, smelling good, tasting good. Being good.
T+ 1.0 hours
I can think about anything and everything easily, my thoughts are melted together rather than choppy. I can connect thoughts easily, I can see my thoughts.
T + 1.125 hours
Still listening to The Flower Duet, it's melody and rhythm just makes me feel heaven. Just loving everything, anger, fury, hatred-they don't exist. Couldn't describe the feeling of pain. I literally tried to explain it to myself, all I could think of it being an untangible object with no meaning. Love and pleasure meant everything good, pure, and excellent.
T + 2.0 Hours
Still feeling quite high, cotton mouth and eyes did not interfere I just ate a quick snack. The munchies I received was not a craving, more like my stomach was a bottomless pit where I could not satisfy my hunger. I did not seek food I just never felt full.
T + 3.0 hours
Went to sleep feeling good in every nanometer of my body, giggling on my way to bed. Seeing things in new percepective, finding meaning to the meaningless.
T + 7.0 hours
Feeling very refreshed. I feel reborn, I know found more meaning to things that I always overlooked. My religous beliefs strengthened. If there is no god, why are we here? Science explains the how but not the why. Theories and hypothesis, knowledge and fact, fantasy and euphoria. Me and Mary Jane.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


?6
7
8
9
10
T
XT
v
The
New
York
copyright
reserved
botanical
Garden
<8>
IMAGED
THE
NEW
YORK
BOTANICAL
GARDEN
Plants
of
Puerto
Rico
NEW
YORK
BOTANICAL
GARDEN
00843133
D-L
ipholis
cubensis
(Griseb.)
Pierre
The
New
York
Botanical
Garden
£
I
À.Çw'oÕk^Vovx.
Ç-o\oÇ.v\s{s
A.w.V\0"t*
&<
Ji
WAP§.
Ôi”-j'ulvj
20ï1-/
Small
tree,
ItÑ5
m.
high*
On
serpentine
soil.
Altitude
300
m.
las
Ilesas,
Mayaguez.
Puerto
Rico.
Brother
Alain
Liogier
June
25,
1963
Legend -
Level of confidence that token is an accurately-transcribed word
extremely low
very low
low
undetermined
medium
high
very high


VIRT-WHAT
Section: Virtualization Support (1)Updated: 2011-05-26
Index Return to Main Contents
NAME
virt-what - detect if we are running in a virtual machineSUMMARY
virt-what [options]DESCRIPTION
"virt-what" is a shell script which can be used to detect if the program is running in a virtual machine.The program prints out a list of ``facts'' about the virtual machine, derived from heuristics. One fact is printed per line.
If nothing is printed and the script exits with code 0 (no error), then it can mean either that the program is running on bare-metal or the program is running inside a type of virtual machine which we don't know about or cannot detect.
FACTS
- hyperv
-
This is Microsoft Hyper-V hypervisor.
Status: confirmed by RWMJ
- ibm_systemz
- This is an IBM SystemZ (or other S/390) hardware partitioning system. Additional facts listed below may also be printed.
- ibm_systemz-direct
-
This is Linux running directly on a IBM SystemZ hardware partitioning
system.
This is expected to be a highly unusual configuration - if you see this result you should treat it with suspicion.
Status: not confirmed
- ibm_systemz-lpar
-
This is Linux running directly on an LPAR on an IBM SystemZ
hardware partitioning system.
Status: not confirmed
- ibm_systemz-zvm
-
This is a z/VM guest running in an LPAR on an IBM SystemZ
hardware partitioning system.
Status: confirmed by RWMJ using a Fedora guest running in z/VM
- linux_vserver
-
This process is running in a Linux VServer container.
Status: contributed by BarXX Metin
- kvm
-
This guest is running on the KVM hypervisor using hardware
acceleration.
Note that if the hypervisor is using software acceleration you should not see this, but should see the "qemu" fact instead.
Status: confirmed by RWMJ.
- openvz
-
The guest appears to be running inside an OpenVZ or Virtuozzo
container.
Status: contributed by Evgeniy Sokolov
- parallels
-
The guest is running inside Parallels Virtual Platform
(Parallels Desktop, Parallels Server).
Status: contributed by Justin Clift
- powervm_lx86
-
The guest is running inside IBM PowerVM Lx86 Linux/x86 emulator.
Status: data originally supplied by Jeffrey Scheel, confimed by Yufang Zhang and RWMJ
- qemu
-
This is QEMU hypervisor using software emulation.
Note that for KVM (hardware accelerated) guests you should not see this.
Status: confirmed by RWMJ.
- uml
-
This is a User-Mode Linux (UML) guest.
Status: contributed by Laurent Leonard
- virt
- Some sort of virtualization appears to be present, but we are not sure what it is. In some very rare corner cases where we know that virtualization is hard to detect, we will try a timing attack to see if certain machine instructions are running much more slowly than they should be, which would indicate virtualization. In this case, the generic fact "virt" is printed.
- virtage
-
This is Hitachi Virtualization Manager (HVM) Virtage
hardware partitioning system.
Status: data supplied by Bhavna Sarathy, not confirmed
- virtualbox
-
This is a VirtualBox guest.
Status: contributed by Laurent Leonard
- virtualpc
-
The guest appears to be running on Microsoft VirtualPC.
Status: not confirmed
- vmware
-
The guest appears to be running on VMware hypervisor.
Status: confirmed by RWMJ
- xen
-
The guest appears to be running on Xen hypervisor.
Status: confirmed by RWMJ
- xen-dom0
-
This is the Xen dom0 (privileged domain).
Status: confirmed by RWMJ
- xen-domU
-
This is a Xen domU (paravirtualized guest domain).
Status: confirmed by RWMJ
- xen-hvm
-
This is a Xen guest fully virtualized (HVM).
Status: confirmed by RWMJ
EXIT STATUS
Programs that use or wrap "virt-what" should check that the exit status is 0 before they attempt to parse the output of the command.A non-zero exit status indicates some error, for example, an unrecognized command line argument. If the exit status is non-zero then the output ``facts'' (if any were printed) cannot be guaranteed and should be ignored.
The exit status does not have anything to do with whether the program is running on baremetal or under virtualization, nor with whether "virt-what" managed detection ``correctly'' (which is basically unknowable given the large variety of virtualization systems out there and that some systems deliberately emulate others).
RUNNING VIRT-WHAT FROM OTHER PROGRAMS
"virt-what" is designed so that you can easily run it from other programs or wrap it up in a library.Your program should check the exit status (see the section above).
Some programming languages (notably Python: issue 1652) erroneously mask the "SIGPIPE" signal and do not restore it when executing subprocesses. "virt-what" is a shell script and some shell commands do not work correctly when you do this. You may see warnings from "virt-what" similar to this:
echo: write error: Broken pipe
The solution is to set the "SIGPIPE" signal handler back to "SIG_DFL" before running "virt-what".
IMPORTANT NOTE
Most of the time, using this program is the wrong thing to do. Instead you should detect the specific features you actually want to use. (As an example, if you wanted to issue Xen hypervisor commands you would look for the "/proc/xen/privcmd" file).However people keep asking for this, so we provide it. There are a few legitimate uses:
- Bug reporting tool
- If you think that virtualization could affect how your program runs, then you might use "virt-what" to report this in a bug reporting tool.
- Status display and monitoring tools
- You might include this information in status and monitoring programs.
SEE ALSO
<http://people.redhat.com/~rjones/virt-what/>, <http://www.vmware.com/>, <http://www.microsoft.com/windows/products/winfamily/virtualpc>, <http://xensource.com/>, <http://bellard.org/qemu/>, <http://kvm.qumranet.com/>, <http://openvz.org/>AUTHORS
Richard W.M. Jones <rjones @ redhat . com>COPYRIGHT
(C) Copyright 2008-2011 Red Hat Inc., <http://people.redhat.com/~rjones/virt-what/>This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
REPORTING BUGS
Bugs can be viewed on the Red Hat Bugzilla page: <https://bugzilla.redhat.com/>.If you find a bug in virt-what, please follow these steps to report it:
- 1. Check for existing bug reports
- Go to <https://bugzilla.redhat.com/> and search for similar bugs. Someone may already have reported the same bug, and they may even have fixed it.
- 2. Capture debug and error messages
-
Run
virt-what > virt-what.log 2>&1
and keep virt-what.log. It may contain error messages which you should submit with your bug report.
- 3. Get version of virt-what.
-
Run
virt-what --version
- 4. Submit a bug report.
-
Go to <https://bugzilla.redhat.com/> and enter a new bug.
Please describe the problem in as much detail as possible.
Remember to include the version numbers (step 3) and the debug messages file (step 2) and as much other detail as possible.
- 5. Assign the bug to rjones @ redhat.com
-
Assign or reassign the bug to rjones @ redhat.com (without the
spaces). You can also send me an email with the bug number if you
want a faster response.
Index
- NAME
- SUMMARY
- DESCRIPTION
- FACTS
- EXIT STATUS
- RUNNING VIRT-WHAT FROM OTHER PROGRAMS
- IMPORTANT NOTE
- SEE ALSO
- AUTHORS
- COPYRIGHT
- REPORTING BUGS
This document was created by man2html, using the manual pages.
Time: 05:29:12 GMT, December 24, 2015


Here's a list October inflation rates for Canadian provinces, territories
OTTAWA — Canada's national annual inflation rate was 1.9 per cent in October, Statistics Canada says. Here's what happened in the provinces (previous month in brackets): — Newfoundland and Labrador: 0.5 per cent (0.5) — Prince Edward Island: 1.1 (1.
by Canadian PressOTTAWA — Canada's national annual inflation rate was 1.9 per cent in October, Statistics Canada says. Here's what happened in the provinces (previous month in brackets):
— Newfoundland and Labrador: 0.5 per cent (0.5)
— Prince Edward Island: 1.1 (1.6)
— Nova Scotia: 1.0 (2.1)
— New Brunswick: 1.3 (1.8)
— Quebec: 2.3 (2.2)
— Ontario: 1.7 (1.7)
— Manitoba: 2.2 (2.2)
— Saskatchewan: 1.6 (1.7)
— Alberta: 1.6 (1.3)
— British Columbia: 2.2 (2.4)
The Canadian Press


| Severity | Error Description | Line |
| warning | File contains tab characters (this is the first instance). | 6 |
| warning | Class 'BackstageItem' looks like designed for extension (can be subclassed), but the method 'updateQuality' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'BackstageItem' final or making the method 'updateQuality' static/final/abstract/empty, or adding allowed annotation for the method. | 9 |
| warning | 'if' has incorrect indentation level 4, expected level should be 8. | 12 |
| warning | '{' at column 3 should be on the previous line. | 13 |
| warning | 'if' child has incorrect indentation level 6, expected level should be 12. | 14 |
| warning | 'if rcurly' has incorrect indentation level 6, expected level should be 8. | 15 |
| warning | 'if' has incorrect indentation level 6, expected level should be 8. | 17 |
| warning | '{' at column 3 should be on the previous line. | 18 |
| warning | 'if' has incorrect indentation level 10, expected level should be 12. | 19 |
| warning | 'if lcurly' has incorrect indentation level 8, expected level should be 12. | 20 |
| warning | '{' at column 5 should be on the previous line. | 20 |
| warning | 'if' child has incorrect indentation level 12, expected level should be 16. | 21 |
| warning | 'if rcurly' has incorrect indentation level 8, expected level should be 12. | 22 |
| warning | 'if rcurly' has incorrect indentation level 4, expected level should be 8. | 23 |
| warning | 'if' has incorrect indentation level 6, expected level should be 8. | 26 |
| warning | '{' at column 3 should be on the previous line. | 27 |
| warning | 'if' has incorrect indentation level 8, expected level should be 12. | 28 |
| warning | 'if lcurly' has incorrect indentation level 8, expected level should be 12. | 29 |
| warning | '{' at column 9 should be on the previous line. | 29 |
| warning | 'if rcurly' has incorrect indentation level 10, expected level should be 12. | 31 |
| warning | 'if rcurly' has incorrect indentation level 6, expected level should be 8. | 32 |
| warning | 'if' has incorrect indentation level 12, expected level should be 8. | 38 |
| warning | 'if lcurly' has incorrect indentation level 12, expected level should be 8. | 39 |
| warning | '{' at column 4 should be on the previous line. | 39 |
| warning | 'if' child has incorrect indentation level 16, expected level should be 12. | 40 |
| warning | 'if rcurly' has incorrect indentation level 12, expected level should be 8. | 41 |
| Severity | Error Description | Line |
| warning | File does not end with a newline. | 1 |
| warning | 'method def modifier' has incorrect indentation level 0, expected level should be 4. | 10 |
| warning | Class 'ConjuredItem' looks like designed for extension (can be subclassed), but the method 'updateQuality' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'ConjuredItem' final or making the method 'updateQuality' static/final/abstract/empty, or adding allowed annotation for the method. | 10 |
| warning | 'if' has incorrect indentation level 4, expected level should be 8. | 12 |
| warning | '{' at column 9 should be on the previous line. | 13 |
| warning | 'method def' child has incorrect indentation level 4, expected level should be 8. | 18 |
| warning | 'if' has incorrect indentation level 6, expected level should be 8. | 20 |
| warning | 'if lcurly' has incorrect indentation level 10, expected level should be 8. | 21 |
| warning | '{' at column 11 should be on the previous line. | 21 |
| warning | '{' at column 13 should be on the previous line. | 23 |
| warning | 'if rcurly' has incorrect indentation level 14, expected level should be 12. | 26 |
| warning | 'method def rcurly' has incorrect indentation level 0, expected level should be 4. | 28 |
| Severity | Error Description | Line |
| warning | File does not end with a newline. | 1 |
| warning | File contains tab characters (this is the first instance). | 6 |
| warning | Name 'maxQuality' must match pattern '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'. | 7 |
| warning | 'method def modifier' has incorrect indentation level 2, expected level should be 4. | 11 |
| warning | Class 'GeneralItem' looks like designed for extension (can be subclassed), but the method 'isUnderMaxQuality' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'GeneralItem' final or making the method 'isUnderMaxQuality' static/final/abstract/empty, or adding allowed annotation for the method. | 11 |
| warning | Class 'GeneralItem' looks like designed for extension (can be subclassed), but the method 'isSellInNegative' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'GeneralItem' final or making the method 'isSellInNegative' static/final/abstract/empty, or adding allowed annotation for the method. | 15 |
| warning | Class 'GeneralItem' looks like designed for extension (can be subclassed), but the method 'isQualityPositive' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'GeneralItem' final or making the method 'isQualityPositive' static/final/abstract/empty, or adding allowed annotation for the method. | 19 |
| warning | Line is longer than 150 characters (found 153). | 23 |
| warning | Class 'GeneralItem' looks like designed for extension (can be subclassed), but the method 'decrementSellIn' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'GeneralItem' final or making the method 'decrementSellIn' static/final/abstract/empty, or adding allowed annotation for the method. | 25 |
| warning | Class 'GeneralItem' looks like designed for extension (can be subclassed), but the method 'incrementQuality' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'GeneralItem' final or making the method 'incrementQuality' static/final/abstract/empty, or adding allowed annotation for the method. | 29 |
| warning | Class 'GeneralItem' looks like designed for extension (can be subclassed), but the method 'decrementQuality' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'GeneralItem' final or making the method 'decrementQuality' static/final/abstract/empty, or adding allowed annotation for the method. | 33 |
| warning | 'method def modifier' has incorrect indentation level 2, expected level should be 4. | 39 |
| warning | Class 'GeneralItem' looks like designed for extension (can be subclassed), but the method 'updateQuality' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'GeneralItem' final or making the method 'updateQuality' static/final/abstract/empty, or adding allowed annotation for the method. | 39 |
| warning | 'if lcurly' has incorrect indentation level 12, expected level should be 8. | 41 |
| warning | '{' at column 4 should be on the previous line. | 41 |
| warning | 'if' child has incorrect indentation level 16, expected level should be 12. | 42 |
| warning | 'if rcurly' has incorrect indentation level 12, expected level should be 8. | 43 |
| warning | 'if lcurly' has incorrect indentation level 12, expected level should be 8. | 48 |
| warning | '{' at column 6 should be on the previous line. | 48 |
| warning | 'if' has incorrect indentation level 16, expected level should be 12. | 49 |
| warning | 'if lcurly' has incorrect indentation level 16, expected level should be 12. | 50 |
| warning | '{' at column 5 should be on the previous line. | 50 |
| warning | 'if' child has incorrect indentation level 20, expected level should be 16. | 51 |
| warning | 'if rcurly' has incorrect indentation level 16, expected level should be 12. | 52 |
| warning | 'if rcurly' has incorrect indentation level 12, expected level should be 8. | 53 |
| warning | 'method def rcurly' has incorrect indentation level 2, expected level should be 4. | 54 |
| Severity | Error Description | Line |
| warning | File contains tab characters (this is the first instance). | 5 |
| warning | 'ctor def modifier' has incorrect indentation level 1, expected level should be 4. | 7 |
| warning | Redundant 'public' modifier. | 7 |
| warning | 'items' hides a field. | 7 |
| warning | Return count is 5 (max allowed for non-void methods/lambdas is 3). | 14 |
| warning | 'switch lcurly' has incorrect indentation level 12, expected level should be 8. | 16 |
| warning | '{' at column 5 should be on the previous line. | 16 |
| warning | 'case' child has incorrect indentation level 16, expected level should be 12. | 17 |
| warning | 'block' child has incorrect indentation level 20, expected level should be 16. | 18 |
| warning | 'case' child has incorrect indentation level 16, expected level should be 12. | 20 |
| warning | 'block' child has incorrect indentation level 20, expected level should be 16. | 21 |
| warning | 'case' child has incorrect indentation level 16, expected level should be 12. | 23 |
| warning | 'block' child has incorrect indentation level 20, expected level should be 16. | 24 |
| warning | 'if' construct must use '{}'s. | 27 |
| warning | 'if' has incorrect indentation level 15, expected level should be 16. | 27 |
| warning | 'switch rcurly' has incorrect indentation level 12, expected level should be 8. | 30 |
| warning | '{' at column 2 should be on the previous line. | 35 |
| warning | '{' at column 3 should be on the previous line. | 37 |
| warning | Variable 'generalItem' should be declared final. | 38 |
| Severity | Error Description | Line |
| warning | Missing a Javadoc comment. | 5 |
| warning | Variable 'name' must be private and have accessor methods. | 5 |
| warning | Missing a Javadoc comment. | 7 |
| warning | Variable 'sellIn' must be private and have accessor methods. | 7 |
| warning | Missing a Javadoc comment. | 9 |
| warning | Variable 'quality' must be private and have accessor methods. | 9 |
| warning | 'name' hides a field. | 11 |
| warning | 'sellIn' hides a field. | 11 |
| warning | 'quality' hides a field. | 11 |
| warning | 'method def modifier' has incorrect indentation level 3, expected level should be 4. | 17 |
| warning | Class 'Item' looks like designed for extension (can be subclassed), but the method 'toString' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'Item' final or making the method 'toString' static/final/abstract/empty, or adding allowed annotation for the method. | 17 |
| warning | The String ", " appears 2 times in the file. | 19 |