|
My Project
|
A function prototype. More...
#include <fspec.hh>
Public Member Functions | |
| FuncProto (void) | |
| Constructor. | |
| ~FuncProto (void) | |
| Destructor. | |
| Architecture * | getArch (void) const |
| Get the Architecture owning this. | |
| void | copy (const FuncProto &op2) |
| Copy another function prototype. More... | |
| void | copyFlowEffects (const FuncProto &op2) |
| Copy properties that affect data-flow. | |
| void | getPieces (PrototypePieces &pieces) const |
| Get the raw pieces of the prototype. More... | |
| void | setPieces (const PrototypePieces &pieces) |
| Set this prototype based on raw pieces. More... | |
| void | setScope (Scope *s, const Address &startpoint) |
| Set a backing symbol Scope for this. More... | |
| void | setInternal (ProtoModel *m, Datatype *vt) |
| Set internal backing storage for this. More... | |
| void | setModel (ProtoModel *m) |
| Set the prototype model for this. More... | |
| bool | hasModel (void) const |
| Does this prototype have a model. | |
| bool | hasMatchingModel (const FuncProto *op2) const |
| Does this have a matching model. | |
| bool | hasMatchingModel (const ProtoModel *op2) const |
| Does this use the given model. | |
| const string & | getModelName (void) const |
| Get the prototype model name. | |
| int4 | getModelExtraPop (void) const |
| Get the extrapop of the prototype model. | |
| bool | isInputLocked (void) const |
| Are input data-types locked. | |
| bool | isOutputLocked (void) const |
| Is the output data-type locked. | |
| bool | isModelLocked (void) const |
| Is the prototype model for this locked. | |
| bool | isUnknownModel (void) const |
| Is prototype model officially "unknown". | |
| bool | hasCustomStorage (void) const |
| Is this a "custom" function prototype. | |
| void | setInputLock (bool val) |
| Toggle the data-type lock on input parameters. More... | |
| void | setOutputLock (bool val) |
| Toggle the data-type lock on the return value. More... | |
| void | setModelLock (bool val) |
| Toggle the lock on the prototype model for this. More... | |
| bool | isInline (void) const |
| Does this function get in-lined during decompilation. | |
| void | setInline (bool val) |
| Toggle the in-line setting for functions with this prototype. More... | |
| int4 | getInjectId (void) const |
| Get the injection id associated with this. More... | |
| int4 | getReturnBytesConsumed (void) const |
| Get an estimate of the number of bytes consumed by callers of this prototype. More... | |
| bool | setReturnBytesConsumed (int4 val) |
| Set the number of bytes consumed by callers of this. More... | |
| bool | isNoReturn (void) const |
| Does a function with this prototype never return. | |
| void | setNoReturn (bool val) |
| Toggle the no-return setting for functions with this prototype. More... | |
| bool | hasThisPointer (void) const |
| Is this a prototype for a class method, taking a this pointer. | |
| void | setThisPointer (bool val) |
| Toggle the this-call setting for this prototype. More... | |
| bool | isConstructor (void) const |
| Is this prototype for a class constructor method. | |
| void | setConstructor (bool val) |
| Toggle whether this prototype is a constructor method. More... | |
| bool | isDestructor (void) const |
| Is this prototype for a class destructor method. | |
| void | setDestructor (bool val) |
| Toggle whether this prototype is a destructor method. More... | |
| bool | hasInputErrors (void) const |
| Has this prototype been marked as having an incorrect input parameter descriptions. | |
| bool | hasOutputErrors (void) const |
| Has this prototype been marked as having an incorrect return value description. | |
| void | setInputErrors (bool val) |
| Toggle the input error setting for this prototype. More... | |
| void | setOutputErrors (bool val) |
| Toggle the output error setting for this prototype. More... | |
| int4 | getExtraPop (void) const |
| Get the general extrapop setting for this prototype. | |
| void | setExtraPop (int4 ep) |
| Set the general extrapop for this prototype. | |
| int4 | getInjectUponEntry (void) const |
| Get any upon-entry injection id (or -1) | |
| int4 | getInjectUponReturn (void) const |
| Get any upon-return injection id (or -1) | |
| void | resolveExtraPop (void) |
| Assuming this prototype is locked, calculate the extrapop. More... | |
| void | clearUnlockedInput (void) |
| Clear input parameters that have not been locked. | |
| void | clearUnlockedOutput (void) |
| Clear the return value if it has not been locked. | |
| void | clearInput (void) |
| Clear all input parameters regardless of lock. | |
| void | cancelInjectId (void) |
| Turn-off any in-lining for this function. | |
| void | resolveModel (ParamActive *active) |
| If this has a merged model, pick the most likely model (from the merged set) More... | |
| void | deriveInputMap (ParamActive *active) const |
| Given a list of input trials, derive the most likely inputs for this prototype. More... | |
| void | deriveOutputMap (ParamActive *active) const |
| Given a list of output trials, derive the most likely return value for this prototype. More... | |
| bool | checkInputJoin (const Address &hiaddr, int4 hisz, const Address &loaddr, int4 losz) const |
| Check if the given two input storage locations can represent a single logical parameter. More... | |
| bool | checkInputSplit (const Address &loc, int4 size, int4 splitpoint) const |
| Check if it makes sense to split a single storage location into two input parameters. More... | |
| void | updateInputTypes (const vector< Varnode *> &triallist, ParamActive *activeinput) |
| Update input parameters based on Varnode trials. More... | |
| void | updateInputNoTypes (const vector< Varnode *> &triallist, ParamActive *activeinput, TypeFactory *factory) |
| Update input parameters based on Varnode trials, but do not store the data-type. More... | |
| void | updateOutputTypes (const vector< Varnode *> &triallist) |
| Update the return value based on Varnode trials. More... | |
| void | updateOutputNoTypes (const vector< Varnode *> &triallist, TypeFactory *factory) |
| Update the return value based on Varnode trials, but don't store the data-type. More... | |
| void | updateAllTypes (const vector< string > &namelist, const vector< Datatype *> &typelist, bool dtdtdt) |
| Set this entire function prototype based on a list of names and data-types. More... | |
| ProtoParameter * | getParam (int4 i) const |
| Get the i-th input parameter. | |
| void | removeParam (int4 i) |
| Remove the i-th input parameter. | |
| int4 | numParams (void) const |
| Get the number of input parameters. | |
| ProtoParameter * | getOutput (void) const |
| Get the return value. | |
| Datatype * | getOutputType (void) const |
| Get the return value data-type. | |
| const RangeList & | getLocalRange (void) const |
| Get the range of potential local stack variables. | |
| const RangeList & | getParamRange (void) const |
| Get the range of potential stack parameters. | |
| bool | isStackGrowsNegative (void) const |
| Return true if the stack grows toward smaller addresses. | |
| bool | isDotdotdot (void) const |
| Return true if this takes a variable number of arguments. | |
| void | setDotdotdot (bool val) |
| Toggle whether this takes variable arguments. | |
| bool | isOverride (void) const |
| Return true if this is a call site override. | |
| void | setOverride (bool val) |
| Toggle whether this is a call site override. | |
| uint4 | hasEffect (const Address &addr, int4 size) const |
| Calculate the effect this has an a given storage location.  More... | |
| const VarnodeData & | getLikelyTrash (int4 i) const |
| Get the i-th likely-trash location. More... | |
| int4 | characterizeAsInputParam (const Address &addr, int4 size) const |
| Decide whether a given storage location could be, or could hold, an input parameter. More... | |
| bool | possibleInputParam (const Address &addr, int4 size) const |
| Decide whether a given storage location could be an input parameter. More... | |
| bool | possibleOutputParam (const Address &addr, int4 size) const |
| Decide whether a given storage location could be a return value. More... | |
| int4 | getMaxInputDelay (void) const |
| Return the maximum heritage delay across all possible input parameters. More... | |
| int4 | getMaxOutputDelay (void) const |
| Return the maximum heritage delay across all possible return values. More... | |
| bool | unjustifiedInputParam (const Address &addr, int4 size, VarnodeData &res) const |
| Check if the given storage location looks like an unjustified input parameter. More... | |
| OpCode | assumedInputExtension (const Address &addr, int4 size, VarnodeData &res) const |
| Get the type of extension and containing input parameter for the given storage. More... | |
| OpCode | assumedOutputExtension (const Address &addr, int4 size, VarnodeData &res) const |
| Get the type of extension and containing return value location for the given storage. More... | |
| bool | getBiggestContainedInputParam (const Address &loc, int4 size, VarnodeData &res) const |
| Pass-back the biggest potential input parameter contained within the given range. More... | |
| bool | isCompatible (const FuncProto &op2) const |
| Decide if this can be safely restricted to match another prototype. More... | |
| AddrSpace * | getSpacebase (void) const |
| Get the stack address space. | |
| void | printRaw (const string &funcname, ostream &s) const |
| Print this prototype as a single line of text. More... | |
| uint4 | getComparableFlags (void) const |
| Get the comparable properties of this prototype. More... | |
| void | saveXml (ostream &s) const |
| Save this to an XML stream as a <prototype> tag. More... | |
| void | restoreXml (const Element *el, Architecture *glb) |
| Restore this from an XML stream. More... | |
Protected Member Functions | |
| void | paramShift (int4 paramshift) |
| Add parameters to the front of the input parameter list. More... | |
| bool | isParamshiftApplied (void) const |
| void | setParamshiftApplied (bool val) |
| Toggle whether a parameter shift has been applied. | |
A function prototype.
A description of the parameters and return value for a specific function. Parameter descriptions include both source code features like name and data-type but also give the storage location. Storage follows a specific parameter passing convention (ProtoModel), although individual parameters may be customized. The prototype describes numerous properties related to calling the specific function:
|
inline |
Get the type of extension and containing input parameter for the given storage.
If the given storage is properly contained within a normal parameter and the model typically extends a small value into the full container, pass back the full container and the type of extension.
| addr | is the starting address of the given storage |
| size | is the number of bytes in the given storage |
| res | is the parameter storage to pass back |
|
inline |
Get the type of extension and containing return value location for the given storage.
If the given storage is properly contained within a normal return value location and the model typically extends a small value into the full container, pass back the full container and the type of extension.
| addr | is the starting address of the given storage |
| size | is the number of bytes in the given storage |
| res | is the parameter storage to pass back |
| int4 FuncProto::characterizeAsInputParam | ( | const Address & | addr, |
| int4 | size | ||
| ) | const |
Decide whether a given storage location could be, or could hold, an input parameter.
If the input is locked, check if the location overlaps one of the current parameters. Otherwise, check if the location overlaps an entry in the prototype model. Return:
| addr | is the starting address of the given storage location |
| size | is the number of bytes in the storage |
|
inline |
Check if the given two input storage locations can represent a single logical parameter.
For this prototype, do the two (hi/lo) locations represent consecutive input parameter locations that can be replaced by a single logical parameter.
| hiaddr | is the address of the most significant part of the value |
| hisz | is the size of the most significant part in bytes |
| loaddr | is the address of the least significant part of the value |
| losz | is the size of the least significant part in bytes |
|
inline |
Check if it makes sense to split a single storage location into two input parameters.
A storage location and split point is provided, implying two new storage locations. Does this prototype allow these locations to be considered separate parameters.
| loc | is the starting address of provided storage location |
| size | is the size of the location in bytes |
| splitpoint | is the number of bytes to consider in the first (in address order) piece |
| void FuncProto::copy | ( | const FuncProto & | op2 | ) |
Copy another function prototype.
| op2 | is the other function prototype to copy into this |
|
inline |
Given a list of input trials, derive the most likely inputs for this prototype.
Trials are sorted and marked as used or not.
| active | is the collection of Varnode input trials |
|
inline |
Given a list of output trials, derive the most likely return value for this prototype.
One trial (at most) is marked used and moved to the front of the list
| active | is the collection of output trials |
| bool FuncProto::getBiggestContainedInputParam | ( | const Address & | loc, |
| int4 | size, | ||
| VarnodeData & | res | ||
| ) | const |
Pass-back the biggest potential input parameter contained within the given range.
Pass-back the biggest input parameter contained within the given range.
| loc | is the starting address of the given range |
| size | is the number of bytes in the range |
| res | will hold the parameter storage description being passed back |
|
inline |
Get the comparable properties of this prototype.
Get properties not including locking, error, and inlining flags.
|
inline |
Get the injection id associated with this.
A non-negative id indicates a call-fixup is used to in-line function's with this prototype.
| const VarnodeData & FuncProto::getLikelyTrash | ( | int4 | i | ) | const |
Get the i-th likely-trash location.
| i | is the index of the storage location |
|
inline |
Return the maximum heritage delay across all possible input parameters.
Depending on the address space, data-flow for a parameter may not be available until extra transform passes have completed. This method returns the number of passes that must occur before we can guarantee that all parameters have data-flow info.
|
inline |
Return the maximum heritage delay across all possible return values.
Depending on the address space, data-flow for a parameter may not be available until extra transform passes have completed. This method returns the number of passes that must occur before we can guarantee that any return value has data-flow info.
| void FuncProto::getPieces | ( | PrototypePieces & | pieces | ) | const |
Get the raw pieces of the prototype.
Copy out the raw pieces of this prototype as stand-alone objects, includings model, names, and data-types
| pieces | will hold the raw pieces |
|
inline |
Get an estimate of the number of bytes consumed by callers of this prototype.
A value of 0 means all possible bytes of the storage location are consumed.
| uint4 FuncProto::hasEffect | ( | const Address & | addr, |
| int4 | size | ||
| ) | const |
Calculate the effect this has an a given storage location.
For a storage location that is active before and after a call to a function with this prototype, we determine the type of side-effect the function will have on the storage.
| addr | is the starting address of the storage location |
| size | is the number of bytes in the storage |
| bool FuncProto::isCompatible | ( | const FuncProto & | op2 | ) | const |
Decide if this can be safely restricted to match another prototype.
Do this and another given function prototype share enough of their model, that if we restrict this to the other prototype, we know we won't miss data-flow.
| op2 | is the other restricting prototype |
|
inlineprotected |
Has a parameter shift been applied
| int4 FuncProto::numLikelyTrash | ( | void | ) | const |
Get the number of likely-trash locations.
|
protected |
Add parameters to the front of the input parameter list.
Prepend the indicated number of input parameters to this. The new parameters have a data-type of xunknown4. If they were originally locked, the existing parameters are preserved.
| paramshift | is the number of parameters to add (must be >0) |
| bool FuncProto::possibleInputParam | ( | const Address & | addr, |
| int4 | size | ||
| ) | const |
Decide whether a given storage location could be an input parameter.
If the input is locked, check if the location matches one of the current parameters. Otherwise, check if the location could be a parameter based on the prototype model.
| addr | is the starting address of the given storage location |
| size | is the number of bytes in the storage |
| bool FuncProto::possibleOutputParam | ( | const Address & | addr, |
| int4 | size | ||
| ) | const |
Decide whether a given storage location could be a return value.
If the output is locked, check if the location matches the current return value. Otherwise, check if the location could be a return value based on the prototype model.
| addr | is the starting address of the given storage location |
| size | is the number of bytes in the storage |
| void FuncProto::printRaw | ( | const string & | funcname, |
| ostream & | s | ||
| ) | const |
Print this prototype as a single line of text.
| funcname | is an identifier of the function using this prototype |
| s | is the output stream |
| void FuncProto::resolveExtraPop | ( | void | ) |
Assuming this prototype is locked, calculate the extrapop.
If extrapop is unknown and this prototype is locked, try to directly calculate what the extrapop should be. This is really only designed to work with 32-bit x86 binaries.
| void FuncProto::resolveModel | ( | ParamActive * | active | ) |
If this has a merged model, pick the most likely model (from the merged set)
The given parameter trials are used to pick from among the merged ProtoModels and this prototype is changed (specialized) to the pick
| active | is the set of parameter trials to evaluate with |
| void FuncProto::restoreXml | ( | const Element * | el, |
| Architecture * | glb | ||
| ) |
Restore this from an XML stream.
The backing store for the parameters must already be established using either setStore() or setInternal().
| el | is the <prototype> XML element |
| glb | is the Architecture owning the prototype |
| void FuncProto::saveXml | ( | ostream & | s | ) | const |
Save this to an XML stream as a <prototype> tag.
Save everything under the control of this prototype, which may not include input parameters, as these are typically controlled by the function's symbol table scope.
| s | is the output stream |
|
inline |
Toggle whether this prototype is a constructor method.
| val | is true if this is a constructor, false otherwise |
|
inline |
Toggle whether this prototype is a destructor method.
| val | is true if this is a destructor |
|
inline |
Toggle the in-line setting for functions with this prototype.
In-lining can be based on a call-fixup, or the full body of the function can be in-lined.
| val | is true if in-lining should be performed. |
|
inline |
Toggle the input error setting for this prototype.
| val | is true if input parameters should be marked as in error |
| void FuncProto::setInputLock | ( | bool | val | ) |
Toggle the data-type lock on input parameters.
The lock on the data-type of input parameters is set as specified. A true value indicates that future analysis will not change the number of input parameters or their data-type. Zero parameters or void can be locked.
| val | is true to indicate a lock, false for unlocked |
| void FuncProto::setInternal | ( | ProtoModel * | m, |
| Datatype * | vt | ||
| ) |
Set internal backing storage for this.
A prototype model is set, and any parameters added to this during analysis will be backed internally.
| m | is the prototype model to set |
| vt | is the default void data-type to use if the return-value remains unassigned |
| void FuncProto::setModel | ( | ProtoModel * | m | ) |
Set the prototype model for this.
Establish a specific prototype model for this function prototype. Some basic properties are inherited from the model, otherwise parameters are unchanged.
| m | is the new prototype model to set |
|
inline |
Toggle the lock on the prototype model for this.
The prototype model can be locked while still leaving parameters unlocked. Parameter recovery will follow the rules of the locked model.
| val | is true to indicate a lock, false for unlocked |
|
inline |
Toggle the no-return setting for functions with this prototype.
| val | is true to treat the function as never returning |
|
inline |
Toggle the output error setting for this prototype.
| val | is true if return value should be marked as in error |
| void FuncProto::setOutputLock | ( | bool | val | ) |
Toggle the data-type lock on the return value.
The lock of the data-type of the return value is set as specified. A true value indicates that future analysis will not change the presence of or the data-type of the return value. A void return value can be locked.
| val | is true to indicate a lock, false for unlocked |
| void FuncProto::setPieces | ( | const PrototypePieces & | pieces | ) |
Set this prototype based on raw pieces.
The full function prototype is (re)set from a model, names, and data-types The new input and output parameters are both assumed to be locked.
| pieces | is the raw collection of names and data-types |
| bool FuncProto::setReturnBytesConsumed | ( | int4 | val | ) |
Set the number of bytes consumed by callers of this.
This value can be used as a hint as to how much of the return value is important and is used to inform the dead code consume algorithm.
| val | is the estimated number of bytes or 0 |
Set a backing symbol Scope for this.
Input parameters are set based on an existing function Scope and if there is no prototype model the default model is set. Parameters that are added to this during analysis will automatically be reflected in the symbol table. This should only be called during initialization of this prototype.
| s | is the Scope to set |
| startpoint | is a usepoint to associate with the parameters |
|
inline |
Toggle the this-call setting for this prototype.
| val | is true if this prototype uses a this pointer |
| bool FuncProto::unjustifiedInputParam | ( | const Address & | addr, |
| int4 | size, | ||
| VarnodeData & | res | ||
| ) | const |
Check if the given storage location looks like an unjustified input parameter.
The storage for a value may be contained in a normal parameter location but be unjustified within that container, i.e. the least significant bytes are not being used. If this is the case, pass back the full parameter location and return true. If the input is locked, checking is againt the set parameters, otherwise the check is against the prototype model.
| addr | is the starting address of the given storage |
| size | is the number of bytes in the given storage |
| res | is the full parameter storage to pass back |
| void FuncProto::updateAllTypes | ( | const vector< string > & | namelist, |
| const vector< Datatype *> & | typelist, | ||
| bool | dtdtdt | ||
| ) |
Set this entire function prototype based on a list of names and data-types.
Prototype information is provided as separate lists of names and data-types, where the first entry corresponds to the output parameter (return value) and the remaining entries correspond to input parameters. Storage locations and hidden return parameters are calculated, creating a complete function protototype. Existing locks are overridden.
| namelist | is the list of parameter names |
| typelist | is the list of data-types |
| dtdtdt | is true if the new prototype accepts variable argument lists |
| void FuncProto::updateInputNoTypes | ( | const vector< Varnode *> & | triallist, |
| ParamActive * | activeinput, | ||
| TypeFactory * | factory | ||
| ) |
Update input parameters based on Varnode trials, but do not store the data-type.
This is accomplished in the same way as if there were data-types but instead of pulling a data-type from the Varnode, only the size is used. Undefined data-types are pulled from the given TypeFactory
| triallist | is the list of Varnodes |
| activeinput | is the trial container |
| factory | is the given TypeFactory |
| void FuncProto::updateInputTypes | ( | const vector< Varnode *> & | triallist, |
| ParamActive * | activeinput | ||
| ) |
Update input parameters based on Varnode trials.
If the input parameters are locked, don't do anything. Otherwise, given a list of Varnodes and their associated trial information, create an input parameter for each trial in order, grabbing data-type information from the Varnode. Any old input parameters are cleared.
| triallist | is the list of Varnodes |
| activeinput | is the trial container |
| void FuncProto::updateOutputNoTypes | ( | const vector< Varnode *> & | triallist, |
| TypeFactory * | factory | ||
| ) |
Update the return value based on Varnode trials, but don't store the data-type.
If the output parameter is locked, don't do anything. Otherwise, given a list of (at most 1) Varnode, create a return value, grabbing size information from the Varnode. An undefined data-type is created from the given TypeFactory. Any old return value is removed.
| triallist | is the list of Varnodes |
| factory | is the given TypeFactory |
| void FuncProto::updateOutputTypes | ( | const vector< Varnode *> & | triallist | ) |


Display None
visibility Hidden
Counter
{this.count}
This is something
${ (this.count >= 7 && this.count < 11) ? `More than 7 & less than 11` : `` }
greater than 5
DOWN
UP
Text
{color}
{color.color}
Hey inplace {this.count}


I discovered a cool method today while working with a frozen hash containing a frozen array.
deep_dup
From the Rails API Documentation:
Returns a deep copy of hash.
hash = { a: { b: 'b' } } dup = hash.deep_dup dup[:a][:c] = 'c' hash[:a][:c] # => nil dup[:a][:c] # => "c">
Use of this method allowed for a nice refactor:
Before
SANITIZER = AppConfig.sanitizer.default.dup
SANITIZER[:elements] = SANITIZER[:elements].dup
SANITIZER[:elements].push "iframe"
After
SANITIZER = AppConfig.sanitizer.default.deep_dup
SANITIZER[:elements].push "iframe"


So I was able to get the changes into the Cauldron and NPC working faster than I thought I would. I got both tasks done within the first few days and while neither are release ready, I am happy with the progress I made on them this sprint.
There were two main aspects of the Cauldron that I wanted to address in this sprint. The first one was that The initial UI was very confusing and there wasn't a ton of feedback for the player. Additionally none of the buttons were labeled. I added in a progress bar to each of the three stations to show that they were being used as well as labeled all of the buttons in the UI. Eventually I want to add in the herbs used on the screen to show the player what they have used so far however that will be for a later sprint dedicated solely on the Cauldron.
The second aspect is that there was a bug to where if the player clicked on one device while another one was active then both would activate despite the second device not having an herb actually placed in it. I fix this bug by restructuring how herbs were transferred to the device and then cauldron so that the herb was removed when the device was clicked on instead of after it was finished.
For the NPC's I implemented a movement system to where they move between a set number of points that are pre-determined. They have a set amount of time that they "wait" at each point before moving to the next one. When the player talks to the NPC they stop moving to display their dialogue and then continue moving after they finish. The dialogue system itself still needs some work as there isn't anything to it yet but that will be for a future sprint.
This next sprint I have actually already started working on since I finished with my main two tasks early. The next two weeks are going to be focused on getting a decent MVP up and running. Below is the main loop and as you can see there are a few aspects I still need to work on with the main one's being the helping villagers and placing the potions into the shrines. This is also going to include some new herbs and actual potion recipes which I have yet to flesh out. Currently most of the major systems are in place and while I know that this will be one of my largest sprints, I'm hoping that by the end I'll have something more tangible for a gameplay loop that isn't only written down.


The variable information that you entered does not conform to our requirements. Please confirm that:
- Each variable has a distinct name
- Each variable has at least two levels
- The levels of each variable are distinct labels
Cancel and return to dashboard


Panoptic is an initiative by the Internet Freedom Foundation. You can help us scale up initiatives like these by making a donation for digital rights.
Become an IFF member to help sustain the fight for internet freedom. We ask for your support to our corpus to fight in courts, legislative bodies and regulators for ordinary Indian internet users like you.
Donate Now


|
Symmetric Polynomials
V3.1
A C++ library for generating symmetric polynomials with relations
|
For a quick demonstration you may use the binaries found here. These are compiled from Demo.cpp using MSVC (Windows) and GCC (Linux). You can also compile these binaries yourself: For example, on Linux and from within the source
folder use:
g++ Demo.cpp -std=c++17 -O3 -fopenmp -march=native -o Lin64.out
Only the -std=c++17
flag is required; the other flags are for optimization.
Everything in this library is under the namespace symmp (short for Symmetric Polynomials). The code examples that follow will assume we are using this namespace.
So start with:
using symmp;
To specify a polynomial ring such as \(\mathbf Z[x_1,...,x_n]\), \(|x_i|=1\), we use two template parameters:
int64_t
.x_i
(when printed to an output stream) and no relations. We shall explain alternatives in the next few subsections.The zero element of \(\mathbf Z[x_1,...,x_n]\) can then be constructed by:
Poly<int, StandardVariables<>> p;
A nonzero monomial \(cx_1^{a_1}\cdots x_n^{a_n}\) is constructed by providing the exponent vector \([a_1,...,a_n]\) and the coefficient \(c\neq 0\).
For example,
p=Poly<int, StandardVariables<>>({0,1,4},7);
sets \(p=7x_2x_3^4\). Similarly,
auto t=Poly<int, StandardVariables<>>({1,1,2},-8);
sets \(t=-8x_1x_2x_3^2\).
Polynomials can be combined via the usual operators +,-,*
; they can be raised to a nonnegative integer powers by ^
.
For example:
p+=t;
sets \(p=-8x_1x_2x_3^2+7x_2x_3^4\) which can be verified by printing \(p\) to the console:
std::cout << p << "\n";
After that:
std::cout << (p+(p^2))<< "\n";
will print
$$-8x_1x_2x_3^2 + 7x_2x_3^4 + 64x_1^2x_2^2x_3^4 - 112x_1x_2^2x_3^6 + 49x_2^2x_3^8$$
which is exactly \(p+p^2\).
We can substitute StandardVariables with ElementarySymmetricVariables which specify variables with names e_i
, degrees \(|e_i|=i\) and no relations.
Example: The element \(q=-1.5e_1e_2\) of the graded ring \(\mathbf R[e_1,...,e_n], |e_i|=i\), can be defined as:
Poly<double, ElementarySymmetricVariables<>> q({ 2,3 }, -1.5);
For brevity let us use the following two typedefs:
typedef Poly<double, StandardVariables<>> x_poly_t; typedef Poly<double, ElementarySymmetricVariables<>> e_poly_t;
Now we view
\[\mathbf R[e_1,...,e_n]=\mathbf R[x_1,...,x_n]^{\Sigma_n}\]
with \(e_i=\sigma_i\) being the elementary symmetric polynomials on the \(x_i\). To convert \(q\) from \(e_i\) variables to \(x_i\) variables we use the class SymmetricBasis :
SymmetricBasis<x_poly_t, e_poly_t> SB(2);
The 2
signifies that we are using two variables \(x_1,x_2\). Then:
auto qx=SB(q); std::cout << qx;
will set the polynomial x_poly_t qx
to be q
transformed into the \(x_i\) variables (StandardVariables) and print
\[-1.5x_1^3x_2^5 -3x_1^4x_2^4 -1.5x_1^5x_2^3\]
We can perform the conversion the other way as well: given a polynomial on the \(x_i\) variables such as qx
we can use the object same SB
to transform qx
into a polynomial on the \(e_i\) variables :
auto qe=SB(qx); std::cout << qe;
which will print \(-1.5e_1e_2\).
q==qe
evaluates to 1
.We can generate
\[(\mathbf Z[x_1,...,x_n,y_1,...,y_n]/y_i^2=y_i)^{\Sigma_n}\]
by the \(\alpha_i, c_i, \gamma_{s,t}\) (see The Math).
The class TwistedChernBasis allows us to transform polynomials on \(x_i,y_i\) variables (HalfIdempotentVariables) into polynomials on the \(\alpha_i,c_i,\gamma_{s,i}\) (TwistedChernVariables).
Example:
typedef Poly<int, HalfIdempotentVariables<>> xy_poly_t; typedef Poly<int, TwistedChernVariables<>>> chern_poly_t; xy_poly_t r; r.insert({ 1,0,1,0 }, 2); r.insert({ 0,1,0,1 }, 2); TwistedChernBasis<xy_poly_t, chern_poly_t> TCB(2); std::cout << TCB(r) << "\n";
This sets r
to be \(2x_1y_1+2x_2y_2\), transforms it into \(\gamma_{s,j}\) variables and prints the result:
\[-2\gamma_{1,1}+2\alpha_1 c_1\]
And indeed:
\[2x_1y_1+2x_2y_2=-2\gamma_{1,1}+2\alpha_1 c_1\]
If we perform the transformation again we get the original polynomial:
std::cout << TCB(TCB(r)) << "\n";
prints \(2x_1y_1+2x_2y_2\).
2
in the constructor of TCB
is half the number of variables \(x_1,x_2,y_1,y_2\).To print the relations amongst \(\alpha_i,c_i,\gamma_{s,j}\) use:
print_half_idempotent_relations<xy_poly_t, chern_poly_t>(3);
The \(3\) here corresponds to the half the number of variables: \(x_1,x_2,x_3,y_1,y_2,y_3\) and can be replaced by any positive integer.
Finally, Demo.cpp contains another function, pontryagin_via_chern. This prints the expressions of the twisted Pontryagin/symplectic classes:
\[\pi_{s,t}=\kappa_{s,t}=\sum_{1\le i_1< \cdots< i_s\le n\\ 1\le j_1< \cdots< j_t\le n\\ i_u\neq j_v}x^2_{i_1}....x^2_{i_s}y_{j_1}\cdots y_{j_t}\]
in terms of the \(\alpha_i,c_i,\gamma_{s,t}\). For example, try running
pontryagin_via_chern < xy_poly_t, chern_poly_t>(5);


| site_data_dir {rappdirs} | R Documentation |
site_data_dir
returns full path to the user-shared data dir for this application.
site_config_dir
returns full path to the user-specific configuration directory for this application
which returns the same path as site data directory in Windows and Mac but a different one for Unix.
Typical user-shared data directories are:
site_data_dir( appname = NULL, appauthor = appname, version = NULL, multipath = FALSE, expand = TRUE, os = NULL ) site_config_dir( appname = NULL, appauthor = appname, version = NULL, multipath = FALSE, expand = TRUE, os = NULL )
appname |
is the name of application. If NULL, just the system directory is returned. |
appauthor |
(only required and used on Windows) is the name of the appauthor or distributing body for this application. Typically it is the owning company name. This falls back to appname. |
version |
is an optional version path element to append to the
path. You might want to use this if you want multiple versions
of your app to be able to run independently. If used, this
would typically be |
multipath |
is an optional parameter only applicable to *nix which indicates that the entire list of data dirs should be returned By default, the first directory is returned |
expand |
If TRUE (the default) will expand the |
os |
Operating system whose conventions are used to construct the
requested directory. Possible values are "win", "mac", "unix". If |
Mac OS X: /Library/Application Support/<AppName>
Unix: /usr/local/share:/usr/share/
Win XP: C:\\Documents and Settings\\All Users\\Application Data\\<AppAuthor>\\<AppName>
Vista: (Fail! C:\\ProgramData
is a hidden system directory on Vista.)
Win 7: C:\\ProgramData\\<AppAuthor>\\<AppName>
. Hidden, but writeable on Win 7.
Unix also specifies a separate location for user-shared configuration data in $XDG_CONFIG_DIRS.
Unix: /etc/xdg/<AppName>
, in $XDG_CONFIG_HOME if defined
For Unix, this returns the first default. Set the multipath=TRUE
to guarantee returning all directories.
Do not use this on Windows. See the note above for why.


Good Inc. image caption to go here
Quisque accumsan eleifend dolor, nec bibendum nibh ultricies at. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages.


Sales Data
Home
Sales
Sales Data
Adding New Salmon Cookies Locations
New Location Name:
Minimum Customers Number:
Maximum Customers Number:
Avg Customers :


Pefin
UX design of transaction management
UX design and prototype | June 2014-December 2015
All the UI was designed for web and I displayed it on iPad since I was just displaying the part I designed.
-
I worked at Pefin as a UX designer for 6 months, and was in charge of two core functions design among five. One was designing the process of interacting with the transactions, the other was visualizing the data of trends.
-
I want to know how much I spend
on my wedding.Based on our clients’ feedback, costumed tags could be added to transactions and be used as filters to check the total amount. So we had to figure out the logic behind the filters chosen.
-
Logic comes the first.
To make the logic clear, I created two kinds of filter pools. One was for Must-have tags, and the other was for May-have tags. So users can have see any combination of filters. Later, we found it was too complicated for users so we saved it for advanced settings.
Quick sketch for different scenarios
-
Design comes the next.
Traditional table lists and chats
Based on the researches, we decided to do the user interface of transactions as a table list. After studying the presidents, I found most of the table lists were boring and lack of structure, kind of a web-version excel. So I transformed part of the information into visual that can be understood immediately and users canfocus on the transactions without distraction.
Space is better than lines.
I removed the boxes around the elements to make a more clean user interface.
Different sizes are for different layers.
Users could get more clear with the what transactions were made each day by taking a glimpse at the bubble tree.
Use colors properly.
Same color would be used for the same tag. I made a list of colors which matches each other nicely.
To make it more fresh and friendly, I used low saturated color and made a mechanism to select the colors to the filters. ( I would never say any task is easy after realizing the connections between an element to the whole product.)
Other colors were not be presented here.
-
It’s always fun to play with data.
The web pages were designed with both bar chart and pie chart for different needs.
Based on our user testing, people took twice more time on the page when the chart was interactive. So we made animation to made the chart more interesting.
Some bars going slower is for more attention from users and I’m glad people like this design :)
-
Making pixels perfect.
I didn’t have the chance finish the product, and I would love to show you more however this project was under NDA. Here’s only a sneak peak. Please contact me for more details.
-
-
If you'd like to share your feedback about this project, comment it on Medium .


R base functions for inspecting a vertical profile of biological targets
(vp
) object.
# S3 method for vp summary(object, ...) is.vp(x) # S3 method for vp dim(x)
| object | A |
|---|---|
| ... | Additional arguments affecting the summary produced. |
| x | A |
For is.vp()
: TRUE
for an object of class vp
, otherwise
FALSE
.
For dim.vp()
: number of heights and quantities in a vertical
profile (vp
).
A vertical profile of biological targets contains a collection of quantities,
organized in different (typically equally spaced) altitude layers (height
bins) above the earth's surface. A vertical profile (vp
) object is a list
containing:
radar
: Radar identifier.
datetime
: Nominal time of the volume to which the scan belongs in UTC.
data
: A data.frame with the profile's quantities organized per height
bin. Use get_quantity()
to access these:
height
: Height bin (lower bound) in m above sea level.
u
: Speed component west to east in m/s.
v
: Speed component north to south in m/s.
w
: Vertical speed (unreliable!) in m/s.
ff
: Horizontal speed in m/s.
dd
: Direction in degrees clockwise from north.
sd_vvp
: VVP radial velocity standard deviation in m/s.
gap
: Angular data gap detected in T/F.
dbz
: Animal reflectivity factor in dBZ.
eta
: Animal reflectivity in cm^2/km^3.
dens
: Animal density in animals/km^3.
DBZH
: Total reflectivity factor (bio + meteo scattering) in dBZ.
n
: Number of data points used for the ground speed estimates
(quantities u
, v
, w
, ff
, dd
).
n_all
: Number of data points used for the radial velocity standard
deviation estimate (quantity sd_vvp
).
n_dbz
: Number of data points used for reflectivity-based estimates
(quantities dbz
, eta
, dens
).
n_dbz_all
: Number of data points used for the total reflectivity
estimate (quantity DBZH
).
attributes
: List of the vertical profile's what
, where
and how
attributes.
NA
: Maps to nodata
in the ODIM convention: value to denote areas void
of data (never radiated).
NaN
: Maps to undetect
in the ODIM convention: denote areas below the
measurement detection threshold (radiated but nothing detected). The value is
also used when there are too few datapoints to calculate a quantity.
0
: Maps to 0
in the ODIM convention: denote areas where the quantity
has a measured value of zero (radiated and value zero detected or inferred).
It depends on a radar's detection threshold or signal to noise ratio whether
it safe to assume an undetect
is equivalent to zero. When dealing with
close range data only (within 35 km), it is typically safe to assume aerial
densities (dens
) and reflectivities (eta
) are in fact zero in case of
undetects.
# Load the example vertical profile vp <- example_vp # Verify that it is an object of class vp is.vp(vp)#> [1] TRUE# Get summary info vp # Same as summary(vp) or print(vp)#> Vertical profile (class vp) #> #> radar: seang #> source: WMO:02606,RAD:SE50,PLC:Angelholm,NOD:seang,ORG:82,CTY:643,CMT:Swedish radar #> nominal time: 2015-10-18 18:00:00 #> generated by: vol2bird 0.3.17#> [1] 25 16


Payback * (out of * * * * )
Directed by Brian Helgeland.  Reviewed February 6, 1999.
"Payback," Brian Helgeland's inauspicious directing debut (coincidentally, he previously penned the award-winning screenplay for 1997's "L.A. Confidential"), is a wildly uneven and thoroughly unpleasant revenge thriller that takes one idea---a movie with non-stop violence, death, and villains---and runs with it, or should I say, barely manages to crawl away with it.
 Porter is not dead, however---not by a long shot---as he quickly rehabilitates and, along with his loyal prositute girlfriend, Rosie (Maria Bello), sets out to make everyone involved in the scam pay.
The tagline for "Payback" is, "get ready to root for the bad guy," and sure enough, this is true, as pretty much every significant character who appears is crooked in some way. I wouldn't have a problem with this offbeat detail if the painfully thin story had been of any interest, but it wasn't, and therefore, I found myself having an especially laborious time investing myself into a wide array of character that have absolutely no redeeming qualities whatsoever. No attempt is made to flesh the roles into three-dimensional characters, and there are no vacant signs that anyone has any sort of humanity in them. Just because the protagonist, a "bad guy," is played by Mel Gibson doesn't mean I will "root for him," and I didn't.
Since none of the respectable actors in "Payback" actually have human beings to play, only one performance managed to stand out. Lucy Alexis Liu (of T.V.'s "Ally McBeal"), who plays a spicy S&M dominatrix, brightens up every scene she is in, and has a definite flair for comedy, something I would have liked to have seen more of, since most of the humor fell with a resounding splat. Meanwhile, Gibson, who is perfectly fine here, sleepwalks through a role that is not the least bit challenging. Unger, who made an impression in 1997's "The Game," is surprisingly wasted and it is difficult to see why she took such a part since she disappears ten minutes in, and only has two purproses: (1) to get high on heroin, and (2) because she plays a key part in an early flashback. Finally, Kris Kristofferson appears in a throwaway role during the climax, and this unnecessary plot development sticks out like a sore thumb (tellingly, he didn't appear in the original cut of the film, but was cast when extensive reshoots took place months later).
Like most action movies, the star often takes a licking but keeps on ticking. In the course of the 102-minute running time of "Payback," Porter is shot three times in the back, hit by a van, beaten up, and has his feet smashed with a sledgehammer. And guess what? Not only does he survive the whole ordeal, but he is happy-go-lucky in the penultimate sequence (and can still walk!), even though he looks like he had recently substituted for a punching bag.
"Payback" is not, in any way, an entertaining film, even though I am sure the makers hoped it would be with all the graphic carnage that goes on, but take away that violence and what you are basically left with is a blank screen. Perhaps director Helgeland would have been smart to consider this, so he could have at least added a few worthwhile elements, like a fresh storyline and characters whom you could even remotely stand to be around for a few hours.
- Copyright 1999 by Dustin Putman Http://hometown.aol.com/FilmFan16/index.html
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Manchester United could complete January swap transfer in bid to rescue their season
by Mark BrusManchester United are being linked with a stunning January transfer window swap deal involving Gareth Bale and Paul Pogba.
The Red Devils have not made the best start to the 2019/20 season, and that could mean some major business this winter is essential to reviving their hopes of a top four finish.
MORE: Manchester United line up potential £185million double transfer for January
Given that many of United’s issues are in attack at the moment, it could make sense to revive interest in Bale, whose future at Real Madrid has looked in doubt for some time.
According to the Sun, Man Utd were keen on Bale in the summer and could be interested again as they’re after a big-name signing to rescue their season.
The Wales international nearly left for Chinese Super League club Jiangsu Suning in the summer, according to the Sun, and they add that Real remain prepared to do business this winter.
However, this would likely involve a push from the Spanish giants to land MUFC midfielder Pogba as part of the deal.
While this seems risky for United, the Frenchman has not ever really hit top form in his time at Old Trafford and has also had some recent injury problems.
It may well be that this is an ideal time for the Premier League giants to offload Pogba and strengthen in an arguably more important area of their squad.


This page is under construction and will contain a live styleguide which demonstrates the usage of the holon component


NOTE: QuACS is currently showing course schedules for Summer 2020
Welcome to QuACS!
This website was quickly made because I dont understand how yacs has not been updated yet and I found it very hard to visualize course conflicts without yacs
You can view the source code here
https://github.com/elihschiff/quacs. Feel free to make a PR or add an issue. I will try to fix any bugs.
- ELi
How to use:
- To use the website, click the checkbox next to any section of classes to add it to classes you plan on registering for.
- Then, click the check conflict button next to any class to see if it conflicts with any of the classes you have selected.
- Please notice that the "check conflict" button only checks for conflicts regarding that specific course, but it does not account for any conflicts that may exist between the courses you have already selected.
- If the button flashes green, that course does not conflict with any of the classes you have selected. If it flashes red, it does conflict.
- This website will also account for 6 week courses. So, if 2 courses happen at the same time, but during different halves of the sumemr, they will not be marked as conflicting.
Selected courses:
{{crn}} {{crn_to_name[crn]}}
All courses:


I've learned the basics of programming and web development from several online learning sites including Lynda.com, freeCodeCamp, Codeschool.com, and various Udemy and Coursera courses. I've learned by building projects from these courses and some of my own. I have also learned many other skills in the digital and tangible relms through online courses. I'm enrolled at CCSF. I'm a life-long learner.
I enjoy design and coding websites using these technologies
You can find me on Twitter @sev_welker


--- layout: default nav: attributes > ic-transition ---
ic-transition
The ic-transition attribute can specify the transition to use when replacing an element
Currently only two values are supported: fade and none
fade
none


Fullwidth List of Split
Style One
Reach and grow your audience.
Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit. Cras mattis consectetur purus sit amet fermentum. Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Praesent commodo cursus magna, vel scelerisque nisl consectetur et.
Style Two (Reversed)
Reach and grow your audience.


deals of the day
Badminton
under 299
sports&fitness
Bracelet & bracelet sets
Just 499
Grab or gone
mobile accesories
under 999
Explore now
Lights & LED
Min 10% off
Household stuff
Men's footwear
Min 50% off
Grab it
Discounts for you
Pendrive
Min 20% off
Computer accesories
Womes's wear
Just 999
Hurry up
Sandal
under 699
Grab now
Bedsheet
Min 10% off
Household stuff
Television
Min 50% off
Buy it
Cycles
under 2999
sports&fitness
Clock
Just 499
Grab or gone
Gears
under 999
Explore now
Toys
Min 10% off
Playing accesories


Instantiator QML Type
Dynamically creates objects More...
| Import Statement: | import QtQml 2.2 |
Properties
- active : bool
- asynchronous : bool
- count : int
- delegate : QtQml::Component
- model : variant
- object : QtObject
Signals
- objectAdded(int index, QtObject object)
- objectRemoved(int index, QtObject object)
Methods
- QtObject objectAt(int index)
Detailed Description
A Instantiator can be used to control the dynamic creation of objects, or to dynamically create multiple objects from a template.
The Instantiator element will manage the objects it creates. Those objects are parented to the Instantiator and can also be deleted by the Instantiator if the Instantiator's properties change. Objects can also be destroyed dynamically through other means, and the Instantiator will not recreate them unless the properties of the Instantiator change.
Property Documentation
When active is true, and the delegate component is ready, the Instantiator will create objects according to the model. When active is false, no objects will be created and any previously created objects will be destroyed.
Default is true.
When asynchronous is true the Instantiator will attempt to create objects asynchronously. This means that objects may not be available immediately, even if active is set to true.
You can use the objectAdded signal to respond to items being created.
Default is false.
[default] delegate : QtQml::Component |
The component used to create all objects.
Note that an extra variable, index, will be available inside instances of the delegate. This variable refers to the index of the instance inside the Instantiator, and can be used to obtain the object through the objectAt method of the Instantiator.
If this property is changed, all instances using the old delegate will be destroyed and new instances will be created using the new delegate.
model : variant |
This property can be set to any of the supported data models:
- A number that indicates the number of delegates to be created by the repeater
- A model (e.g. a ListModel item, or a QAbstractItemModel subclass)
- A string list
- An object list
The type of model affects the properties that are exposed to the delegate.
Default value is 1, which creates a single delegate instance.
See also Data Models.
object : QtObject |
This is a reference to the first created object, intended as a convenience for the case where only one object has been created.
Signal Documentation
objectAdded(int index, QtObject object) |
This signal is emitted when an object is added to the Instantiator. The index parameter holds the index which the object has been given, and the object parameter holds the QtObject that has been added.
The corresponding handler is onObjectAdded
.
objectRemoved(int index, QtObject object) |
This signal is emitted when an object is removed from the Instantiator. The index parameter holds the index which the object had been given, and the object parameter holds the QtObject that has been removed.
Do not keep a reference to object if it was created by this Instantiator, as in these cases it will be deleted shortly after the signal is handled.
The corresponding handler is onObjectRemoved
.
Method Documentation
QtObject objectAt(int index) |
Returns a reference to the object with the given index.


This file describes the coding style used in most C files in the Open vSwitch distribution. However, Linux kernel code datapath directory follows the Linux kernel's established coding conventions. For the Windows kernel datapath code, use the coding style described in datapath-windows/CodingStyle.
The following GNU indent options approximate this style:
-npro -bad -bap -bbb -br -blf -brs -cdw -ce -fca -cli0 -npcs -i4 -l79 \
-lc79 -nbfda -nut -saf -sai -saw -sbi4 -sc -sob -st -ncdb -pi4 -cs -bs \
-di1 -lp -il0 -hnl
Limit lines to 79 characters.
Use form feeds (control+L) to divide long source files into logical pieces. A form feed should appear as the only character on a line.
Do not use tabs for indentation.
Avoid trailing spaces on lines.
Use names that explain the purpose of a function or object.
Use underscores to separate words in an identifier: multiwordname.
Use lowercase for most names. Use uppercase for macros, macro parameters, and members of enumerations.
Give arrays names that are plural.
Pick a unique name prefix (ending with an underscore) for each module, and apply that prefix to all of that module's externally visible names. Names of macro parameters, struct and union members, and parameters in function prototypes are not considered externally visible for this purpose.
Do not use names that begin with . If you need a name for "internal use only", use _ as a suffix instead of a prefix.
Avoid negative names: "found" is a better name than "not_found".
In names, a "size" is a count of bytes, a "length" is a count of characters. A buffer has size, but a string has length. The length of a string does not include the null terminator, but the size of the buffer that contains the string does.
Comments should be written as full sentences that start with a capital letter and end with a period. Put two spaces between sentences.
Write block comments as shown below. You may put the /* and */ on the same line as comment text if you prefer.
/*
* We redirect stderr to /dev/null because we often want to remove all
* traffic control configuration on a port so its in a known state. If
* this done when there is no such configuration, tc complains, so we just
* always ignore it.
*/
Each function and each variable declared outside a function, and each struct, union, and typedef declaration should be preceded by a comment. See FUNCTION DEFINITIONS below for function comment guidelines.
Each struct and union member should each have an inline comment that explains its meaning. structs and unions with many members should be additionally divided into logical groups of members by block comments, e.g.:
/* An event that will wake the following call to poll_block(). */
struct poll_waiter {
/* Set when the waiter is created. */
struct ovs_list node; /* Element in global waiters list. */
int fd; /* File descriptor. */
short int events; /* Events to wait for (POLLIN, POLLOUT). */
poll_fd_func *function; /* Callback function, if any, or null. */
void *aux; /* Argument to callback function. */
struct backtrace *backtrace; /* Event that created waiter, or null. */
/* Set only when poll_block() is called. */
struct pollfd *pollfd; /* Pointer to element of the pollfds array
(null if added from a callback). */
};
Use XXX or FIXME comments to mark code that needs work.
Don't use //
comments.
Don't comment out or #if 0 out code. Just remove it. The code that was there will still be in version control history.
Put the return type, function name, and the braces that surround the function's code on separate lines, all starting in column 0.
Before each function definition, write a comment that describes the function's purpose, including each parameter, the return value, and side effects. References to argument names should be given in single-quotes, e.g. 'arg'. The comment should not include the function name, nor need it follow any formal structure. The comment does not need to describe how a function does its work, unless this information is needed to use the function correctly (this is often better done with comments inside the function).
Simple static functions do not need a comment.
Within a file, non-static functions should come first, in the order that they are declared in the header file, followed by static functions. Static functions should be in one or more separate pages (separated by form feed characters) in logical groups. A commonly useful way to divide groups is by "level", with high-level functions first, followed by groups of progressively lower-level functions. This makes it easy for the program's reader to see the top-down structure by reading from top to bottom.
All function declarations and definitions should include a prototype. Empty parentheses, e.g. "int foo();", do not include a prototype (they state that the function's parameters are unknown); write "void" in parentheses instead, e.g. "int foo(void);".
Prototypes for static functions should either all go at the top of the file, separated into groups by blank lines, or they should appear at the top of each page of functions. Don't comment individual prototypes, but a comment on each group of prototypes is often appropriate.
In the absence of good reasons for another order, the following parameter order is preferred. One notable exception is that data parameters and their corresponding size parameters should be paired.
Status parameter.
Example:
``` /* Stores the features supported by 'netdev' into each of '*current',
Functions that destroy an instance of a dynamically-allocated type should accept and ignore a null pointer argument. Code that calls such a function (including the C standard library function free()) should omit a null-pointer check. We find that this usually makes code easier to read.
Functions in .c files should not normally be marked "inline", because it does not usually help code generation and it does suppress compilers warnings about unused functions. (Functions defined in .h usually should be marked inline.)
Put the return type and function name on the same line in a function prototype:
static const struct option_class *get_option_class(int code);
Omit parameter names from function prototypes when the names do not give useful information, e.g.:
int netdev_get_mtu(const struct netdev *, int *mtup);
Indent each level of code with 4 spaces. Use BSD-style brace placement:
if (a()) {
b();
d();
}
Put a space between "if", "while", "for", etc. and the expressions that follow them.
Enclose single statements in braces:
if (a > b) {
return a;
} else {
return b;
}
Use comments and blank lines to divide long functions into logical groups of statements.
Avoid assignments inside "if" and "while" conditions.
Do not put gratuitous parentheses around the expression in a return statement, that is, write "return 0;" and not "return(0);"
Write only one statement per line.
Indent "switch" statements like this:
switch (conn->state) {
case S_RECV:
error = run_connection_input(conn);
break;
case S_PROCESS:
error = 0;
break;
case S_SEND:
error = run_connection_output(conn);
break;
default:
OVS_NOT_REACHED();
}
"switch" statements with very short, uniform cases may use an abbreviated style:
switch (code) {
case 200: return "OK";
case 201: return "Created";
case 202: return "Accepted";
case 204: return "No Content";
default: return "Unknown";
}
Use "for (;;)" to write an infinite loop.
In an if/else construct where one branch is the "normal" or "common" case and the other branch is the "uncommon" or "error" case, put the common case after the "if", not the "else". This is a form of documentation. It also places the most important code in sequential order without forcing the reader to visually skip past less important details. (Some compilers also assume that the "if" branch is the more common case, so this can be a real form of optimization as well.)
For functions that return a success or failure indication, prefer one of the following return value conventions:
An "int" where 0 indicates success and a positive errno value indicates a reason for failure.
A "bool" where true indicates success and false indicates failure.
Don't define an object-like macro if an enum can be used instead.
Don't define a function-like macro if a "static inline" function can be used instead.
If a macro's definition contains multiple statements, enclose them with "do { ... } while (0)" to allow them to work properly in all syntactic circumstances.
Do use macros to eliminate the need to update different parts of a single file in parallel, e.g. a list of enums and an array that gives the name of each enum. For example:
/* Logging importance levels. */
#define VLOG_LEVELS \
VLOG_LEVEL(EMER, LOG_ALERT) \
VLOG_LEVEL(ERR, LOG_ERR) \
VLOG_LEVEL(WARN, LOG_WARNING) \
VLOG_LEVEL(INFO, LOG_NOTICE) \
VLOG_LEVEL(DBG, LOG_DEBUG)
enum vlog_level {
#define VLOG_LEVEL(NAME, SYSLOG_LEVEL) VLL_##NAME,
VLOG_LEVELS
#undef VLOG_LEVEL
VLL_N_LEVELS
};
/* Name for each logging level. */
static const char *level_names[VLL_N_LEVELS] = {
#define VLOG_LEVEL(NAME, SYSLOG_LEVEL) #NAME,
VLOG_LEVELS
#undef VLOG_LEVEL
};
Use the macros in lib/compiler.h to annotate locking requirements. For example:
static struct ovs_mutex mutex = OVS_MUTEX_INITIALIZER;
static struct ovs_rwlock rwlock = OVS_RWLOCK_INITIALIZER;
void function_require_plain_mutex(void) OVS_REQUIRES(mutex);
void function_require_rwlock(void) OVS_REQ_RDLOCK(rwlock);
Pass lock objects, not their addresses, to the annotation macros. (Thus we have OVSREQUIRES(mutex) above, not OVSREQUIRES(&mutex).)
Each source file should state its license in a comment at the very top, followed by a comment explaining the purpose of the code that is in that file. The comment should explain how the code in the file relates to code in other files. The goal is to allow a programmer to quickly figure out where a given module fits into the larger system.
The first non-comment line in a .c source file should be:
#include <config.h>
#include
directives should appear in the following order:
#include <config.h>
The module's own headers, if any. Including this before any
other header (besides
Standard C library headers and other system headers, preferably in alphabetical order. (Occasionally one encounters a set of system headers that must be included in a particular order, in which case that order must take precedence.)
Open vSwitch headers, in alphabetical order. Use "", not <>, to specify Open vSwitch header names.
Each header file should start with its license, as described under SOURCE FILES above, followed by a "header guard" to make the header file idempotent, like so:
#ifndef NETDEV_H
#define NETDEV_H 1
...
#endif /* netdev.h */
Header files should be self-contained; that is, they should #include whatever additional headers are required, without requiring the client to #include them for it.
Don't define the members of a struct or union in a header file, unless client code is actually intended to access them directly or if the definition is otherwise actually needed (e.g. inline functions defined in the header need them).
Similarly, don't #include a header file just for the declaration of
a struct or union tag (e.g. just for "struct
Use typedefs sparingly. Code is clearer if the actual type is visible at the point of declaration. Do not, in general, declare a typedef for a struct, union, or enum. Do not declare a typedef for a pointer type, because this can be very confusing to the reader.
A function type is a good use for a typedef because it can clarify code. The type should be a function type, not a pointer-to-function type. That way, the typedef name can be used to declare function prototypes. (It cannot be used for function definitions, because that is explicitly prohibited by C89 and C99.)
You may assume that "char" is exactly 8 bits and that "int" and "long" are at least 32 bits.
 If you
need to cast a pointer to an integer, use "intptrt" or "uintptrt"
from
Use the int
For compatibility with antique printf() implementations:
Instead of "%zu", use "%"PRIuSIZE.
Instead of "%td", use "%"PRIdPTR.
Instead of "%ju", use "%"PRIuMAX.
Other variants exist for different radixes. For example, use "%"PRIxSIZE instead of "%zx" or "%x" instead of "%hhx".
Also, instead of "%hhd", use "%d". Be cautious substituting "%u", "%x", and "%o" for the corresponding versions with "hh": cast the argument to unsigned char if necessary, because printf("%hhu", -1) prints 255 but printf("%u", -1) prints<PHONE_NUMBER>.
Use bit-fields sparingly. Do not use bit-fields for layout of network protocol fields or in other circumstances where the exact format is important.
Declare bit-fields to be signed or unsigned integer types or _Bool (aka bool). Do not declare bit-fields of type "int": C99 allows these to be either signed or unsigned according to the compiler's whim. (A 1-bit bit-field of type "int" may have a range of -1...0!)
Try to order structure members such that they pack well on a system with 2-byte "short", 4-byte "int", and 4- or 8-byte "long" and pointer types. Prefer clear organization over size optimization unless you are convinced there is a size or speed benefit.
Pointer declarators bind to the variable name, not the type name. Write "int x", not "int x" and definitely not "int * x".
Put one space on each side of infix binary and ternary operators:
* / %
+ -
<< >>
< <= > >=
== !=
&
^
|
&&
||
?:
= += -= *= /= %= &= ^= |= <<= >>=
Avoid comma operators.
Do not put any white space around postfix, prefix, or grouping operators:
() [] -> .
! ~ ++ -- + - * &
Exception 1: Put a space after (but not before) the "sizeof" keyword. Exception 2: Put a space between the () used in a cast and the expression whose type is cast: (void *) 0.
Break long lines before the ternary operators ? and :, rather than after them, e.g.
return (out_port != VIGP_CONTROL_PATH
? alpheus_output_port(dp, skb, out_port)
: alpheus_output_control(dp, skb, fwd_save_skb(skb),
VIGR_ACTION));
Do not parenthesize the operands of && and || unless operator precedence makes it necessary, or unless the operands are themselves expressions that use && and ||. Thus:
if (!isdigit((unsigned char)s[0])
|| !isdigit((unsigned char)s[1])
|| !isdigit((unsigned char)s[2])) {
printf("string %s does not start with 3-digit code\n", s);
}
but
if (rule && (!best || rule->priority > best->priority)) {
best = rule;
}
Do parenthesize a subexpression that must be split across more than one line, e.g.:
*idxp = ((l1_idx << PORT_ARRAY_L1_SHIFT)
| (l2_idx << PORT_ARRAY_L2_SHIFT)
| (l3_idx << PORT_ARRAY_L3_SHIFT));
Try to avoid casts. Don't cast the return value of malloc().
The "sizeof" operator is unique among C operators in that it accepts two very different kinds of operands: an expression or a type. In general, prefer to specify an expression, e.g. "int *x = xmalloc(sizeof *x);". When the operand of sizeof is an expression, there is no need to parenthesize that operand, and please don't.
Use the ARRAY_SIZE macro from lib/util.h to calculate the number of elements in an array.
When using a relational operator like "<" or "==", put an expression or variable argument on the left and a constant argument on the right, e.g. "x == 0", not "0 == x".
Put one blank line between top-level definitions of functions and global variables.
Most C99 features are OK because they are widely implemented:
Flexible array members (e.g. struct { int foo[]; }).
"static inline" functions (but no other forms of "inline", for which GCC and C99 have differing interpretations).
"long long"
bool and
Designated initializers (e.g. "struct foo foo = {.a = 1};" and "int a[] = {[2] = 5};").
Mixing of declarations and code within a block. Please use this judiciously; keep declarations nicely grouped together in the beginning of a block if possible.
Use of declarations in iteration statements (e.g. "for (int i = 0; i < 10; i++)").
Use of a trailing comma in an enum declaration (e.g. "enum { x = 1, };").
As a matter of style, avoid // comments.
Avoid using GCC or Clang extensions unless you also add a fallback for other compilers. You can, however, use C99 features or GCC extensions also supported by Clang in code that compiles only on GNU/Linux (such as lib/netdev-linux.c), because GCC is the system compiler there.
When introducing new Python code, try to follow Python's
PEP 8 style.
Consider running the pep8
or flake8
tool against your
code to find issues.


My App has been created during some sad moments of a terrific life
My App has been created by the following people:


While the primary target audience is blind users, ChromeVox provides rich
visuals that highlight its interactions with the page. These are important
for developers and testers, for side-by-side use of the same computer by
blind and sighted companions, and for low-vision users who need a hybrid
interface.
ChromeVox adds visuals by adding new elements to the web page DOM that are
rendered on top of page content by giving them a large z-index. The current visuals
include:
-
Active Indicator
- A glowing outline around the current object or text rage
that ChromeVox is focused on; this is synchronized with browser focus
but can also land on static content that’s not normally focusable.
-
Lens
- A visual transcript of the text that ChromeVox spoke in a large font. This
enables sighted testers and developers to quickly check accessible behavior
without listening to speech (which may be cumbersome for users who
aren’t used to it), while also providing a hybrid interface for low-vision
users.


Learn
Try
Docs
Plugins
Download
Starting Out
Introduction
License
Starting Out
Introduction
License
Starting Out
Introduction
License
Copyright (c) 2013 Evan Moran
OJ may be freely distributed under the
MIT license


A newer upstream version ({{ s.upstream_version }})
is available. Consider packaging the new version for
MSYS2 as well. See the
packaging guide for how to help.
{% endif %}
Group(s):
{% for g in s.groups %}
{{ g }}{{ ", " if not loop.last else "" }}
{% else %}
-
{% endfor %}
Repo(s):
{% for r in s.repos %}
{{ r }}{{ ", " if not loop.last else "" }}
{% else %}
-
{% endfor %}


Lorem ipsum dolor amet tumeric quinoa semiotics man braid, keytar whatever taxidermy 90's blue bottle selvage paleo stumptown pickled activaYOLO keytar literally blog pitchfork. PBR&B godard vexillologist pinterest.
Lorem ipsum dolor amet tumeric quinoa semiotics man braid, keytar whatever taxidermy 90's blue bottle selvage paleo stumptown pickled activaYOLO keytar literally blog pitchfork. PBR&B godard vexillologist pinterest.
Lorem ipsum dolor amet tumeric quinoa semiotics man braid, keytar whatever taxidermy 90's blue bottle selvage paleo stumptown pickled activaYOLO keytar literally blog pitchfork. PBR&B godard vexillologist pinterest.  PBR&B godard vexillologist pinterest.
lor amet tumeric quinoa semiotics man braid, keytar whatever taxidermy 90's blue bottle selvage paleo stumptown pickled activaYOLO keytar literally blog pitchfork. PBR&B godard vexillologist pinterest.
lor amet tumeric quinoa semiotics man braid, keytar whatever taxidermy 90's blue bottle selvage paleo stumptown pickled activaYOLO keytar literally blog pitchfork. PBR&B godard vexillologist pinterest.


The purpose of a server is to share data as well as to share resources and distribute work.
A server computer can serve its own computer programs as well; depending on the scenario, this could be part of a quid pro quo transaction, or simply a technical possibility. The following table shows several scenarios in which a server is used. A server computer can serve its own computer programs as well; depending on the scenario, this could be part of a quid pro quo transaction, or simply a technical possibility. The following table shows several scenarios in which a server is used.


Last updated: 2018-06-22
workflowr checks: (Click a bullet for more information) ✔ R Markdown file: up-to-date
Great! Since the R Markdown file has been committed to the Git repository, you know the exact version of the code that produced these results.
✔ Repository version: 5567f49
wflow_publish
or wflow_git_commit
). workflowr only checks the R Markdown file, but you know if there are other scripts or data files that it depends on. Below is the status of the Git repository when the results were generated:
Untracked files:
Untracked: output/44binary.txt.gz
Untracked: output/bmaonlybetasd5lfsr.txt.gz
Untracked: output/bmaonlybetasd5posterior.means.txt.gz
Untracked: output/independentsim.rds
Untracked: output/independentsimesd05.rds
Untracked: output/independentsiminputdata
Untracked: output/independenttest.txt
Untracked: output/indsim05sdlfsr.txt.gz
Untracked: output/indsim05sdposterior.means.txt.gz
Untracked: output/logBFTABLEapril.txt
Untracked: output/noashsharedwithzerobmaalllfsr.txt.gz
Untracked: output/noashsharedwithzerobmaallposterior.means.txt.gz
Untracked: output/sharedashcutoffomega2jun15lfsr.txt.gz
Untracked: output/sharedashcutoffomega2jun15posterior.means.txt.gz
Untracked: output/sharedtest
Untracked: output/simdata.rds
Untracked: output/univariate.ash.lfsr.txt.gz
Untracked: output/univariate.ash.pm.txt.gz
Untracked: output/univariate.ash.pmindesd.txt.gz
Untracked: output/univariate.ashind.lfsresd.txt.gz
Unstaged changes:
Modified: README.md
Note that any generated files, e.g. HTML, png, CSS, etc., are not included in this status report because it is ok for generated content to have uncommitted changes.
| File | Version | Author | Date | Message |
|---|---|---|---|---|
| Rmd | 5567f49 | Peter Carbonetto | 2018-06-22 | wflow_publish(“index.Rmd”) |
| html | 30c6a41 | Peter Carbonetto | 2018-06-21 | Build site. |
| Rmd | f224917 | Peter Carbonetto | 2018-06-21 | wflow_publish(c(“index.Rmd”, “gtexanalysis.Rmd”, “gtexdata.Rmd”)) |
| Rmd | 39d38a8 | Peter Carbonetto | 2018-06-21 | wflow_publish(“index.Rmd”) |
| html | f3feee1 | Peter Carbonetto | 2018-06-21 | Added gtexdata link to home page, and to navbar. |
| Rmd | 3ac4f03 | Peter Carbonetto | 2018-06-21 | wflow_publish(“index.Rmd”) |
| Rmd | e9d1bb2 | Peter Carbonetto | 2018-06-19 | wflow_publish(“index.Rmd”) |
| html | 00b767a | Peter Carbonetto | 2018-06-19 | Made a few small changes to descriptions. |
| Rmd | 08b3e3a | Peter Carbonetto | 2018-06-19 | wflow_publish(“index.Rmd”) |
| html | 3ab329f | Peter Carbonetto | 2018-06-18 | Build site. |
| html | 23c6dda | Peter Carbonetto | 2018-06-04 | More revisions to gtex and index pages. |
| Rmd | f645bba | Peter Carbonetto | 2018-06-04 | wflow_publish(c(“index.Rmd”, “gtex.Rmd”)) |
| html | 03a35cb | Peter Carbonetto | 2018-06-04 | Added “What’s included” section to index. |
| Rmd | b152386 | Peter Carbonetto | 2018-06-04 | wflow_publish(“index.Rmd”) |
| html | 45bcaa8 | Peter Carbonetto | 2018-06-04 | Re-built main webpages after several updates and improvements. |
| Rmd | fe0bcf7 | Peter Carbonetto | 2018-06-04 | wflow_publish(c(“index.Rmd”, “gtex.Rmd”, “fastqtl2mash.Rmd”)) |
| Rmd | 1131043 | Peter Carbonetto | 2018-06-01 | Minor change to homepage. |
| html | fe6f00c | Peter Carbonetto | 2018-06-01 | Fixed links in navbar. |
| Rmd | b82193c | Peter Carbonetto | 2018-06-01 | Moved some output files to data folder; removed some old files from |
| html | 8877b63 | Peter Carbonetto | 2018-06-01 | Moved details of GTEx analysis away from home page. |
| Rmd | ad4ab2a | Peter Carbonetto | 2018-06-01 | wflow_publish(“index.Rmd”) |
| html | be63841 | Peter Carbonetto | 2018-06-01 | More changes to navigation bar. |
| html | b2b5ff9 | Peter Carbonetto | 2018-06-01 | Re-built home page with new navbar. |
| Rmd | eade155 | Peter Carbonetto | 2018-06-01 | wflow_publish(“index.Rmd”) |
| html | f42f07a | Peter Carbonetto | 2018-06-01 | This is a new, pared-down version of the home page. |
| Rmd | 7ec0c30 | Peter Carbonetto | 2018-06-01 | wflow_publish(“index.Rmd”) |
| Rmd | 64caf96 | Peter Carbonetto | 2018-05-31 | Removed most of the materials from the README. |
| Rmd | b98e680 | Gao Wang | 2018-05-31 | Change workflow output folder |
| Rmd | bd0c3fd | Peter Carbonetto | 2018-05-22 | Working on improvements to Fig.GTExExamples.Rmd. |
| Rmd | 2c9e37b | Peter Carbonetto | 2018-05-16 | A few very minor misc. changes. |
| html | 9ce5080 | Peter Carbonetto | 2018-05-14 | Removed R code chunk from index.Rmd. |
| html | abda373 | Peter Carbonetto | 2018-05-14 | Built index.Rmd with new version of workflowr that speeds up |
| Rmd | e7d0e05 | Peter Carbonetto | 2018-05-14 | wflow_publish(“index.Rmd”) |
| Rmd | f4fd799 | Peter Carbonetto | 2018-05-07 | Added step to install packages in instructions (index.Rmd). |
| html | 6206baf | Peter Carbonetto | 2018-05-07 | wflow_publish(“index.Rmd”) took 10 min to complete: |
| Rmd | a58aa04 | Peter Carbonetto | 2018-05-07 | wflow_publish(“index.Rmd”) |
| html | 5c5e02c | Peter Carbonetto | 2018-05-07 | Ran wflow_publish(“index.Rmd”). |
| Rmd | f30f3d6 | Peter Carbonetto | 2018-05-07 | wflow_publish(“index.Rmd”) |
| Rmd | 1668be6 | Peter Carbonetto | 2018-05-07 | Setting up workflowr settings. |
| html | 1668be6 | Peter Carbonetto | 2018-05-07 | Setting up workflowr settings. |
| Rmd | da461d8 | Peter Carbonetto | 2018-05-07 | Added workflowr <IP_ADDRESS>00 files. |
| html | 3c053c7 | Gao Wang | 2017-09-20 | Fix one more broken link |
| html | 094708a | Gao Wang | 2017-09-20 | Update figures |
| html | aecc7f1 | Peter Carbonetto | 2017-09-20 | Moved doc to docs. |
This repository contains code and data resources to accompany our research paper:
Sarah M. Urbut, Gao Wang and Matthew Stephens (2017). Flexible statistical methods for estimating and testing effects in genomic studies with multiple conditions. bioRxiv doi:10.1101/096552.
We provide four sets of resources:
If you are primarily interested in applying the multivariate adaptive shrinkage (mash) methods to your own data, please see the mashr R package.
If you would like to obtain the exact GTEx association statistics used in the multivariate adaptive shrinkage (mash) analysis described in our research paper (e.g., so you can apply your method of choice to these data, and compare against our results), please see here.
If you would like follow the exact steps we took to produce the results of the GTEx analysis presented in the manuscript, follow the instructions here. Note: The mashr package was not used in this analysis because mashr was only developed afterward.
If you are working with association statistics from the GTEx study, or similar genetic association data, please see here for our code to convert association statistics in the FastQTL format, or a similar format, to a format that is more suitable for analysis with mash.
If you find any of the source code in this repository useful for your work, please cite our manuscript, Urbut et al (2017). The full citation is given above. Please also cite the Zenodo archive:
Sarah M. Urbut, Gao Wang, Peter Carbonetto and Matthew Stephens (2018), Code and data resources accompanying Urbut et al 2017, version 1.0, Zenodo, doi:10.5281/zenodo.1296399.
Copyright (c) 2016-2018, Sarah Urbut, Gao Wang, Peter Carbonetto and Matthew Stephens.
All source code and software in this repository are made available under the terms of the MIT license.
See here for the source repository. This is what you will find in the repository:
├── analysis
├── code
├── data
├── docs
├── output
└── workflows
The analysis contains R Markdown source files for the workflowr website, including R code used in the final step of the analysis to generate figures and tables for the manuscript.
The code directory contains additional supporting code for the analyses.
The data directory contains original and processed data files used in the mash analysis of the GTEx data, example data sets used to illustrate the data processing and analysis pipelines, and additional data used to generate the tables and figures for the manuscript.
The docs directory contains webpages generated from the R Markdown files in the analysis directory.
The output stores outputs from data processing and analysis pipelines (“workflows”).
The workflows directory contains source code (“SoS workflows”) and Docker configuration files (“Dockerfiles”) implementing a data processing pipeline for mash and an end-to-end analysis of the GTEx data using the multivariate statistical methods (“mash”).
This project was developed by Sarah Urbut, Gao Wang, Peter Carbonetto and Matthew Stephens at the University of Chicago.
This reproducible R Markdown analysis was created with workflowr <IP_ADDRESS>00