This document is the central repository for all information pertaining to debug information in LLVM. It describes the actual format that the LLVM debug information takes, which is useful for those interested in creating front-ends or dealing directly with the information. Further, this document provides specifc examples of what debug information for C/C++.
The idea of the LLVM debugging information is to capture how the important pieces of the source-language's Abstract Syntax Tree map onto LLVM code. Several design aspects have shaped the solution that appears here. The important ones are:
The approach used by the LLVM implementation is to use a small set of intrinsic functions to define a mapping between LLVM program objects and the source-level objects. The description of the source-level program is maintained in LLVM global variables in an implementation-defined format (the C/C++ front-end currently uses working draft 7 of the Dwarf 3 standard).
When a program is being debugged, a debugger interacts with the user and turns the stored debug information into source-language specific information. As such, a debugger must be aware of the source-language, and is thus tied to a specific language or family of languages.
The role of debug information is to provide meta information normally stripped away during the compilation process. This meta information provides an LLVM user a relationship between generated code and the original program source code.
Currently, debug information is consumed by the DwarfWriter to produce dwarf information used by the gdb debugger. Other targets could use the same information to produce stabs or other debug forms.
It would also be reasonable to use debug information to feed profiling tools for analysis of generated code, or, tools for reconstructing the original source from generated code.
TODO - expound a bit more.
An extremely high priority of LLVM debugging information is to make it interact well with optimizations and analysis. In particular, the LLVM debug information provides the following guarantees:
Basically, the debug information allows you to compile a program with "-O0 -g" and get full debug information, allowing you to arbitrarily modify the program as it executes from a debugger. Compiling a program with "-O3 -g" gives you full debug information that is always available and accurate for reading (e.g., you get accurate stack traces despite tail call elimination and inlining), but you might lose the ability to modify the program and call functions where were optimized out of the program, or inlined away completely.
LLVM test suite provides a framework to test optimizer's handling of debugging information. It can be run like this:
% cd llvm/projects/test-suite/MultiSource/Benchmarks # or some other level % make TEST=dbgopt
This will test impact of debugging information on optimization passes. If debugging information influences optimization passes then it will be reported as a failure. See TestingGuide for more information on LLVM test infrastructure and how to run various tests.
LLVM debugging information has been carefully designed to make it possible for the optimizer to optimize the program and debugging information without necessarily having to know anything about debugging information. In particular, the global constant merging pass automatically eliminates duplicated debugging information (often caused by header files), the global dead code elimination pass automatically deletes debugging information for a function if it decides to delete the function, and the linker eliminates debug information when it merges linkonce functions.
To do this, most of the debugging information (descriptors for types, variables, functions, source files, etc) is inserted by the language front-end in the form of LLVM global variables. These LLVM global variables are no different from any other global variables, except that they have a web of LLVM intrinsic functions that point to them. If the last references to a particular piece of debugging information are deleted (for example, by the -globaldce pass), the extraneous debug information will automatically become dead and be removed by the optimizer.
Debug information is designed to be agnostic about the target debugger and debugging information representation (e.g. DWARF/Stabs/etc). It uses a generic machine debug information pass to decode the information that represents variables, types, functions, namespaces, etc: this allows for arbitrary source-language semantics and type-systems to be used, as long as there is a module written for the target debugger to interpret the information. In addition, debug global variables are declared in the "llvm.metadata" section. All values declared in this section are stripped away after target debug information is constructed and before the program object is emitted.
To provide basic functionality, the LLVM debugger does have to make some assumptions about the source-level language being debugged, though it keeps these to a minimum. The only common features that the LLVM debugger assumes exist are source files, and program objects. These abstract objects are used by a debugger to form stack traces, show information about local variables, etc.
This section of the documentation first describes the representation aspects common to any source-language. The next section describes the data layout conventions used by the C and C++ front-ends.
In consideration of the complexity and volume of debug information, LLVM provides a specification for well formed debug global variables. The constant value of each of these globals is one of a limited set of structures, known as debug descriptors.
Consumers of LLVM debug information expect the descriptors for program objects to start in a canonical format, but the descriptors can include additional information appended at the end that is source-language specific. All LLVM debugging information is versioned, allowing backwards compatibility in the case that the core structures need to change in some way. Also, all debugging information objects start with a tag to indicate what type of object it is. The source-language is allowed to define its own objects, by using unreserved tag numbers. We recommend using with tags in the range 0x1000 thru 0x2000 (there is a defined enum DW_TAG_user_base = 0x1000.)
The fields of debug descriptors used internally by LLVM (MachineModuleInfo) are restricted to only the simple data types int, uint, bool, float, double, i8* and { }* . References to arbitrary values are handled using a { }* and a cast to { }* expression; typically references to other field descriptors, arrays of descriptors or global variables.
%llvm.dbg.object.type = type { uint, ;; A tag ... }
The details of the various descriptors follow.
%llvm.dbg.anchor.type = type { uint, ;; Tag = 0 + LLVMDebugVersion uint ;; Tag of descriptors grouped by the anchor }
One important aspect of the LLVM debug representation is that it allows the LLVM debugger to efficiently index all of the global objects without having the scan the program. To do this, all of the global objects use "anchor" descriptors with designated names. All of the global objects of a particular type (e.g., compile units) contain a pointer to the anchor. This pointer allows a debugger to use def-use chains to find all global objects of that type.
The following names are recognized as anchors by LLVM:
%llvm.dbg.compile_units = linkonce constant %llvm.dbg.anchor.type { uint 0, uint 17 } ;; DW_TAG_compile_unit %llvm.dbg.global_variables = linkonce constant %llvm.dbg.anchor.type { uint 0, uint 52 } ;; DW_TAG_variable %llvm.dbg.subprograms = linkonce constant %llvm.dbg.anchor.type { uint 0, uint 46 } ;; DW_TAG_subprogram
Using anchors in this way (where the compile unit descriptor points to the anchors, as opposed to having a list of compile unit descriptors) allows for the standard dead global elimination and merging passes to automatically remove unused debugging information. If the globals were kept track of through lists, there would always be an object pointing to the descriptors, thus would never be deleted.
%llvm.dbg.compile_unit.type = type { uint, ;; Tag = 17 + LLVMDebugVersion (DW_TAG_compile_unit) { }*, ;; Compile unit anchor = cast = (%llvm.dbg.anchor.type* %llvm.dbg.compile_units to { }*) uint, ;; Dwarf language identifier (ex. DW_LANG_C89) i8*, ;; Source file name i8*, ;; Source file directory (includes trailing slash) i8* ;; Producer (ex. "4.0.1 LLVM (LLVM research group)") bool ;; True if this is a main compile unit. }
These descriptors contain a source language ID for the file (we use the Dwarf 3.0 ID numbers, such as DW_LANG_C89, DW_LANG_C_plus_plus, DW_LANG_Cobol74, etc), three strings describing the filename, working directory of the compiler, and an identifier string for the compiler that produced it.
Compile unit descriptors provide the root context for objects declared in a specific source file. Global variables and top level functions would be defined using this context. Compile unit descriptors also provide context for source line correspondence.
Each input file is encoded as a separate compile unit in LLVM debugging information output. However, many target specific tool chains prefer to encode only one compile unit in an object file. In this situation, the LLVM code generator will include debugging information entities in the compile unit that is marked as main compile unit. The code generator accepts maximum one main compile unit per module. If a module does not contain any main compile unit then the code generator will emit multiple compile units in the output object file.
%llvm.dbg.global_variable.type = type { uint, ;; Tag = 52 + LLVMDebugVersion (DW_TAG_variable) { }*, ;; Global variable anchor = cast (%llvm.dbg.anchor.type* %llvm.dbg.global_variables to { }*), { }*, ;; Reference to context descriptor i8*, ;; Name i8*, ;; Display name (fully qualified C++ name) i8*, ;; MIPS linkage name (for C++) { }*, ;; Reference to compile unit where defined uint, ;; Line number where defined { }*, ;; Reference to type descriptor bool, ;; True if the global is local to compile unit (static) bool, ;; True if the global is defined in the compile unit (not extern) { }* ;; Reference to the global variable }
These descriptors provide debug information about globals variables. The provide details such as name, type and where the variable is defined.
%llvm.dbg.subprogram.type = type { uint, ;; Tag = 46 + LLVMDebugVersion (DW_TAG_subprogram) { }*, ;; Subprogram anchor = cast (%llvm.dbg.anchor.type* %llvm.dbg.subprograms to { }*), { }*, ;; Reference to context descriptor i8*, ;; Name i8*, ;; Display name (fully qualified C++ name) i8*, ;; MIPS linkage name (for C++) { }*, ;; Reference to compile unit where defined uint, ;; Line number where defined { }*, ;; Reference to type descriptor bool, ;; True if the global is local to compile unit (static) bool ;; True if the global is defined in the compile unit (not extern) }
These descriptors provide debug information about functions, methods and subprograms. They provide details such as name, return types and the source location where the subprogram is defined.
%llvm.dbg.block = type { i32, ;; Tag = 13 + LLVMDebugVersion (DW_TAG_lexical_block) { }* ;; Reference to context descriptor }
These descriptors provide debug information about nested blocks within a subprogram. The array of member descriptors is used to define local variables and deeper nested blocks.
%llvm.dbg.basictype.type = type { uint, ;; Tag = 36 + LLVMDebugVersion (DW_TAG_base_type) { }*, ;; Reference to context (typically a compile unit) i8*, ;; Name (may be "" for anonymous types) { }*, ;; Reference to compile unit where defined (may be NULL) uint, ;; Line number where defined (may be 0) i64, ;; Size in bits i64, ;; Alignment in bits uint, ;; Offset in bits uint ;; Dwarf type encoding }
These descriptors define primitive types used in the code. Example int, bool and float. The context provides the scope of the type, which is usually the top level. Since basic types are not usually user defined the compile unit and line number can be left as NULL and 0. The size, alignment and offset are expressed in bits and can be 64 bit values. The alignment is used to round the offset when embedded in a composite type (example to keep float doubles on 64 bit boundaries.) The offset is the bit offset if embedded in a composite type.
The type encoding provides the details of the type. The values are typically one of the following:
DW_ATE_address = 1 DW_ATE_boolean = 2 DW_ATE_float = 4 DW_ATE_signed = 5 DW_ATE_signed_char = 6 DW_ATE_unsigned = 7 DW_ATE_unsigned_char = 8
%llvm.dbg.derivedtype.type = type { uint, ;; Tag (see below) { }*, ;; Reference to context i8*, ;; Name (may be "" for anonymous types) { }*, ;; Reference to compile unit where defined (may be NULL) uint, ;; Line number where defined (may be 0) uint, ;; Size in bits uint, ;; Alignment in bits uint, ;; Offset in bits { }* ;; Reference to type derived from }
These descriptors are used to define types derived from other types. The value of the tag varies depending on the meaning. The following are possible tag values:
DW_TAG_formal_parameter = 5 DW_TAG_member = 13 DW_TAG_pointer_type = 15 DW_TAG_reference_type = 16 DW_TAG_typedef = 22 DW_TAG_const_type = 38 DW_TAG_volatile_type = 53 DW_TAG_restrict_type = 55
DW_TAG_member is used to define a member of a composite type or subprogram. The type of the member is the derived type. DW_TAG_formal_parameter is used to define a member which is a formal argument of a subprogram.
DW_TAG_typedef is used to provide a name for the derived type.
DW_TAG_pointer_type, DW_TAG_reference_type, DW_TAG_const_type, DW_TAG_volatile_type and DW_TAG_restrict_type are used to qualify the derived type.
Derived type location can be determined from the compile unit and line number. The size, alignment and offset are expressed in bits and can be 64 bit values. The alignment is used to round the offset when embedded in a composite type (example to keep float doubles on 64 bit boundaries.) The offset is the bit offset if embedded in a composite type.
Note that the void * type is expressed as a llvm.dbg.derivedtype.type with tag of DW_TAG_pointer_type and NULL derived type.
%llvm.dbg.compositetype.type = type { uint, ;; Tag (see below) { }*, ;; Reference to context i8*, ;; Name (may be "" for anonymous types) { }*, ;; Reference to compile unit where defined (may be NULL) uint, ;; Line number where defined (may be 0) uint, ;; Size in bits uint, ;; Alignment in bits uint, ;; Offset in bits { }* ;; Reference to array of member descriptors }
These descriptors are used to define types that are composed of 0 or more elements. The value of the tag varies depending on the meaning. The following are possible tag values:
DW_TAG_array_type = 1 DW_TAG_enumeration_type = 4 DW_TAG_structure_type = 19 DW_TAG_union_type = 23 DW_TAG_vector_type = 259 DW_TAG_subroutine_type = 46 DW_TAG_inheritance = 26
The vector flag indicates that an array type is a native packed vector.
The members of array types (tag = DW_TAG_array_type) or vector types (tag = DW_TAG_vector_type) are subrange descriptors, each representing the range of subscripts at that level of indexing.
The members of enumeration types (tag = DW_TAG_enumeration_type) are enumerator descriptors, each representing the definition of enumeration value for the set.
The members of structure (tag = DW_TAG_structure_type) or union (tag = DW_TAG_union_type) types are any one of the basic, derived or composite type descriptors, each representing a field member of the structure or union.
For C++ classes (tag = DW_TAG_structure_type), member descriptors provide information about base classes, static members and member functions. If a member is a derived type descriptor and has a tag of DW_TAG_inheritance, then the type represents a base class. If the member of is a global variable descriptor then it represents a static member. And, if the member is a subprogram descriptor then it represents a member function. For static members and member functions, getName() returns the members link or the C++ mangled name. getDisplayName() the simplied version of the name.
The first member of subroutine (tag = DW_TAG_subroutine_type) type elements is the return type for the subroutine. The remaining elements are the formal arguments to the subroutine.
Composite type location can be determined from the compile unit and line number. The size, alignment and offset are expressed in bits and can be 64 bit values. The alignment is used to round the offset when embedded in a composite type (as an example, to keep float doubles on 64 bit boundaries.) The offset is the bit offset if embedded in a composite type.
%llvm.dbg.subrange.type = type { uint, ;; Tag = 33 + LLVMDebugVersion (DW_TAG_subrange_type) uint, ;; Low value uint ;; High value }
These descriptors are used to define ranges of array subscripts for an array composite type. The low value defines the lower bounds typically zero for C/C++. The high value is the upper bounds. Values are 64 bit. High - low + 1 is the size of the array. If low == high the array will be unbounded.
%llvm.dbg.enumerator.type = type { uint, ;; Tag = 40 + LLVMDebugVersion (DW_TAG_enumerator) i8*, ;; Name uint ;; Value }
These descriptors are used to define members of an enumeration composite type, it associates the name to the value.
%llvm.dbg.variable.type = type { uint, ;; Tag (see below) { }*, ;; Context i8*, ;; Name { }*, ;; Reference to compile unit where defined uint, ;; Line number where defined { }* ;; Type descriptor }
These descriptors are used to define variables local to a sub program. The value of the tag depends on the usage of the variable:
DW_TAG_auto_variable = 256 DW_TAG_arg_variable = 257 DW_TAG_return_variable = 258
An auto variable is any variable declared in the body of the function. An argument variable is any variable that appears as a formal argument to the function. A return variable is used to track the result of a function and has no source correspondent.
The context is either the subprogram or block where the variable is defined. Name the source variable name. Compile unit and line indicate where the variable was defined. Type descriptor defines the declared type of the variable.
LLVM uses several intrinsic functions (name prefixed with "llvm.dbg") to provide debug information at various points in generated code.
void %llvm.dbg.stoppoint( uint, uint, { }* )
This intrinsic is used to provide correspondence between the source file and the generated code. The first argument is the line number (base 1), second argument is the column number (0 if unknown) and the third argument the source %llvm.dbg.compile_unit* cast to a { }*. Code following a call to this intrinsic will have been defined in close proximity of the line, column and file. This information holds until the next call to %lvm.dbg.stoppoint.
void %llvm.dbg.func.start( { }* )
This intrinsic is used to link the debug information in %llvm.dbg.subprogram to the function. It defines the beginning of the function's declarative region (scope). It also implies a call to %llvm.dbg.stoppoint which defines a source line "stop point". The intrinsic should be called early in the function after the all the alloca instructions. It should be paired off with a closing %llvm.dbg.region.end. The function's single argument is the %llvm.dbg.subprogram.type.
void %llvm.dbg.region.start( { }* )
This intrinsic is used to define the beginning of a declarative scope (ex. block) for local language elements. It should be paired off with a closing %llvm.dbg.region.end. The function's single argument is the %llvm.dbg.block which is starting.
void %llvm.dbg.region.end( { }* )
This intrinsic is used to define the end of a declarative scope (ex. block) for local language elements. It should be paired off with an opening %llvm.dbg.region.start or %llvm.dbg.func.start. The function's single argument is either the %llvm.dbg.block or the %llvm.dbg.subprogram.type which is ending.
void %llvm.dbg.declare( { } *, { }* )
This intrinsic provides information about a local element (ex. variable.) The first argument is the alloca for the variable, cast to a { }*. The second argument is the %llvm.dbg.variable containing the description of the variable, also cast to a { }*.
LLVM debugger "stop points" are a key part of the debugging representation that allows the LLVM to maintain simple semantics for debugging optimized code. The basic idea is that the front-end inserts calls to the %llvm.dbg.stoppoint intrinsic function at every point in the program where a debugger should be able to inspect the program (these correspond to places a debugger stops when you "step" through it). The front-end can choose to place these as fine-grained as it would like (for example, before every subexpression evaluated), but it is recommended to only put them after every source statement that includes executable code.
Using calls to this intrinsic function to demark legal points for the debugger to inspect the program automatically disables any optimizations that could potentially confuse debugging information. To non-debug-information-aware transformations, these calls simply look like calls to an external function, which they must assume to do anything (including reading or writing to any part of reachable memory). On the other hand, it does not impact many optimizations, such as code motion of non-trapping instructions, nor does it impact optimization of subexpressions, code duplication transformations, or basic-block reordering transformations.
In many languages, the local variables in functions can have their lifetime or scope limited to a subset of a function. In the C family of languages, for example, variables are only live (readable and writable) within the source block that they are defined in. In functional languages, values are only readable after they have been defined. Though this is a very obvious concept, it is also non-trivial to model in LLVM, because it has no notion of scoping in this sense, and does not want to be tied to a language's scoping rules.
In order to handle this, the LLVM debug format uses the notion of "regions" of a function, delineated by calls to intrinsic functions. These intrinsic functions define new regions of the program and indicate when the region lifetime expires. Consider the following C fragment, for example:
1. void foo() { 2. int X = ...; 3. int Y = ...; 4. { 5. int Z = ...; 6. ... 7. } 8. ... 9. }
Compiled to LLVM, this function would be represented like this:
void %foo() { entry: %X = alloca int %Y = alloca int %Z = alloca int ... call void %llvm.dbg.func.start( %llvm.dbg.subprogram.type* %llvm.dbg.subprogram ) call void %llvm.dbg.stoppoint( uint 2, uint 2, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit ) call void %llvm.dbg.declare({}* %X, ...) call void %llvm.dbg.declare({}* %Y, ...) ;; Evaluate expression on line 2, assigning to X. call void %llvm.dbg.stoppoint( uint 3, uint 2, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit ) ;; Evaluate expression on line 3, assigning to Y. call void %llvm.region.start() call void %llvm.dbg.stoppoint( uint 5, uint 4, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit ) call void %llvm.dbg.declare({}* %X, ...) ;; Evaluate expression on line 5, assigning to Z. call void %llvm.dbg.stoppoint( uint 7, uint 2, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit ) call void %llvm.region.end() call void %llvm.dbg.stoppoint( uint 9, uint 2, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit ) call void %llvm.region.end() ret void }
This example illustrates a few important details about the LLVM debugging information. In particular, it shows how the various intrinsics are applied together to allow a debugger to analyze the relationship between statements, variable definitions, and the code used to implement the function.
The first intrinsic %llvm.dbg.func.start provides a link with the subprogram descriptor containing the details of this function. This call also defines the beginning of the function region, bounded by the %llvm.region.end at the end of the function. This region is used to bracket the lifetime of variables declared within. For a function, this outer region defines a new stack frame whose lifetime ends when the region is ended.
It is possible to define inner regions for short term variables by using the %llvm.region.start and %llvm.region.end to bound a region. The inner region in this example would be for the block containing the declaration of Z.
Using regions to represent the boundaries of source-level functions allow LLVM interprocedural optimizations to arbitrarily modify LLVM functions without having to worry about breaking mapping information between the LLVM code and the and source-level program. In particular, the inliner requires no modification to support inlining with debugging information: there is no explicit correlation drawn between LLVM functions and their source-level counterparts (note however, that if the inliner inlines all instances of a non-strong-linkage function into its caller that it will not be possible for the user to manually invoke the inlined function from a debugger).
Once the function has been defined, the stopping point corresponding to line #2 (column #2) of the function is encountered. At this point in the function, no local variables are live. As lines 2 and 3 of the example are executed, their variable definitions are introduced into the program using %llvm.dbg.declare, without the need to specify a new region. These variables do not require new regions to be introduced because they go out of scope at the same point in the program: line 9.
In contrast, the Z variable goes out of scope at a different time, on line 7. For this reason, it is defined within the inner region, which kills the availability of Z before the code for line 8 is executed. In this way, regions can support arbitrary source-language scoping rules, as long as they can only be nested (ie, one scope cannot partially overlap with a part of another scope).
It is worth noting that this scoping mechanism is used to control scoping of all declarations, not just variable declarations. For example, the scope of a C++ using declaration is controlled with this and could change how name lookup is performed.
The C and C++ front-ends represent information about the program in a format that is effectively identical to Dwarf 3.0 in terms of information content. This allows code generators to trivially support native debuggers by generating standard dwarf information, and contains enough information for non-dwarf targets to translate it as needed.
This section describes the forms used to represent C and C++ programs. Other languages could pattern themselves after this (which itself is tuned to representing programs in the same way that Dwarf 3 does), or they could choose to provide completely different forms if they don't fit into the Dwarf model. As support for debugging information gets added to the various LLVM source-language front-ends, the information used should be documented here.
The following sections provide examples of various C/C++ constructs and the debug information that would best describe those constructs.
Given the source files "MySource.cpp" and "MyHeader.h" located in the directory "/Users/mine/sources", the following code:
#include "MyHeader.h" int main(int argc, char *argv[]) { return 0; }
a C/C++ front-end would generate the following descriptors:
... ;; ;; Define types used. In this case we need one for compile unit anchors and one ;; for compile units. ;; %llvm.dbg.anchor.type = type { uint, uint } %llvm.dbg.compile_unit.type = type { uint, { }*, uint, uint, i8*, i8*, i8* } ... ;; ;; Define the anchor for compile units. Note that the second field of the ;; anchor is 17, which is the same as the tag for compile units ;; (17 = DW_TAG_compile_unit.) ;; %llvm.dbg.compile_units = linkonce constant %llvm.dbg.anchor.type { uint 0, uint 17 }, section "llvm.metadata" ;; ;; Define the compile unit for the source file "/Users/mine/sources/MySource.cpp". ;; %llvm.dbg.compile_unit1 = internal constant %llvm.dbg.compile_unit.type { uint add(uint 17, uint 262144), { }* cast (%llvm.dbg.anchor.type* %llvm.dbg.compile_units to { }*), uint 1, uint 1, i8* getelementptr ([13 x i8]* %str1, i32 0, i32 0), i8* getelementptr ([21 x i8]* %str2, i32 0, i32 0), i8* getelementptr ([33 x i8]* %str3, i32 0, i32 0) }, section "llvm.metadata" ;; ;; Define the compile unit for the header file "/Users/mine/sources/MyHeader.h". ;; %llvm.dbg.compile_unit2 = internal constant %llvm.dbg.compile_unit.type { uint add(uint 17, uint 262144), { }* cast (%llvm.dbg.anchor.type* %llvm.dbg.compile_units to { }*), uint 1, uint 1, i8* getelementptr ([11 x i8]* %str4, int 0, int 0), i8* getelementptr ([21 x i8]* %str2, int 0, int 0), i8* getelementptr ([33 x i8]* %str3, int 0, int 0) }, section "llvm.metadata" ;; ;; Define each of the strings used in the compile units. ;; %str1 = internal constant [13 x i8] c"MySource.cpp\00", section "llvm.metadata"; %str2 = internal constant [21 x i8] c"/Users/mine/sources/\00", section "llvm.metadata"; %str3 = internal constant [33 x i8] c"4.0.1 LLVM (LLVM research group)\00", section "llvm.metadata"; %str4 = internal constant [11 x i8] c"MyHeader.h\00", section "llvm.metadata"; ...
Given an integer global variable declared as follows:
int MyGlobal = 100;
a C/C++ front-end would generate the following descriptors:
;; ;; Define types used. One for global variable anchors, one for the global ;; variable descriptor, one for the global's basic type and one for the global's ;; compile unit. ;; %llvm.dbg.anchor.type = type { uint, uint } %llvm.dbg.global_variable.type = type { uint, { }*, { }*, i8*, { }*, uint, { }*, bool, bool, { }*, uint } %llvm.dbg.basictype.type = type { uint, { }*, i8*, { }*, int, uint, uint, uint, uint } %llvm.dbg.compile_unit.type = ... ... ;; ;; Define the global itself. ;; %MyGlobal = global int 100 ... ;; ;; Define the anchor for global variables. Note that the second field of the ;; anchor is 52, which is the same as the tag for global variables ;; (52 = DW_TAG_variable.) ;; %llvm.dbg.global_variables = linkonce constant %llvm.dbg.anchor.type { uint 0, uint 52 }, section "llvm.metadata" ;; ;; Define the global variable descriptor. Note the reference to the global ;; variable anchor and the global variable itself. ;; %llvm.dbg.global_variable = internal constant %llvm.dbg.global_variable.type { uint add(uint 52, uint 262144), { }* cast (%llvm.dbg.anchor.type* %llvm.dbg.global_variables to { }*), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([9 x i8]* %str1, int 0, int 0), i8* getelementptr ([1 x i8]* %str2, int 0, int 0), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), uint 1, { }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype to { }*), bool false, bool true, { }* cast (int* %MyGlobal to { }*) }, section "llvm.metadata" ;; ;; Define the basic type of 32 bit signed integer. Note that since int is an ;; intrinsic type the source file is NULL and line 0. ;; %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([4 x i8]* %str3, int 0, int 0), { }* null, int 0, uint 32, uint 32, uint 0, uint 5 }, section "llvm.metadata" ;; ;; Define the names of the global variable and basic type. ;; %str1 = internal constant [9 x i8] c"MyGlobal\00", section "llvm.metadata" %str2 = internal constant [1 x i8] c"\00", section "llvm.metadata" %str3 = internal constant [4 x i8] c"int\00", section "llvm.metadata"
Given a function declared as follows:
int main(int argc, char *argv[]) { return 0; }
a C/C++ front-end would generate the following descriptors:
;; ;; Define types used. One for subprogram anchors, one for the subprogram ;; descriptor, one for the global's basic type and one for the subprogram's ;; compile unit. ;; %llvm.dbg.subprogram.type = type { uint, { }*, { }*, i8*, { }*, bool, bool } %llvm.dbg.anchor.type = type { uint, uint } %llvm.dbg.compile_unit.type = ... ;; ;; Define the anchor for subprograms. Note that the second field of the ;; anchor is 46, which is the same as the tag for subprograms ;; (46 = DW_TAG_subprogram.) ;; %llvm.dbg.subprograms = linkonce constant %llvm.dbg.anchor.type { uint 0, uint 46 }, section "llvm.metadata" ;; ;; Define the descriptor for the subprogram. TODO - more details. ;; %llvm.dbg.subprogram = internal constant %llvm.dbg.subprogram.type { uint add(uint 46, uint 262144), { }* cast (%llvm.dbg.anchor.type* %llvm.dbg.subprograms to { }*), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([5 x i8]* %str1, int 0, int 0), i8* getelementptr ([1 x i8]* %str2, int 0, int 0), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), uint 1, { }* null, bool false, bool true }, section "llvm.metadata" ;; ;; Define the name of the subprogram. ;; %str1 = internal constant [5 x i8] c"main\00", section "llvm.metadata" %str2 = internal constant [1 x i8] c"\00", section "llvm.metadata" ;; ;; Define the subprogram itself. ;; int %main(int %argc, i8** %argv) { ... }
The following are the basic type descriptors for C/C++ core types:
%llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([5 x i8]* %str1, int 0, int 0), { }* null, int 0, uint 32, uint 32, uint 0, uint 2 }, section "llvm.metadata" %str1 = internal constant [5 x i8] c"bool\00", section "llvm.metadata"
%llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([5 x i8]* %str1, int 0, int 0), { }* null, int 0, uint 8, uint 8, uint 0, uint 6 }, section "llvm.metadata" %str1 = internal constant [5 x i8] c"char\00", section "llvm.metadata"
%llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([14 x i8]* %str1, int 0, int 0), { }* null, int 0, uint 8, uint 8, uint 0, uint 8 }, section "llvm.metadata" %str1 = internal constant [14 x i8] c"unsigned char\00", section "llvm.metadata"
%llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([10 x i8]* %str1, int 0, int 0), { }* null, int 0, uint 16, uint 16, uint 0, uint 5 }, section "llvm.metadata" %str1 = internal constant [10 x i8] c"short int\00", section "llvm.metadata"
%llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([19 x i8]* %str1, int 0, int 0), { }* null, int 0, uint 16, uint 16, uint 0, uint 7 }, section "llvm.metadata" %str1 = internal constant [19 x i8] c"short unsigned int\00", section "llvm.metadata"
%llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([4 x i8]* %str1, int 0, int 0), { }* null, int 0, uint 32, uint 32, uint 0, uint 5 }, section "llvm.metadata" %str1 = internal constant [4 x i8] c"int\00", section "llvm.metadata"
%llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([13 x i8]* %str1, int 0, int 0), { }* null, int 0, uint 32, uint 32, uint 0, uint 7 }, section "llvm.metadata" %str1 = internal constant [13 x i8] c"unsigned int\00", section "llvm.metadata"
%llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([14 x i8]* %str1, int 0, int 0), { }* null, int 0, uint 64, uint 64, uint 0, uint 5 }, section "llvm.metadata" %str1 = internal constant [14 x i8] c"long long int\00", section "llvm.metadata"
%llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([23 x i8]* %str1, int 0, int 0), { }* null, int 0, uint 64, uint 64, uint 0, uint 7 }, section "llvm.metadata" %str1 = internal constant [23 x 8] c"long long unsigned int\00", section "llvm.metadata"
%llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([6 x i8]* %str1, int 0, int 0), { }* null, int 0, uint 32, uint 32, uint 0, uint 4 }, section "llvm.metadata" %str1 = internal constant [6 x i8] c"float\00", section "llvm.metadata"
%llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), 8* getelementptr ([7 x 8]* %str1, int 0, int 0), { }* null, int 0, uint 64, uint 64, uint 0, uint 4 }, section "llvm.metadata" %str1 = internal constant [7 x 8] c"double\00", section "llvm.metadata"
Given the following as an example of C/C++ derived type:
typedef const int *IntPtr;
a C/C++ front-end would generate the following descriptors:
;; ;; Define the typedef "IntPtr". ;; %llvm.dbg.derivedtype1 = internal constant %llvm.dbg.derivedtype.type { uint add(uint 22, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([7 x 8]* %str1, int 0, int 0), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), int 1, uint 0, uint 0, uint 0, { }* cast (%llvm.dbg.derivedtype.type* %llvm.dbg.derivedtype2 to { }*) }, section "llvm.metadata" %str1 = internal constant [7 x 8] c"IntPtr\00", section "llvm.metadata" ;; ;; Define the pointer type. ;; %llvm.dbg.derivedtype2 = internal constant %llvm.dbg.derivedtype.type { uint add(uint 15, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* null, { }* null, int 0, uint 32, uint 32, uint 0, { }* cast (%llvm.dbg.derivedtype.type* %llvm.dbg.derivedtype3 to { }*) }, section "llvm.metadata" ;; ;; Define the const type. ;; %llvm.dbg.derivedtype3 = internal constant %llvm.dbg.derivedtype.type { uint add(uint 38, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* null, { }* null, int 0, uint 0, uint 0, uint 0, { }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype1 to { }*) }, section "llvm.metadata" ;; ;; Define the int type. ;; %llvm.dbg.basictype1 = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), 8* getelementptr ([4 x 8]* %str2, int 0, int 0), { }* null, int 0, uint 32, uint 32, uint 0, uint 5 }, section "llvm.metadata" %str2 = internal constant [4 x 8] c"int\00", section "llvm.metadata"
Given the following as an example of C/C++ struct type:
struct Color { unsigned Red; unsigned Green; unsigned Blue; };
a C/C++ front-end would generate the following descriptors:
;; ;; Define basic type for unsigned int. ;; %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type { uint add(uint 36, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([13 x i8]* %str1, int 0, int 0), { }* null, int 0, uint 32, uint 32, uint 0, uint 7 }, section "llvm.metadata" %str1 = internal constant [13 x i8] c"unsigned int\00", section "llvm.metadata" ;; ;; Define composite type for struct Color. ;; %llvm.dbg.compositetype = internal constant %llvm.dbg.compositetype.type { uint add(uint 19, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([6 x i8]* %str2, int 0, int 0), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), int 1, uint 96, uint 32, uint 0, { }* null, { }* cast ([3 x { }*]* %llvm.dbg.array to { }*) }, section "llvm.metadata" %str2 = internal constant [6 x i8] c"Color\00", section "llvm.metadata" ;; ;; Define the Red field. ;; %llvm.dbg.derivedtype1 = internal constant %llvm.dbg.derivedtype.type { uint add(uint 13, uint 262144), { }* null, i8* getelementptr ([4 x i8]* %str3, int 0, int 0), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), int 2, uint 32, uint 32, uint 0, { }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype to { }*) }, section "llvm.metadata" %str3 = internal constant [4 x i8] c"Red\00", section "llvm.metadata" ;; ;; Define the Green field. ;; %llvm.dbg.derivedtype2 = internal constant %llvm.dbg.derivedtype.type { uint add(uint 13, uint 262144), { }* null, i8* getelementptr ([6 x i8]* %str4, int 0, int 0), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), int 3, uint 32, uint 32, uint 32, { }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype to { }*) }, section "llvm.metadata" %str4 = internal constant [6 x i8] c"Green\00", section "llvm.metadata" ;; ;; Define the Blue field. ;; %llvm.dbg.derivedtype3 = internal constant %llvm.dbg.derivedtype.type { uint add(uint 13, uint 262144), { }* null, i8* getelementptr ([5 x i8]* %str5, int 0, int 0), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), int 4, uint 32, uint 32, uint 64, { }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype to { }*) }, section "llvm.metadata" %str5 = internal constant [5 x 8] c"Blue\00", section "llvm.metadata" ;; ;; Define the array of fields used by the composite type Color. ;; %llvm.dbg.array = internal constant [3 x { }*] [ { }* cast (%llvm.dbg.derivedtype.type* %llvm.dbg.derivedtype1 to { }*), { }* cast (%llvm.dbg.derivedtype.type* %llvm.dbg.derivedtype2 to { }*), { }* cast (%llvm.dbg.derivedtype.type* %llvm.dbg.derivedtype3 to { }*) ], section "llvm.metadata"
Given the following as an example of C/C++ enumeration type:
enum Trees { Spruce = 100, Oak = 200, Maple = 300 };
a C/C++ front-end would generate the following descriptors:
;; ;; Define composite type for enum Trees ;; %llvm.dbg.compositetype = internal constant %llvm.dbg.compositetype.type { uint add(uint 4, uint 262144), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), i8* getelementptr ([6 x i8]* %str1, int 0, int 0), { }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to { }*), int 1, uint 32, uint 32, uint 0, { }* null, { }* cast ([3 x { }*]* %llvm.dbg.array to { }*) }, section "llvm.metadata" %str1 = internal constant [6 x i8] c"Trees\00", section "llvm.metadata" ;; ;; Define Spruce enumerator. ;; %llvm.dbg.enumerator1 = internal constant %llvm.dbg.enumerator.type { uint add(uint 40, uint 262144), i8* getelementptr ([7 x i8]* %str2, int 0, int 0), int 100 }, section "llvm.metadata" %str2 = internal constant [7 x i8] c"Spruce\00", section "llvm.metadata" ;; ;; Define Oak enumerator. ;; %llvm.dbg.enumerator2 = internal constant %llvm.dbg.enumerator.type { uint add(uint 40, uint 262144), i8* getelementptr ([4 x i8]* %str3, int 0, int 0), int 200 }, section "llvm.metadata" %str3 = internal constant [4 x i8] c"Oak\00", section "llvm.metadata" ;; ;; Define Maple enumerator. ;; %llvm.dbg.enumerator3 = internal constant %llvm.dbg.enumerator.type { uint add(uint 40, uint 262144), i8* getelementptr ([6 x i8]* %str4, int 0, int 0), int 300 }, section "llvm.metadata" %str4 = internal constant [6 x i8] c"Maple\00", section "llvm.metadata" ;; ;; Define the array of enumerators used by composite type Trees. ;; %llvm.dbg.array = internal constant [3 x { }*] [ { }* cast (%llvm.dbg.enumerator.type* %llvm.dbg.enumerator1 to { }*), { }* cast (%llvm.dbg.enumerator.type* %llvm.dbg.enumerator2 to { }*), { }* cast (%llvm.dbg.enumerator.type* %llvm.dbg.enumerator3 to { }*) ], section "llvm.metadata"


--- layout: post title: Speed up Capybara Tests with Devise date: '2012-01-16T10:44:00-06:00' tags: - ruby - ruby on rails - capybara - devise - acceptance testing permalink: /post/15948562424/speed-up-capybara-tests-with-devise ---
All good developers should write tests, and anyone with a high stake in a web app should write acceptance tests. Acceptance tests use a web driver like Capybara to test the full functionality of your web app by interacting directly with view elements the same way a user would (clicking links, filling out forms, etc.)
My only problem with acceptance tests is that they can be a bit slow, so i’m always looking for ways to speed mine up. One of my pain points is since everything is done via manual interaction with a headless website, any test requiring a logged in user (most of them) also requires that before it is run, Capybara must log the user in by visiting the sign in path and entering valid credentials. While I still think manual sign in should be tested, it doesn’t need to be tested every single time we run another test.
If you’re doing authentication with Devise to speed things up a bit we can stub out a logged in user with Warden’s built in test helpers.
It works like this when you’re running a non-acceptance test we want to use Devise’s sign_in
helper since we have direct access to the request
object (not available during capybara/acceptance tests). All other times we want to use Warden’s login_as
method.
Here is an example of as_user
and as_visitor
helpers that do just that:
include Devise::TestHelpers
# gives us the login_as(@user) method when request object is not present
include Warden::Test::Helpers
Warden.test_mode!
# Will run the given code as the user passed in
def as_user(user=nil, &block)
current_user = user || Factory.create(:user)
if request.present?
sign_in(current_user)
else
login_as(current_user, :scope => :user)
end
block.call if block.present?
return self
end
def as_visitor(user=nil, &block)
current_user = user || Factory.stub(:user)
if request.present?
sign_out(current_user)
else
logout(:user)
end
block.call if block.present?
return self
end
I then needed to call Warden.test_reset!
after each test to ensure correct functionality
RSpec.configure do |config|
config.after(:each) { Warden.test_reset! }
end
Then in my tests (shown here with capybara/rspec, I can simply log in a user like this:
let(:user) { Factory.create(:user) }
# To use the methods you can call
# methods directly on them like this:
scenario 'works while logged in' do
as_user(user).visit teach_path
# ...
# Or you can pass the code you wish
# to run in a block:
scenario 'creating a class' do
as_user(user) do
visit teach_path
click_link('Create')
current_path.should == new_course_path
fill_in 'course_title', :with => course_stub.title
fill_in 'course_teaser', :with => course_stub.teaser
fill_in 'course_experience', :with => course_stub.experience
click_button 'Submit'
# ...
It’s that simple. With a few lines of code I was able to speed up my tests and keep all expected behavior. For more details on how this works, you can go to the wiki page I created: https://github.com/plataformatec/devise/wiki/How-To:-Test-with-Capybara . Good luck and happy testing!


Regular hand wash for 30 seconds will help you avoid germs or any kind of infection. Use soap or hand sanitizer for better results and do this every time you travel or touch anything.Whenever you touch any surface wash your hands before eating anything.
Covering your mouth and nose while sneezing or when anyone next to coughs or sneezes can do you a lot better.
If you are suffering from a common cold, cough, nausea, vomiting, shortness of breath and fatigue make it a point to consult a doctor at the earliest. Any of these symptoms could be a sign that you are suffering from the virus.
Avoid being in crowded places. An infected person can spread the virus instantly and crowded places is a good way to accomplish this. Make sure you wear full sleeves shirts with anti-pollution masks when you travel. Staying indoors is a rather safe option.
Do not get close to anyone, especially touching or laughing closely. Also, use anti-pollution masks when out with friends or family. Avoid touching anyone and do not use the same utensils used by another. These simple non-touchy ways can do good until the outbreak comes to an end.


When applications using Berkeley DB receive signals, it is important that they exit gracefully, discarding any Berkeley DB locks that they may hold. This is normally done by setting a flag when a signal arrives, and then checking for that flag periodically within the application. As Berkeley DB is not reentrant, the signal handler should not attempt to release locks and/or close the database handles itself if there is any question at all that Berkeley DB can be reentered. Reentering Berkeley DB is not guaranteed to work correctly and the results are undefined.
If an application exits holding a lock, the situation is no different than if the application crashed, and all applications participating in the database environment must be shutdown, and then recovery must be performed. If this is not done, the locks that the application held can cause unresolvable deadlocks inside the database, and applications may then hang.


Guidance
A list of all apprenticeship standards available for employers and training organisations.
MS Excel Spreadsheet , 113KB
If you use assistive technology (such as a screen reader) and need a version of this document in a more accessible format, please email<EMAIL_ADDRESS>. Please tell us what format you need. It will help us if you say what assistive technology you use.
This document provides a list of all the apprenticeship standards that are currently being developed by groups of employers (trailblazers). It identifies their stage of development – including whether they are ready for delivery.
A standard is considered ready for delivery when it has an approved assessment plan and a funding cap assigned.
For more information and to access all the apprenticeship standards and assessment plan documents, please see the standards page .
Published: 5 October 2015
Updated: 20 January 2017
From: Skills Funding Agency
Part of: Apprenticeships


Try out our Premium Member services: Virtual Legal Assistant, Query Alert Service and an ad-free experience. Free for one month and pay only if you like it.
PETITIONER: MEMBER-SECRETARY, ANDHRA PRADESH STATEBOARD FOR PREVENTION A Vs. RESPONDENT: ANDHRA PRADESH RAYONS LTD. & ORS. DATE OF JUDGMENT30/09/1988 BENCH: MUKHARJI, SABYASACHI (J) BENCH: MUKHARJI, SABYASACHI (J) KANIA, M.H. RANGNATHAN, S. CITATION: 1989 AIR 611 1988 SCR Supl. (3) 380 1989 SCC (1) 44 JT 1988 (4) 154 1988 SCALE (2)1811 CITATOR INFO : R 1992 SC 224 (11,19) ACT: Water (Prevention and Control of Pollution) cess Act, 1977: Section 3 and Schedule I--Cess--Levy and collection of Industry manufacturing Rayon Grade pulp--Neither chemical, textile nor paper industry. % Statutory Interpretation: Taxing Statute--Interpretation of--No room for any intendment--No equity about tax--No presumption as to tax--Whether any industry falls within realm of taxation--To be judged by predominant purpose and process--Not by any ancillary or Incidental process carried on by the industry. HEADNOTE: The respondent, Andhra Pradesh Rayons Ltd., manufacturing Rayon Grade Pulp, a base material for the manufacture of synthetics or man-made fabrics, was assessed by the petitioner under the provisions of Water (Prevention and Control of Pollution) Cess Act, 1977 which provided for levy and collection of Water cess from the specified industries enumerated in Schedule I of the Act. On appeal, the Appellate late Committee confirmed the order of assessment on the ground that the respondent was manufacturing Rayon Grade Pulp which came under the category of Textile industry. The respondent filed a writ in the High Court challenging the levy Inter alia on the ground that it was not one of the industries mentioned in the Schedule. The High Court upheld this contention. Before this Court, it was sought to be canvessed by the petitioner that Rayon Grade Pulp was covered either by Item No. 7 of the Schedule, which was chemical industry, or item No. 10 which was textile industry, or item No.11 which was paper industry. Dismissing the petition, it was, PG NO 380 PG NO 381 HELD: (I) The Act being fiscal in nature must be strictly construed. The question as to what is covered must be found out from the language according to its natural meaning, fairly and squarely read. [385F; 386B] (2) In a taxing Act one has to look merely at what is clearly said. There is no room for any intendment. There is no equity about a tax, there is no presumption as to tax. Nothing is to be read in, nothing is to be implied. [385H] (3) Whether a particular industry is an industry covered in Schedule I has to be judged normally by what that industry produces mainly, its predominant purpose and process, and not by any ancillary or incidental process carried on by it. [386D] (4) Chemical process would be involved to a certain extent, more or less in all industries, but an industry would be known as a chemical industry if it carries out predominantly chemical activities and is involved in chemical endeavours. [386E] (5) Taxing consideration may stem from administrative experience and other factors of life and not artistic visualisation or neat logic and so the literal, though pedestrian, interpretation must prevail. [386C] (6) One of the well recognised canons of construction is that the legislature speaks its mind by use of correct expression and unless there is any ambiguity in the language of the provision the Court should accept literal construction if it does not lead to an absurdity. [387E] (7) There is no absurdity in the literal meaning. Broadly and literally it can be said that the Rayon Grade Pulp is neither chemical industry nor textile industry nor paper industry. [387G;386H] In Re Micklethwait., [1885] II EX 452. 456; Tenant v. Smith, [1892] AC 150; St. Aubyan v. AG., [1951] 2 All E.R. 473; Cape Brandy Syndicate v. IRC., [1921] 1 KB 64 at 71; Gursahai Saigal v. C.I.T. Punjab, [1963] 3 SCR 893; C.I.T. Madras v. MR. P. Firm, Muar, [1965] 1 SCR 815; Controller of Estate Duty, Gujarat v. Kantilal Trikamlal, [1977] 1 SCR 9; IRC v. Duke of Westminster, [1936] AC 1 at 24; AV Fernandez v. The State of Kerala, [1957] SCR 837; Martand Dairy & Farm v. Union of India, [1975] Supp. SCR 265; Lt Col. Prithi Pal Singh Bedi v. Union of India, [1983] 1 SCR 393, referred to. PG NO 382 M/s. Gwalior Rayon Silk Mfg. (Wvg.) Co. Ltd. Mavoor v. The Appellate Committee for Water Cess, Trivandrum, A.I.R. 1983 Kerala 110. overruled. JUDGMENT:
CIVIL APPELLATE JURISDICTION: Special Leave Petition (C) No. 8566 of 1988.
From the Judgment and Order dated 9.10.1987 of the Andhra Pradesh High Court in W.P. No. 306 of 1983. R. Mohan for the Petitioner.
The Judgment of the Court was delivered by SABYASACHI MUKHARJI, J. This petition is for leave to appeal under Article 136 of the Constitution from the judgment and order of the High Court of Andhra Pradesh dated 9th October, 1987. The question that was urged before the High Court and the question which is sought to be raised in this petition is whether the respondent Pradesh Rayons Ltd. which is manufacturing Rayon Grade Pulp, a base material for manufacturing of synthetics or manmade fabrics is an industry as mentioned in Schedule I of the Water (Prevention and Control of Pollution) cess Act, 1977 for the purposes of levy of Water Cess under the Act. The water (Prevention and Control Of Pollution) Act, 1974 was passed by the Parliament to "provide for the prevention and control of water pollution and the maintaining or restoring of wholesomeness of water, for the establishment, with a view to carrying out the purposes aforesaid, of Boards for the prevention and control of water pollution, for conferring on and assigning to such Boards powers and functions relating thereto and for matters connected therewith". For the aforesaid purposes, the Act contemplated creation of State Boards at State level and the Central Board at the national level. Thereafter, the Water (Prevention and Control of Pollution) Cess Act, 1977 being Act 36 of 1977 was passed (hereinafter called 'the Act'). The preamble to the said Act states that the said Act was "to provide for the levy and collection of a cess on water consumed by persons carrying on certain industries and by local authorities, with a view to augment the resources of the Central Board and the State PG NO 383 Boards for the prevention and control of water pollution constituted under the Water (Prevention and Control of Pollution) Act, 1974". Therefore, the said Act was passed only for the purpose of providing for levy and collection of cess on water consumed by persons carrying on certain industries with a view to augment the resources of the Central Board and the State Boards. Section 2(c) stipulates A `specified industry' means any industry specified in Schedule T. Section 3 provides as follows:
"3. Levy and collection of cess.--(1) There shall be levied and collected a cess for the purposes of the Water (Preven-tion and Control of Pollution) Act, 1974 and utilisation thereunder.
(2) The cess under sub-section ( I) shall be payable by-
(a) every person carrying on any specified industry; and
(b) every local authority, and shall be calculated on the basis of the water consumed by such person or local authority, as the case may be, for any of the purposes specified in column (1) of Schedule II, at such rate, not exceeding the rate specified in the corresponding entry in column (2) thereof, as the Central Government may, by notification in the Official Gazette, from time to time, specify."
Therefore, this section provides for levy and collection of cess from the specified industries. Specified industry is one which is mentioned in Schedule I which is as follows:
"1. Ferrous metallurgical industry.
2. Non-ferrous metallurgical industry.
3. Mining industry.
4. Ore processing industry.
5. Petroleum industry.
6. Petro-chemical industry.
7. Chemical industry.
8. Ceramic industry.
PG NO 384
9. Cement industry.
10. Textile industry
11. Paper industry.
12. Fertilizer industry.
13. Coal (including coke) industry.
14. Power (thermal and diesel) generating industry.
15. Processing of animal or vegetable products industry."
Therefore, the short question, is, whether the industry run by the respondent herein for manufacturing Rayon Grade Pulp, a base material for manufacture of synthetics or man- made fabrics is one of the industries mentioned in Schedule I hereinbefore.
In this case, the respondent company was registered as company in 1975. The supply of energy to the company commenced on August 22, 1981 and the production began from September 1, 1981. The company manufactures rayon grade pulp of 26250 tonnes per annum. The Company was served with a notice on 12th August, 1981 to furnish the quantum of water consumed for assessment under the Act. Based on the returns filed by the respondent as required under section S of the Act, assessment of water cess was made by an order dated 31st December 1981. Aggrieved by the said order the respondent filed an appeal before the Appellate Committee constituted under the Act. The Appellate committee by its order dated 30th November, 1982 conformed the orders of the assessment passed by the petitioner. Before the Appellate Committee various contentions were urged and only one of such contention survives now and is agitated before us, namely, that the Rayon Industry is nOt included in Schedule I of the said Act. The Appellate Committee by its order said as follows:
"We are unable to agree with the arguments advanced by the learned counsel. The appellant industry is manufacturing Rayon Grade Pulp which comes under the category of textile industry as it involves the production of Rayon Grade Pulp. a base material for manufacture of synthetic of man-made fibres.'' PG NO 385 From the aforesaid, it appears that the Appellate Committee was of the view that the respondent herein was manufacturing Rayon Grade Pulp which comes under the category of Textile mentioned in Schedule I of the Act. Textile industry is item No. 10 in the aforesaid Schedule. Aggrieved by the decision of the Appellate Committee, the respondent herein filed writ petition challenging the constitutional validity of the Act as well as the levy of cess on water on the ground that it was not one of the industries mentioned in the Schedule. The High Court by its order dated 9th October, 1987 rejected the contention relating to the constitutional validity but upheld the contention that the respondent's industry was not an industry which is mentioned in Schedule I and as such was not liable to pay cess. It is the propriety or the correctness of that decision which is sought to be canvassed before us by this petition. It must, therefore, be made clear that we are not concerned with the correctness or otherwise of the decision of the High Court about the constitutional validity of the Act in question. That is not at issue before us since the petitioner, Andhra Pradesh State Board for Prevention and Control of Water Pollution has not challenged that finding. The only question is whether the respondent is an industry as mentioned in the aforesaid schedule. The High Court in the impugned judgment has held that Rayon Grade Pulp is not covered by any of the items specified in the said Schedule. We are of the opinion that the High Court was right. Before us it was sought to be canvassed that Rayon Grade Pulp is covered either by Item No. 7 which is chemical industry or 13y item No. 10 which is textile industry or item No. I1 which is paper industry. We are unable to accept the contention.
It has to be borne in mind that this Act with which we are concerned is an Act imposing liability for cess. The Act is fiscal in nature. The Act must, therefore, be strictly construed in order to find out whether a liability is fastened on a particular industry. The subject is not to be taxed without clear words for that purpose; and also that every Act of Parliament must be read according to its natural construction of words. See the observations in Re Micklethwait, [1885] 11 EX 452, 456. Also see the observations in Tenant v. Smith, [1892] AC 150 and Lord Halsbury's observations at page 154. See also the observations of Lord Simonds in St. Aubyn v. AG, [1951] 2 All E.R. 473 at 485. Justice Rowlatt of England said a long time ago, that in a taxing ACt one has to look merely at what is clearly said. There is no room for any intendment. There is no equity about a tax. There is no presumption at to tax. Nothing is to be read in, nothing is to be implied. One has to look fairly at the language used. See the observations in Cape Brandy Syndicate v. IRC, [1921]J 1 KB PG NO 386 64 at 71. This Court has also reiterated the same view in Gursahai Saigal v. C.I.T. Punjab, [1963] 3 SCR 893; S.L. T. Madras v. V. MR. P. Firm, Muar, [1965] I SCR 815. and Controller of Estate Duty Gujarat v. Kantilal Trikamlal, [1977] 1 SCR 9.
The question as to what is covered must be found out from the language according to its natural meaning fairly and squarely read. See the observations in IRC v. Duke of Westminster, [1936] AC I at 24, and of this Court in A V Fernandez v. The State of Kerala, [1957] SCR 837. Justice Krishna Iyer of this Court in Martand Dairy & Farm v. Union of India, [1975] Suppl. SCR 265 has observed that taxing consideration may stem from administrative experience and other factors of life and not artistic visualisation or neat logic and so the literal, though pedestrian, interpretation must prevail.
In this case where the question is whether a particular industry is an industry as covered in Schedule I of the Act, it has to be judged normally by what that industry produces mainly. Every industry carries out multifarious activities to reach its goal through various multifarious methods. Whether a particular industry falls within the realm of taxation, must be judged by the predominant purpose and process and not by any ancillary or incidental process carried on by a particular industry in running its business. Chemical process would be involved to a certain extent, more or less in all industries, but an industry would be known as a chemical industry if it carries out predominantly chemical activities and is involved in chemical endeavours. We fail to see that Rayon Grade Pulp could be considered even remotely connected as such with chemical industry or textile industry or paper industry. In all preparations, there is certain chemical process but that does not make all industries chemical industries. The expression "chemical" means, according to Collins English Dictionary. any substance used in or resulting from a reaction involving changes to atoms or molecules or used in chemistry. The Concise Oxford Dictionary, 8th Edition page 170 defines "chemical'' as made by or relating to, chemistry. Broadly and literally, in our opinion, it can be said that the Rayon Grade Pulp is neither chemical industry nor textile industry nor paper industry. We find it difficult on a broad and literal construction to bring the industry of the respondent into any of these categories. In other words, to find out the intention of the legislation, if possible it should be PG NO 387 found out from the language used in case of doubt. The purpose of legislation should be sought for to clarify the ambiguity only, if any. The fairest and most rational method, says Blackstone, to interpret the will of the legislator is by exploring his intentions at the time when the law was made, by signs the most natural and probable. And these signs are either the words, the context, the subject matter, the effects and consequence, or the spirit and reason of the law. See Commentaries on the Laws of England by Blackstone (facsimile of 1st edition of 1765, University of Chicago Press, 1979 Vol. 1 p. 59.). The words are generally to be understood `in their usual and most known signification', although terms of art `must be taken according to the acceptation of the learning in each art, trade and science. If words happen still to be dubious, we may establish their meaning from the context, which includes the preamble to the statute and laws made by the same legislator on the same subject. Words are always to be understood as having regard to the subject matter of the legislation. See Cross Statutory Interpretation, 2nd Edition page 21.
This Court in Lt Col. Prithi Pal Singh Bedi etc. v. Union of India & Ors., [1983] I S.C.R. 393 at page 404 of the report reiterated that the dominant purpose in construing a statute is to ascertain the intention of the Parliament. One of the well recognised canons of construction is that the legislature speaks its mind by use of correct expression and unless there is any ambiguity in the language of the provision the Court should adopt literal construction if it does not lead to an absurdity. Therefore, the first question to be posed is whether there is any ambiguity in the language used. If there is none, it would mean the language used, speaks the mind of Parliament and there is no need to look somewhere else to discover the intention or meaning. If the literal construction leads to an absurdity, external aids to construction can be resorted to. To ascertain the literal meaning it is equally necessary first to ascertain the juxtaposition in which the rule is placed, the purpose for which it is enacted and the object which it is required to subserve and the authority by which the rule is framed.
Bearing the aforesaid principle in mind, we find that there is no absurdity in the literal meaning. The purpose of the Act is to realise money from those whose activities lead to pollution and who must bear the expenses of the maintenance and running of the State Board. It is a fiscal provision and must, therefore, not only be literally construed but also be strictly construed. Having regard to the literal expression used and bearing in mind the purpose for the legislation, we arrive at a result that certain PG NO 388 industries have to pay the expenses of the maintenance and functioning of the State Boards. Considering the principle broadly and from commonsense point of view, we find nothing to warrant the conclusion that Rayon Grade Pulp is included in either of the industries as canvassed on behalf of the petitioner here and as held by the High Court in the judgment under appeal.
In this case, we must also note that neither the water Pollution Board nor any authorities under the Act nor the High Court proceeded on any evidence how these expressions are used in the particular industry or understood in the trade generally. In other words, no principle of understanding in "common parlance" is involved in the instance case.
In that view of the matter, we are of the opinion that the contention sought for by the petitioner is of no substance.
Our attention, however, was drawn to the decision of a learned single Judge of the High Court of Kerala in M/s. Gwalior Rayon Silk Mfg. (Wvg.) Co. Ltd., Mavoor v. The Appellate Committee for Water Cess, Trivandrum and others, A.I.R. 1983 Kerala 110. There, the learned single Judge of the Kerala High Court held that industry manufacturing rayon-grade pulp is chemical industry. The High Court has observed that the product of the Pulp Division of a rayon silk manufacturing company is rayon-grade pulp, extracted from bamboo or wood. The High Court noted that the pulp produced in the Pulp Division of the company is the raw material for the Staple Fibre Division. The High Court further observed that the pulp in question is a chemical used as chemical raw material, in the form known as chemical cellulose, for preparation of fibres. The High Court noted that for the scientist cellulose is a carbohydrate an organic compound, a saccharide and for the layman also it is a chemical like salt and sugar. Manufacture of pulp from wood or bamboo involves consumption of large quantities of water which get polluted in the process; and "chemical industry'' in the context in which it is used in Schedule I of the Act, can therefore, include an industry manufacturing rayon-grade pulp. We are unable, with respect, to accept the circuitous process of reasoning of the Kerala High Court. As mentioned hereinbefore, looked at from this circuitous method every industry would be chemical industry. It could not have been the intention to include all industries because every industry has to go to certain chemical process more or less and, therefore, it could not be so construed. Such expression should, therefore, be construed reasonably, strictly and from a commonsense point of view. The High PG NO 389 Court of Kerala has set out in the said judgment the company's case in that case which also produced Rayon Grade Pulp and the manufacturing process consisted only of isolating cellulose present in bamboo and wood by removal of "lignin" and other contents, and that the resultant product is not chemical cellulose. It explained the process as under:
"The actual process of manufacture of Rayon grade pulp is by feeding the raw materials on the conveyors leading to the chippers, where they are chipped into small pieces in uniform sizes. The raw materials are washed by a continuous stream of water before they are fed into chippers for removal of their adhering mud and dirt. The chips are then conveyed into Digesters, where they are subjected to acid pre-hydrolysis, using dilute sulphuric acid solution. The spent liquor is then drained out, and the chips washed to remove the acid. The chips are again cooked using a solution containing cooking chemicals at high temperature of above 160C. After the chips are thus cooked the pressure is released, and the material is collected in a blow tank, from where the chipped pulp is sent to "Knotter Screen" for removal of uncooked particles. The pulp is washed in a series of washers in a counter-current manner. The washed pulp is bleached in a multi-staged Bleaching Plant, and converted into sheets in a continuous machine. The pulp sheets so obtained are sent to other factories for their conversion into Staple Fibre."
The said High Court also relied on a passage from the "Book of Popular Science" Grolier, 1969, Vol. 7, p. 55 which reads as follows:
"Just what is a chemical, after all? Presumably it is a pure chemical substance (an element or compound) and not a mixture. Thus sulphuric acid is a chemical .. But common salt and sugar, with which all of us are familiar, are also pure chemical substances .... The truly chemical industries, which manufacture chemicals, are seldom well known to the public. This is because we, as consumers, do not ordinarily make use of chemicals in their pure form. Instead they are converted into products that reach the consumer only after a number of operations ...."
(Emphasis supplied) PG NO 390 As mentioned hereinbefore, the expression should be understood not in technical sense but from broad commonsense point of view to find out what it truly means by those who deal with them. Bearing the aforesaid perspective in mind, we are unable to agree with the view of the Kerala High Court expressed in the aforesaid judgment. In that conspectus of the Kerala High Court everything would be included in the process of chemical.
In the aforesaid view of the matter we are of the opinion that the High Court of Andhra Pradesh in the impugned judgment was right and the High Court of Kerala in the judgment referred to hereinbefore was not right. In the aforesaid view of the matter this petition fails and is accordingly dismissed.
R.S.S. Petition dismissed


The VAT system supports very different types of data: raster and vector data. Rasters consist of many pixels, and each pixel contains a value for the particular location, e.g. the mean temperature. Vector data are collections of features with attributes, e.g., a set of occurrences of pumas and the time of the observation.
In this section, you can select one of several data sources. Each data set is added to the map as a new layer, which you can further process with operators.
{{ button.description }}


example9_inheritance - funcyTags can inherit options from other funcy tags
To Notice: New FuncyTags can be built by inheriting from previously defined FuncyTags. As a simple example, if we have already created a <span> tag like this:
span=funcyTag('span',{_nobrout:true,_nobrin:true});
we can then create a <big> tag that inherits everything about span
but also sets the font size to be 150%:
big = funcyTag( span, {cssFontSize_pct:150} );
and a <bigred> tag could inherit from that to be a span that's both 150% bigger and colored red:
bigred = funcyTag( big, {cssColor:'red'} );
next: example10_esc top: all js examples


Squad Owner: {{vm.squad.squadOwner.name}}
Base Squad Cost: {{vm.squad.baseSquadCost | currency :$ :0}}
Loaded Squad Cost: {{vm.squad.loadedSquadCost | currency :$ :0}}
Total Opportunity Value: {{vm.squad.totalOpportunityValue | currency :$ :0}}


kpeaks: Determination of K Using Peak Counts of Features for Clustering
The input argument k which is the number of clusters is needed to start all of the partitioning clustering algorithms. In unsupervised learning applications, an optimal value of this argument is widely determined by using the internal validity indexes. Since these indexes suggest a k value which is computed on the clustering results after several runs of a clustering algorithm they are computationally expensive. On the contrary, 'kpeaks' enables to estimate k before running any clustering algorithm. It is based on a simple novel technique using the descriptive statistics of peak counts of the features in a data set.
| Version: |
0.1.0 |
| Depends: |
R (≥ 2.10.0) |
| Imports: |
graphics, stats, utils |
| Published: |
2017-09-19 |
| Author: |
Zeynel Cebeci [aut, cre],
Cagatay Cebeci [aut] |
| Maintainer: |
Zeynel Cebeci <zcebeci at cukurova.edu.tr> |
| License: |
GPL-2 | GPL-3 [expanded from: GPL (≥ 2)] |
| NeedsCompilation: |
no |
| Citation: |
kpeaks citation info |
| CRAN checks: |
kpeaks results |
Downloads:
Reverse dependencies:
Linking:
Please use the canonical form
https://CRAN.R-project.org/package=kpeaks
to link to this page.


class: center, middle, inverse, title-slide # Lecture 15 ## Pollution and health ### Ivan Rudik ### AEM 6510 --- exclude: true ```r if (!require("pacman")) install.packages("pacman") ``` ``` ## Loading required package: pacman ``` ```r pacman::p_load( tidyverse, xaringanExtra, rlang, patchwork, janitor, data.table ) options(htmltools.dir.version = FALSE) knitr::opts_hooks$set(fig.callout = function(options) { if (options$fig.callout) { options$echo <- FALSE } knitr::opts_chunk$set(echo = TRUE, fig.align="center") options }) ``` ``` ## Warning: 'xaringanExtra::style_panelset' is deprecated. ## Use 'style_panelset_tabs' instead. ## See help("Deprecated") ``` ``` ## Warning in style_panelset_tabs(...): The arguments to `syle_panelset()` changed ## in xaringanExtra 0.1.0. Please refer to the documentation to update your slides. ``` --- # Roadmap - How do we estimate the effect of a policy or environmental change when the treated and control groups do not (counterfactually) look the same in the cross-section? - What is the mortality cost of lead? --- class: inverse, center, middle name: dd # Difference-in-differences

 --- # Our comparisons so far So far we've made two kinds of comparisons to estimate treatment effects: 1. Comparing two groups with random assignment to treatment .hi[(RCT)] -- 2. Comparing two groups where there is a local discontinuity (i.e. discrete change) in policy .hi[(regression discontinuity)] -- In both of these we are comparing groups in the .hi-blue[cross-section]: there is no concept of time, before and after a policy was enacted, etc --- # Our comparisons so far The key assumption for these comparisons is that -- the treated group would have looked the same as the control group (i.e. had the same outcomes) in the absence of treatment -- This assumption is often hard to defend1 .footnote[ One way people show that this tends to not be true is to throw in a bunch of extra controls into the regression, if this affects your estimates it indicates there's likely a problem with the assumption. ] -- Let's try to relax this assumption by exploiting .hi-blue[temporal comparisons] in addition to the cross-sectional comparison --- # Difference-in-differences One way to describe our comparisons thus far is as .hi-red[differences] -- The estimated effect of a policy is simply the difference in expected outcomes between treated and control groups: `$$\delta = E[Y^1|D=1] - E[Y^0|D=0]$$` -- It's exactly that for an RCT since `\(D\)` was randomly assigned, and its the difference in conditional expectations (conditional on being around the threshold) for RDD --- # Difference-in-differences Our next method is called .hi-blue[difference-in-differences] (DD) -- What DD does is take the difference of two comparisons in three steps: -- 1. Take the difference in mean outcomes between treated and control .hi-red[before] treatment -- 2. Take the difference in mean outcomes between treated and control .hi-red[after] treatment -- 3. Take the difference between 1 and 2 -- The name comes from the fact that we are taking the difference (3) between two differences (1 and 2) --- # Difference-in-differences Why do we use DD? -- The identifying assumption required is less strict than for difference approaches -- .hi[**DD assumption:**] the treatment and control group would have followed .hi-blue[parallel trends] in the absence of treatment - i.e. the difference in outcomes would have remained constant -- This is much less stringent than requiring the outcomes to have been the same in the absence of treatment --- # Difference-in-differences .hi-red[Example:] Suppose we want to understand the effect of a conservation policy passed in New York on biodiversity -- Suppose also that: - The effect of the New York policy is given by .hi[B] -- - Each state has it's own fixed determinants of biodiversity (e.g. land cover, average temperature, etc) given by .hi[NY, PA, MA, etc] -- - Each period has it's own determinants of biodiversity, common across all states (e.g. federal policy, global climate change) given by .hi[T0, T1], where 0 is years before the policy is passed, and 1 is after --- # Difference-in-differences When we observe data on biodiversity we see the combination of all determinants: .hi[B + NY + T], not just .hi[B] -- We want to find a way to recover **only** .hi[E[B]] -- There are two ways you could think about trying to estimate .hi[B] using differences: -- 1. Compare New York to another state after the policy is passed -- 2. Compare New York to itself, before and after the policy is passed --- # The cross-sectional difference Let's compare New York to another state, Pennsylvania -- If we were to do this with differences we would get an estimate of .hi[B] given by:  .hi[(B + NY + T1) - (PA + T1) = B + NY - PA]  -- This is not .hi[B]! -- Why? --- # The cross-sectional difference  .hi[(B + NY + T1) - (PA + T1) = B + NY - PA]  There are other determinants of biodiversity that are different across New York and Pennsylvania that are .hi-blue[not] the policy: landcover, urbanization, pollution, etc -- If we take a simple difference across states, we can't disentangle whether the difference is due to the policy .hi[B] or differences in these other factors .hi[NY - PA] --- # The time series difference The next logical thing to try to circumvent this problem is to compare New York to itself, before .hi[NY + T0] and after .hi[B + NY + T1] the policy --  .hi[(B + NY + T1) - (NY + T0) = B + T1 - T0]  -- This is not .hi[B]! -- Why? --- # The time series difference  .hi[(B + NY + T1) - (NY + T0) = B + T1 - T0]  There are other determinants of biodiversity that are different before and after the policy that are .hi-blue[not] the New York policy: federal policy changes, trends in urbanization and pollution -- If we take a simple difference over time, we can't disentangle whether the difference is due to the policy .hi[B] or differences in other factors that are changing over time .hi[T1 - T0] --- # Difference-in-differences With DD we .hi-blue[combine] these two differences -- We take the time series differences for NY and PA: | | After | Before | Time Series Difference | |:------------:|:-------------------:|:--------------------------:|:-----------------------------------------------------------------------------------:| | New York | B + NY + T1 | NY + T0 | (B + NY + T1) - (NY + T0) = .hi[B + T1 - T0] | | Pennsylvania | PA + T1 | PA + T0 | (PA + T1) - (PA + T0) = .hi[T1 - T0] | -- Next, difference the time series differences to get the DD1 .footnote[ 1You can also difference in the opposite order and end up with the same result ] --- # Difference-in-differences | | After | Before | Time Series Difference | |:------------:|:-------------------:|:--------------------------:|:-----------------------------------------------------------------------------------:| | New York | B + NY + T1 | NY + T0 | (B + NY + T1) - (B + NY + T1) = .hi[B + T1 - T0] | | Pennsylvania | PA + T1 | PA + T0 | (PA + T1) - (PA + T0) = .hi[T1 - T0] | | | | | | | | | | | | | | Difference-in-differences: | .hi[(B + T1 - T0) - (T1 - T0) = B ] | -- The time series differences lets us control for all fixed determinants within a state (.hi[NY]) -- The cross-sectional difference lets us control for all period-specific determinants common across all states (.hi[T1]) -- Combining these two differences addresses both and lets us recover .hi[B], the true effect of the policy! --- # Difference-in-differences Note that DD is not magic -- It only can address determinants of biodiversity that are either: -- 1. Time-invariant -- 2. Time-varying, but common across all states -- If there is a determinant of biodiversity that is varying over time, and differentially across states, DD will fail to correctly estimate .hi[B] - State climate trends, state pollution trends, etc --- # Difference-in-differences Suppose that there is another determinant of biodiversity .hi[CNY1, CNY0] that only occurs in New York and varies over time - e.g. climate in New York relative to Pennsylvania Our DD is then | | After | Before | Time Series Difference | |:------------:|:-------------------:|:--------------------------:|:-----------------------------------------------------------------------------------:| | New York | B + NY + T1 + CNY1 | NY + T0 + CNY0 | (B + NY + T1) - (B + NY + T1) = .hi[B + T1 - T0 + CNY1- CNY0] | | Pennsylvania | PA + T1 | PA + T0 | (PA + T1) - (PA + T0) = .hi[T1 - T0] | | | | | | | | | | | | | | Difference-in-differences: | .hi[(B + T1 - T0) - (T1 - T0) = B + CNY1- CNY0 ] | --- # Difference-in-differences | | After | Before | Time Series Difference | |:------------:|:-------------------:|:--------------------------:|:-----------------------------------------------------------------------------------:| | New York | B + NY + T1 + CNY1 + CNY0 | NY + T0 | (B + NY + T1) - (B + NY + T1) = .hi[B + T1 - T0 + CNY1- CNY0] | | Pennsylvania | PA + T1 | PA + T0 | (PA + T1) - (PA + T0) = .hi[T1 - T0] | | | | | | | | | | | | | | Difference-in-differences: | .hi[(B + T1 - T0) - (T1 - T0) = B + CNY1- CNY0 ] | DD cannot isolate the effect of .hi[B] versus .hi[CNY1- CNY0] There cannot be any (uncontrolled for) time varying differences between NY and PA if we want to correctly estimate .hi[B] --- # Difference-in-differences: to the data Now lets see how this works in practice: [notebook here](https://raw.githack.com/irudik/aem6510/master/lecture-notes/13-health-dd/13-health-dd-notebook.html) -- What we are going to do is create a fake dataset where we .hi-blue[know the true value of what we want to estimate] -- This is a good skill to practice to make sure you understand methods and that your code works correctly --- exclude: true ``` ## Joining, by = "period" ``` ``` ## Joining, by = "state" ``` --- # DD step 1 ![](15-slides-health_files/figure-html/dd1-1.png) --- # DD step 2 ![](15-slides-health_files/figure-html/dd2-1.png) --- # DD step 3 ![](15-slides-health_files/figure-html/dd3-1.png) --- # DD step 4 ![](15-slides-health_files/figure-html/dd4-1.png) --- # DD step 5 ![](15-slides-health_files/figure-html/dd5-1.png) --- # DD step 6 ![](15-slides-health_files/figure-html/dd6-1.png) --- class: inverse, center, middle name: hr2021 # The effect of leaded gasoline on elderly mortality: Evidence from regulatory exemptions

 --- # What is the paper about? What is Hollingsworth and Rudik (2021) (.blue[HR]) about? -- HR aims to estimate the .hi-red[causal] effect of lead on mortality -- Why is this important? We know lead is bad -- 1. There is little causal evidence for any effects of lead -- 2. Almost zero *causal* evidence for effects of lead on adults in any way -- 3. Having an accurate measure of effects/costs is vital for policymaking --- # Environmental research directly affects policy! ![federal_register](files/15-federal_register.png) --- # How does the paper do it? HR estimates the causal effect of lead by exploiting a .hi-blue[quasi-experiment] -- A quasi-experiment is a real world occurrence that approximates an actual randomized control trial; quasi-experiments are also called natural experiments --- # How does the paper do it? Randomly assigning lead exposure to different groups is unethical, but we can learn from situations where real world exposure was *as good as random* -- The quasi-experiment HR exploits is the sudden removal of lead from racing gasoline in 2007 -- Places that happened to have racetracks in 2007 had a significant decrease in lead emissions relative to places without racetracks --- # How does the paper do it? Here's the 2x2 DD table | | Before | After | |:-------: |:--------------------------------------------: |:-------------------------------------------: | | .hi[Treated] | .hi[Areas near NASCAR racetracks before 2007] | .hi[Areas near NASCAR racetracks after 2007 ] | | Control | Areas far from NASCAR racetracks before 2007 | Areas far from NASCAR racetracks after 2007 | We are comparing areas .hi[close] vs far from racetracks, before vs after deleading in 2007 --- # How does the paper do it? Here's the 2x2 DD table | | Before | After | |:-------: |:--------------------------------------------: |:-------------------------------------------: | | Treated | Areas near NASCAR racetracks before 2007 | Areas near NASCAR racetracks after 2007 | | .hi[Control] | .hi[Areas far from NASCAR racetracks before 2007] | .hi[Areas far from NASCAR racetracks after 2007] | We are comparing areas close vs .hi[far] from racetracks, before vs after deleading in 2007 --- # How does the paper do it? Here's the 2x2 DD table | | .hi[Before] | After | |:-------: |:--------------------------------------------: |:-------------------------------------------: | | Treated | .hi[Areas near NASCAR racetracks before 2007] | Areas near NASCAR racetracks after 2007 | | Control | .hi[Areas far from NASCAR racetracks before 2007] | Areas far from NASCAR racetracks after 2007 | We are comparing areas close vs far from racetracks, .hi[before] vs after deleading in 2007 --- # How does the paper do it? Here's the 2x2 DD table | | Before | .hi[After] | |:-------: |:--------------------------------------------: |:-------------------------------------------: | | Treated | Areas near NASCAR racetracks before 2007 | .hi[Areas near NASCAR racetracks after 2007] | | Control | Areas far from NASCAR racetracks before 2007 | .hi[Areas far from NASCAR racetracks after 2007] | We are comparing areas close vs far from racetracks, before vs .hi[after] deleading in 2007 --- # How does the paper do it? .blue[track/treated counties], .green[border/weak treated counties], white control counties ![county map](files/15-figure_a3_county_type.png) --- # Event studies What HR do is actually a generalization of DD: an .hi-blue[event study] -- An event study is basically just a DD with multiple time periods before and after the treatment -- Here we estimate the effect of being in the treated group, relative to some baseline period - In the 2x2 DD this baseline period was "before" -- 1. We can look at dynamic effects -- 2. It provides supporting evidence for the parallel trends assumption --- # Event studies: dynamic effects With an event study we can see how the effect of a policy changes *over time* -- We will be able to estimate the effect in each post-period relative to some period -- If we see estimates getting larger, the effect grows over time -- If estimates get smaller, the effect shrinks --- # Event studies: parallel pre-trends In an event study we may have multiple periods before treatment -- We can estimate the effect of being in the treatment group in each of these (pre-)periods -- If there is no trend in the effect, the .hi-blue[pre-]trends are parallel -- This gives us some comfort that the trends were likely to be parallel in the post-period in the absence of treatment -- We never observe what would have .hi-red[actually] happened though, parallel pre-trends is just supporting evidence that the parallel trends assumption holds --- # HR (2021): to the data Now lets use the actual HR (2021) data to get some practice: [notebook here](https://raw.githack.com/irudik/aem6510/master/lecture-notes/13-health-dd/13-health-dd-notebook.html) --- # NASCAR emitted A LOT of lead In .hi[3 hours], one NASCAR race emits more lead than a majority of industrial facilities do in an .hi[entire year] .center[ ![](15-slides-health_files/figure-html/tri histogram-1.svg) ] --- # HR (2021): takeaways What can we take away from HR (2021) 1. Lead has a causal effect on elderly mortality - It appears to be through cardiovascular channels, perhaps *deaths of despair* as well (Case and Deaton, 2015) 2. The mortality costs are large - The external mortality costs imposed by NASCAR are larger than the value of all NASCAR teams combined - The social cost of lead is .hi-red[at least $1,000 per gram] - This is very, very, very big


--- layout: post title: 'Facebook API: post with PHP' date: 2011-01-04 17:20:28.000000000 +01:00 type: post published: true status: publish categories: - Coding tags: - api - automization - code snippets - facebook - movies - permissions - programming - sharemovies - web design meta: _edit_last: '1' _thumbnail_id: '667' socialize_text: If you enjoyed this post, please consider leaving a comment below or subscribing to the RSS feed to have future articles delivered to your feed reader. socialize: '1,2' _sexybookmarks_shortUrl: http://bit.ly/fvg77f _sexybookmarks_permaHash: 1cbe18269204ee6cc69cdf2e120f82e8 dsq_thread_id: '202642070' author: login: bbWebdesign email<EMAIL_ADDRESS>display_name: Bob first_name: Bob last_name: Belderbos ---
A few weeks ago I wrote a blog post on how to tweet with PHP. The post was quite successful so today part II: Facebook API: post with PHP. The principle is the same: you need to register an app on Facebook and with the API key you can get started.
First you go to Facebook's developer page and add an app. You can name it anything you want but make sure you put the right URL of the site (if you develop on your localhost you might consider register two apps because one api key is linked to one URL)
Then you download the facebook php client library and put in the application key and secret. Then you can use the Facebook login button to have people login to your app.
I am flying over this here because the main thing I wanted to show you today is how to automatically post to your Facebook wall. I will show you an example how I implemented this on sharemovi.es, a site I built to bring together movie fans.
The post that really helped me doing this was on stackoverflow which is one of those resources that always show up in Google, but also provides you with good answers!
Once you have initiated the facebook instance with the php client library, posting to facebook is quite easy:
$attachment = array('message' => 'Check out this movie ..', 'name' => $title, 'link' => 'http://sharemovi.es/' . $urlTitle, 'description' => 'Review: ' . $review, 'picture' => $picLocal ); if(!($sendMessage = $facebook->api('/me/feed/','post',$attachment))){ $errors= error_get_last(); echo "Facebook publish error: ".$errors['type']; echo "<br />\n".$errors['message']; }
Unfortunately Facebook does not allow you to select a FBCDN image (FBCDN standing for "Facebook content delivery network"), so you have to use another one or copy one from the FBCDN over to your server (hence $picLocal)
The beauty of the Facebook API lays in the fact it is highly customizable. As you can see, you can exactly specify what the wall post should look like, in my case a link to the new movie title, the review submitted by the user, etc.
Now to understand how this works for the user, let's see a practical example: a user logs into sharemovi.es via the Facebook login button. The first time the user is asked by Facebook to confirm if the Facebook app/ sharemovi.es may access his/her personal info, email and since last week the extended permission to post to his/her wall. Below you see only the latter permission, because the basic permissions I accepted already.
This allows the app to post to the user's wall, but that is only possible when a valid Facebook session has been established (user has logged in).
Implementing this technique, I made the design choice to explicitly ask the user to use this feature. This way there shouldn't be any misunderstanding when sharemovi.es posts to your wall.
Finally here you can see the outcome: a nice customized wall post!
You will recognize the fields of the code snippet. Friends can like and comment on your post, just as any link you share with the existing Facebook buttons. Below the post you see the source, which is the application, Sharemovi.es in this case.
One final thing, you can easily delete the post and even, in the same menu, revoke all access the Facebook application has been given. Facebook thought this out well: your granted access is never permanent and as easy as you give it, as easy it can be taken away:
I hope you liked this post. If so, please use the social media buttons at the top and the bottom of this post to spread the word. You can also subscribe to this blog (see sidebar) to receive a periodic newsletter with my latest blog posts.


Self starter, creative, detail oriented with extensive experience in guest relations, business development, and online marketing. Passionate about creating unique / memorable experiences. Keen on problem solving with creative solutions. With an active interest in Web and Mobile App Development.

Managed scheduling of extensive catering and event calendar.
Excelled in customer satisfaction and relations.
Menu creation and product testing.
Using customer feedback to maintain quaility control via Yelp.
Brand development, logo design and created promotional materials like koozies, stickers and T-shirts.
Developing FDG gave me first hand experience in turning a small idea into a recognizable venture, the entrepreneurial side of business was the true passion. With a new local owner, Frankie Dogs Gourmet remains a Fort Lauderdale favorite giving a little sparkle of independent culture where ever it rolls up.
ADDITIONAL SKILLS
Over 20 years experience in the guest services industry from theme parks to night club DJ.
Licensed professional hair stylist 2005 - 2012
SOFTWARE: Microsoft Office, Adobe Creative Suite, Final Cut Pro, Wordpress and a variety iOS / Android audio/video editing software.
Avid photographer and fluent in A/V production.
Extensive knowledge in social media online marketing & strategy.
Excellent worth ethic with particular attention to detail.
EDUCATION
A.S. Degree in Recording Engineering / Video Production 2001.
Master Student of Hard Knock School of Life 1979-Present.


{% extends "devilry_admin/assignment/students/groupview_base/base-multiselect-view.django.html" %} {% load i18n %} {% load cradmin_legacy_tags %} {% load cradmin_legacy_icon_tags %} {% block title %} {% trans "Organize students in project groups" %} {% endblock title %} {% block pageheader-outer-extraclasses %} {{ block.super }} devilry-page-header-with-backlink {% endblock %} {% block pageheader-inner %} {% trans "Back to student overview" %}
{% trans 'The first selected group will be the group to merge into, Then select one or more groups to be merged into the first selected.' %} {% trans 'Click "Create project group" to create a group containing all the students in the selected groups.' %} {% trans "Only put students in a project group if you want those students to cooperate on the assignments." %} {% trans "They will deliver together, and all feedback and grading is shared, Also previous existing feedback and comments on the assignment will also be shared." %}
{% endblock pageheader-inner %}


Manage and Marketing/Advertising By BRandBoost @2021 You can Contact them<EMAIL_ADDRESS>by there Social Media Handels