[ht::head {Defining New Entries}]
RAMADDA recognizes any file that ends with types.xml as an entry type definition file
exampletypes.xml
You can use this xml file as a plugin. But, if you wanted to include html resources
you would have a zipped directory like:
someplugin
exampletypes.xml
htdocs
myplugin
example.png
Note: the names above do not matter except
Column Types
- string - Use size="..." to specify the column size
- enumeration - See below to specify values
- enumerationplus - Just like enumeration but allows use to enter new text values
- list - A big string internally but shows a list of newline separated text values to the user
- password - A string but is shown in a password field
- clob - A big character large object
- int - Integer
- double - floating point number
- percentage - floating point number shows as percentage
- boolean
- date - Just a date
- datetime - A date and a time
- email - Shows as an email address
- url - Shows as a URL
- latlonbbox - spatial bounds
- latlon - A single point
For enumeration or enumerationplus types you can specify a set of enumeration values.


{% include 'parts/head.html' %}
{% include 'parts/header.html' %}
Berlioz FundMe Demo
v5.0
{% include 'parts/campaign.html' %}
{% include 'parts/donate.html' %}
{% include 'parts/recent.html' %}
{% include 'parts/global-error.html' %}


Gecode::MemoryConfig Namespace Reference
[Space-memory management]
Parameters defining memory management policy for spaces. More...
Functions | |
| void | align (size_t &s) |
| Align size s to the required alignment. | |
Variables | |
| const unsigned int | n_hc_cache = 4*4 |
| How many heap chunks should be cached at most. | |
| const size_t | hcsz_min = 1024 |
| Minimal size of a heap chunk requested from the OS. | |
| const size_t | hcsz_max = 32 * 1024 |
| Maximal size of a heap chunk requested from the OS. | |
| const int | hcsz_inc_ratio = 8 |
| Increment ratio for chunk size. | |
| const int | hcsz_dec_ratio = 8 |
| Decrement ratio for chunk size. | |
| const int | fl_unit_size = ((sizeof(void*) == 4) ? 2 : 3) |
| Unit size for free lists. | |
| const int | fl_size_min = ((sizeof(void*) == 4) ? 2 : 2) |
| Minimal size for free list element. | |
| const int | fl_size_max = ((sizeof(void*) == 4) ? 3 : 3) |
| Maximal size for free list element. | |
| const int | fl_refill = 8 |
| Number of free lists elements to allocate. | |
| const size_t | region_area_size = 32 * 1024 |
| Size of region area. |
Detailed Description
Parameters defining memory management policy for spaces.
Function Documentation
| void Gecode::MemoryConfig::align | ( | size_t & | s | ) | [inline] |
Align size s to the required alignment.
Definition at line 148 of file memory-config.hpp.
Variable Documentation
| const unsigned int Gecode::MemoryConfig::n_hc_cache = 4*4 |
How many heap chunks should be cached at most.
Definition at line 51 of file memory-config.hpp.
| const size_t Gecode::MemoryConfig::hcsz_min = 1024 |
Minimal size of a heap chunk requested from the OS.
Definition at line 56 of file memory-config.hpp.
| const size_t Gecode::MemoryConfig::hcsz_max = 32 * 1024 |
Maximal size of a heap chunk requested from the OS.
Maximal is not strictly true, if a contiguous memory chunk is requested that exceeds hcsz_max, a chunk will be allocated that fits that request.
Definition at line 64 of file memory-config.hpp.
| const int Gecode::MemoryConfig::hcsz_inc_ratio = 8 |
Increment ratio for chunk size.
If a space has requested hcsz_inc_ratio chunks of heap memory, the chunk size is doubled.
Definition at line 71 of file memory-config.hpp.
| const int Gecode::MemoryConfig::hcsz_dec_ratio = 8 |
Decrement ratio for chunk size.
When a space is cloned, the new clone normally inherits the current chunk size from the original space. However, if the original space has requested less than hcsz_dec_ratio heap chunks of the current chunk size, the current chunk size for the clone is halfed.
Definition at line 81 of file memory-config.hpp.
| const int Gecode::MemoryConfig::fl_unit_size = ((sizeof(void*) == 4) ? 2 : 3) |
Unit size for free lists.
The unit size (given as binary logarithm) defines how big a unit of memory for free lists is. Also, it defines the alignment. Sizes of free list objects must be multiples of the unit size.
Currently, for 32 bit machines, the unit size is 4 bytes. For 64 bit machines, it is 8 bytes.
Definition at line 94 of file memory-config.hpp.
| const int Gecode::MemoryConfig::fl_size_min = ((sizeof(void*) == 4) ? 2 : 2) |
Minimal size for free list element.
The minimal size is given in the number of free list units.
Currently, for 32 bit machines, the minimal size is 8 bytes. For 64 bit machines, it is 16 bytes.
Definition at line 103 of file memory-config.hpp.
| const int Gecode::MemoryConfig::fl_size_max = ((sizeof(void*) == 4) ? 3 : 3) |
Maximal size for free list element.
The maximal size is given in the number of free list units.
Currently, for 32 bit machines, the maximal size is 12 bytes. For 64 bit machines, it is 24 bytes.
Definition at line 112 of file memory-config.hpp.
| const int Gecode::MemoryConfig::fl_refill = 8 |
Number of free lists elements to allocate.
When a request for a free list element can not be fulfilled, as the free list is empty and there is also no reusable memory available, allocate fl_refill free list elements.
Definition at line 120 of file memory-config.hpp.
| const size_t Gecode::MemoryConfig::region_area_size = 32 * 1024 |
Size of region area.
The region area can be used in a stack fashion through access from a space. If the a request exceeds the current free space, memory will be allocated from the heap.
Definition at line 138 of file memory-config.hpp.


--- title: script_PlasticDeformation sidebar: documentation_sidebar permalink: PlasticDeformation.html folder: documentation toc: false ---
This script describes how to analyze Schmid factors.
Let us assume a Nickel crystal
{% highlight matlab %} CS = crystalSymmetry('cubic',[3.523,3.523,3.523],'mineral','Nickel') {% endhighlight %} {% highlight plaintext %} CS = crystalSymmetry mineral : Nickel symmetry: m-3m elements: 48 a, b, c : 3.5, 3.5, 3.5 {% endhighlight %}Since Nickel is fcc a dominant slip system is given by the slip plane normal
{% highlight matlab %} n = Miller(1,1,1,CS,'hkl') {% endhighlight %} {% highlight plaintext %} n = Miller (Nickel) h k l 1 1 1 {% endhighlight %}and the slip direction (which needs to be orthogonal)
{% highlight matlab %} d = Miller(0,-1,1,CS,'uvw') {% endhighlight %} {% highlight plaintext %} d = Miller (Nickel) u v w 0 -1 1 {% endhighlight %}For tension in direction 123
{% highlight matlab %} r = normalize(vector3d(1,2,3)) {% endhighlight %} {% highlight plaintext %} r = vector3d {% endhighlight %}the Schmid factor for the slip system [0-11](111) is defined by
{% highlight matlab %} tau = dot(d,r,'noSymmetry') * dot(n,r,'noSymmetry') {% endhighlight %} {% highlight plaintext %} tau = 0.4286 {% endhighlight %}The same computation can be performed by defining the slip system as an MTEX variable
{% highlight matlab %} sS = slipSystem(d,n) {% endhighlight %} {% highlight plaintext %} sS = slipSystem (Nickel) u v w | h k l CRSS 0 -1 1 1 1 1 1 {% endhighlight %}and using the command SchmidFactor
{% highlight matlab %} sS.SchmidFactor(r) {% endhighlight %} {% highlight plaintext %} ans = 0.1750 {% endhighlight %}Ommiting the tension direction r the command SchmidFactor returns the Schmid factor as a spherical function
{% highlight matlab %} SF = sS.SchmidFactor % plot the Schmid factor in dependency of the tension direction plot(SF) % find the tension directions with the maximum Schmid factor [SFMax,pos] = max(SF) % and annotate them annotate(pos) {% endhighlight %} {% highlight plaintext %} SF = S2FunHarmonic bandwidth: 64 antipodal: true isReal: true SFMax = 0.5000 pos = vector3d antipodal: true {% endhighlight %}Instead by the tension direction the stress might be specified by a stress tensor
{% highlight matlab %} sigma = stressTensor.uniaxial(vector3d.Z) {% endhighlight %} {% highlight plaintext %} sigma = stressTensor (xyz) rank: 2 (3 x 3) 0 0 0 0 0 0 0 0 1 {% endhighlight %}Then the Schmid factor for the slip system sS
and the stress tensor sigma
is computed by
In general a crystal contains not only one slip system but at least all symmetrically equivalent ones.  Now
returns a list of Schmid factors and we can find the slip system with the largest Schmid factor using
{% highlight matlab %} [tauMax,id] = max(abs(tau)) sSAll(id) {% endhighlight %} {% highlight plaintext %} tauMax = 0.4666 id = 8 ans = slipSystem (Nickel) u v w | h k l CRSS -1 0 -1 -1 1 1 1 {% endhighlight %}The above computation can be easily extended to a list of tension directions
{% highlight matlab %} % define a grid of tension directions r = plotS2Grid('resolution',0.5*degree,'upper'); % compute the Schmid factors for all slip systems and all tension % directions tau = sSAll.SchmidFactor(r); % tau is a matrix with columns representing the Schmid factors for the % different slip systems. Lets take the maximum rhowise [tauMax,id] = max(abs(tau),[],2); % vizualize the maximum Schmid factor contourf(r,tauMax) mtexColorbar {% endhighlight %}We may also plot the index of the active slip system
{% highlight matlab %} pcolor(r,id) mtexColorMap black2white {% endhighlight %}and observe that within the fundamental sectors the active slip system remains the same. We can even visualize the the plane normal and the slip direction
{% highlight matlab %} % if we ommit the option antipodal we can distinguish % between the oposite burger vectors sSAll = sS.symmetrise % take as directions the centers of the fundamental regions r = symmetrise(CS.fundamentalSector.center,CS); % compute the Schmid factor tau = sSAll.SchmidFactor(r); % here we do not need to take the absolut value since we consider both % burger vectors +/- b [~,id] = max(tau,[],2); % plot active slip plane in red hold on quiver(r,sSAll(id).n,'LineWidth',2,'Color','r'); % plot active slip direction in green hold on quiver(r,sSAll(id).b.normalize,'LineWidth',2,'Color','g'); hold off {% endhighlight %} {% highlight plaintext %} sSAll = slipSystem (Nickel) size: 24 x 1 u v w | h k l CRSS 0 -1 1 1 1 1 1 0 1 -1 1 1 1 1 1 0 -1 1 1 1 1 -1 0 1 1 1 1 1 -1 1 0 1 1 1 1 1 -1 0 1 1 1 1 -1 1 0 1 1 -1 1 1 -1 0 1 1 -1 1 -1 0 -1 1 1 -1 1 1 0 1 1 1 -1 1 0 -1 -1 1 1 -1 1 0 1 1 1 1 -1 1 0 -1 1 -1 1 1 1 0 1 -1 -1 1 1 1 -1 0 -1 -1 1 1 1 1 0 1 -1 1 1 1 -1 -1 0 -1 1 1 1 1 1 0 -1 1 1 1 1 0 -1 1 -1 1 1 -1 0 1 1 -1 1 1 -1 -1 0 1 -1 1 1 1 1 0 1 -1 1 1 0 -1 -1 1 -1 1 1 0 1 1 1 -1 1 1 {% endhighlight %}If we perform this computation in terms of spherical functions we obtain
{% highlight matlab %} % ommiting |r| gives us a list of 12 spherical functions tau = sSAll.SchmidFactor % now we take the max of the absolute value over all these functions contourf(max(abs(tau),[],1),'upper') mtexColorbar {% endhighlight %} {% highlight plaintext %} tau = S2FunHarmonic size: 24 x 1 bandwidth: 64 antipodal: true isReal: true {% endhighlight %}So far we have always assumed that the stress tensor is already given relatively to the crystal coordinate system. Next, we want to examine the case where the stress is given in specimen coordinates and we know the orientation of the crystal. Lets import some EBSD data and computet the grains
{% highlight matlab %} mtexdata csl % take some subset ebsd = ebsd(ebsd.inpolygon([0,0,200,50])) grains = calcGrains(ebsd); grains = smooth(grains,5); plot(ebsd,ebsd.orientations,'micronbar','off') hold on plot(grains.boundary,'linewidth',2) hold off {% endhighlight %} {% highlight plaintext %} ebsd = EBSD Phase Orientations Mineral Color Symmetry Crystal reference frame -1 154107 (100%) iron LightSkyBlue m-3m Properties: ci, error, iq, x, y Scan unit : um ebsd = EBSD Phase Orientations Mineral Color Symmetry Crystal reference frame -1 10251 (100%) iron LightSkyBlue m-3m Properties: ci, error, iq, x, y Scan unit : um {% endhighlight %}We want to consider the following slip systems
{% highlight matlab %} sS = slipSystem.fcc(ebsd.CS) sS = sS.symmetrise; {% endhighlight %} {% highlight plaintext %} sS = slipSystem (iron) u v w | h k l CRSS 0 1 -1 1 1 1 1 {% endhighlight %}Since, those slip systems are in crystal coordinates but the stress tensor is in specimen coordinates we either have to rotate the slip systems into specimen coordinates or the stress tensor into crystal coordinates. In the following sections we will demonstrate both ways. Lets start with the first one
{% highlight matlab %} % rotate slip systems into specimen coordinates sSLocal = grains.meanOrientation * sS {% endhighlight %} {% highlight plaintext %} sSLocal = slipSystem (xyz) CRSS: 1 size: 71 x 24 {% endhighlight %}These slip systems are now arranged in matrix form where the rows corrspond to the crystal reference frames of the different grains and the rows are the symmetrically equivalent slip systems. Computing the Schmid faktor we end up with a matrix of the same size
{% highlight matlab %} % compute Schmid factor sigma = stressTensor.uniaxial(vector3d.X) SF = sSLocal.SchmidFactor(sigma); % take the maxium allong the rows [SFMax,active] = max(SF,[],2); % plot the maximum Schmid factor plot(grains,SFMax,'micronbar','off','linewidth',2) mtexColorbar location southoutside {% endhighlight %} {% highlight plaintext %} sigma = stressTensor (xyz) rank: 2 (3 x 3) 1 0 0 0 0 0 0 0 0 {% endhighlight %}Next we want to visualize the active slip systems.
{% highlight matlab %} % take the active slip system and rotate it in specimen coordinates sSactive = grains.meanOrientation .* sS(active); hold on % visualize the trace of the slip plane quiver(grains,sSactive.trace,'color','b') % and the slip direction quiver(grains,sSactive.b,'color','r') hold off {% endhighlight %}We observe that the Burgers vector is in most case aligned with the trace. In those cases where trace and Burgers vector are not aligned the slip plane is not perpendicular to the surface and the Burgers vector sticks out of the surface.
Next we want to demonstrate the alternative route
{% highlight matlab %} % rotate the stress tensor into crystal coordinates sigmaLocal = inv(grains.meanOrientation) * sigma {% endhighlight %} {% highlight plaintext %} sigmaLocal = stressTensor (iron) size: 71 x 1 rank: 2 (3 x 3) {% endhighlight %}This becomes a list of stress tensors with respect to crystal coordinates - one for each grain. Now we have both the slip systems as well as the stress tensor in crystal coordiantes and can compute the Schmid factor
{% highlight matlab %} % the resulting matrix is the same as above SF = sS.SchmidFactor(sigmaLocal); % and hence we may proceed analogously % take the maxium allong the rows [SFMax,active] = max(SF,[],2); % plot the maximum Schmid factor plot(grains,SFMax) mtexColorbar % take the active slip system and rotate it in specimen coordinates sSactive = grains.meanOrientation .* sS(active); hold on % visualize the trace of the slip plane quiver(grains,sSactive.trace,'color','b') % and the slip direction quiver(grains,sSactive.b,'color','r') hold off {% endhighlight %}


might depend on the history-free variables of
ps. This needs to be worked out.
Side Effects If checkInvariant is TRUE, then the function changes
the status of the unchecked invariants to either passed
or failed.
See Also Enum_ModulePerformDFS
void
Enum_ModulePerformDFS(
Tcl_Interp * interp,
Main_Manager_t * mainManager,
Mdl_Module_t * module,
array_t * invNameArray,
array_t * typedExprArray
)
optional
Side Effects If checkInvariant is TRUE, then the function changes
the status of the unchecked invariants to either passed
or failed.
See Also Enum_ModulePerformBFS
char *
Enum_PartialStatePrintToString(
Enum_VarInfo_t * varInfo,
Enum_State_t * partialState
)
This function returns a string which contains the
valuation of the variables in the given partial state.
Side Effects User should free the string after use.
See Also optional
int
Enum_Reinit(
Tcl_Interp * interp,
Main_Manager_t * manager
)
Reinitializes the enum package.
Side Effects The state manager of the enum package is reset. All
states are freed and the varInfo associated with all
modules freed. The stateCounter is also reset to 0.
See Also Enum_Init
Enum_End
Enum_State_t *
Enum_StateAlloc(
Enum_VarInfo_t * varInfo
)
The function allocates and returns a state. It
initializes all variable values in the state to {LONG,
INT}_MAX, which means that these variables are
uninitialized. The parentState field is set to NULL.
Side Effects None
See Also Enum_StateFree
lsList
Enum_StateAssignAllVarCombinations(
Enum_State_t * state,
lsList varList,
Enum_VarInfo_t * varInfo
)
The function takes as arguments a partial state and a
variable list. The variables in varList should not have
been assigned a value in state. All variables
in varList should be of one of three types -
Var_Boolean_c, Var_Enumerated_c or Var_Event_c. If
successful, the function returns a list of states
(possibly partial) that have the same value as state for
all variables assigned to in state and all combinations
of the values to the variables in varList.
Side Effects None
Enum_State_t *
Enum_StateDup(
Enum_State_t * state,
Enum_VarInfo_t * varInfo
)
The function returnss a duplicate copy of state. It is the
responsibility of the caller function to free the
returned state. The parentState field is just copied
from state.
Side Effects None
void
Enum_StateFreeEventVars(
Enum_State_t * state
)
The function frees the event variables of a state and
sets the field eventVars to NULL.
Side Effects None
void
Enum_StateFreeHistFreeVars(
Enum_State_t * state
)
The function frees the history free variables of a
state and sets the field histFreeVars to NULL.
Side Effects None
void
Enum_StateFree(
Enum_State_t * state
)
The function frees all the internal memory of a state
and the state itself.
Side Effects None
See Also Enum_StateAlloc
boolean
Enum_StateIsVariableAssigned(
Enum_State_t * state,
Var_Variable_t * var,
Enum_VarInfo_t * varInfo
)
The function returns TRUE if var has been assigned a
value, otherwise it returns FALSE.
Side Effects None
See Also Enum_StateSetVariableValue
Enum_StateReadVariableValue
void
Enum_StateManagerAddVarInfo(
Enum_StateManager_t * stateManager,
Mdl_Module_t * module,
Enum_VarInfo_t * varInfo
)
Adds varInfo of a module to the state manager.
Side Effects None
Enum_StateManager_t *
Enum_StateManagerAlloc(
)
Allocates and initializes a state manager.
Side Effects None
See Also Enum_StateManagerFree
Enum_StateManagerReinitialize
void
Enum_StateManagerFree(
Enum_StateManager_t * stateManager
)
The function frees all memory associated with a state
manager, including all states and varInfo associated
with every module.
Side Effects None
See Also Enum_StateManagerAlloc
Enum_StateManagerReinitialize
void
Enum_StateManagerIncrementStateCounter(
Enum_StateManager_t * stateManager
)
This function increments the state counter in the state
manager.
Side Effects Increments the state counter.
Enum_VarInfo_t *
Enum_StateManagerObtainVarInfoFromModule(
Enum_StateManager_t * stateManager,
Mdl_Module_t * module
)
The function returns the varInfo of a module if it
exists in the state manager. Otherwise it creates the
Enum_VarInfo_t data structure, registers it with
state manager and returns the new data structure.
Side Effects moduleToVarInfo hash table inside stateManager could be
updated.
unsigned long
Enum_StateManagerReadStateCounter(
Enum_StateManager_t * stateManager
)
This function returns the state counter in the state
manager.
Side Effects None
Tcl_HashTable *
Enum_StateManagerReadStateNameTable(
Enum_StateManager_t * stateManager
)
This function returns the state table in the state
manager.
Side Effects None
char *
Enum_StateNameTableAddStateWithNameSuffix(
Enum_StateManager_t * stateManager,
char * moduleName,
Enum_State_t * state,
char * nameSuffix
)
Add a state to the TclHashTable.
Side Effects return string has to be freed by user.
char *
Enum_StateNameTableAddState(
Enum_StateManager_t * stateManager,
char * moduleName,
Enum_State_t * state
)
Add a state to the TclHashTable.
Side Effects return string has to be freed by user.
long
Enum_StateReadVariableValue(
Enum_State_t * state,
Var_Variable_t * var,
Enum_VarInfo_t * varInfo
)
The function returns the value of var in state. Note
that the function does not check if var has been
assigned a value in state. It is the user's
responsibility to make sure that he reads only a
variable that has been assigned.
Side Effects None
See Also Enum_StateSetVariableValue
Enum_StateIsVariableAssigned
void
Enum_StateSetParentState(
Enum_State_t * state,
Enum_State_t * parentState
)
The function sets the parentState field of state. This
field is used in producing a counterexample in case an
invariant check fails.
Side Effects None
void
Enum_StateSetVariableValue(
Enum_State_t * state,
Var_Variable_t * var,
Enum_VarInfo_t * varInfo,
long value
)
The value of the variable is set to value. Value is a
number for boolean, integer or natural number variables.
For symbolically enumerated variables, value is an index
associated with the symbolic values of the variable.
Side Effects The old value of the variable is overwritten by the new
value.
See Also Enum_StateReadVariableValue
Enum_StateIsVariableAssigned
Enum_StateTable_t *
Enum_StateTableAlloc(
int power,
Enum_VarInfo_t * varInfo
)
The function allocates and initializes a state table
data structure with 2^power number of buckets. The
number of buckets in the state table is always a power
of 2.
Side Effects None
See Also Enum_StateTableFree
Enum_StateTableEntry_t *
Enum_StateTableEntryAlloc(
Enum_State_t * state,
Enum_StateTableEntry_t * next
)
Allocates a state table entry data structure.
Side Effects None
See Also Enum_StateTableEntryFree
void
Enum_StateTableEntryFree(
Enum_StateTableEntry_t * entry
)
This function frees a state table entry. Note that it
does not free the state in the entry.
Side Effects None
See Also Enum_StateTableEntryAlloc
void
Enum_StateTableFree(
Enum_StateTable_t * stateTable
)
This function frees a state table and all the states in
it.
Side Effects None
See Also Enum_StateTableAlloc
Enum_VarInfo_t *
Enum_VarInfoAlloc(
Mdl_Module_t * module
)
Allocates the varInfo data structure of a module.
Side Effects None
See Also Enum_VarInfoFree
void
Enum_VarInfoFree(
Enum_VarInfo_t * varInfo
)
Frees a varInfo data structure.
Side Effects None
See Also Enum_VarInfoAlloc
Var_Variable_t **
Enum_VarInfoReadEventVars(
Enum_VarInfo_t * varInfo
)
Returns the event variables.
Side Effects None
Var_Variable_t **
Enum_VarInfoReadHistDependVars(
Enum_VarInfo_t * varInfo
)
Returns the history dependent variables.
Side Effects None
Var_Variable_t **
Enum_VarInfoReadHistFreeVars(
Enum_VarInfo_t * varInfo
)
Returns the history free variables.
Side Effects None
int
Enum_VarInfoReadNumEventVars(
Enum_VarInfo_t * varInfo
)
Returns the number of event variables.
Side Effects None
int
Enum_VarInfoReadNumHistDependVars(
Enum_VarInfo_t * varInfo
)
Returns the number of history dependent variables.
Side Effects None
int
Enum_VarInfoReadNumHistFreeVars(
Enum_VarInfo_t * varInfo
)
Returns the number of history free variables.
Side Effects None


Life ***
rated R starring Eddie Murphy, Martin Lawrence, Obba Batabunde, Lisa Nicole Carson, Nick Cassavettes, Noah Emmerich, Bokeem Woodbine, Clarence Williams III written by Robert Ramsey & Matthew Stone directed by Ted Demme
LIFE, Ted Demme's wonderful new film, falls prey to the predator called marketing.  Such things happen when an actors become typecast, as Eddie Murphy and Martin Lawrence have, but their new film, LIFE, is as expansive as it's title indicates.
Ray and Claude(Murphy and Lawrence, respectively), two practical strangers living in Harlem, meet when they are forced to retrieve many cases of beer for the local kingpin, Spanky, because of debts they each owe.  The man was beaten to death by a cop, but the hicks who find the two black men suspect him immediately, and before they know it they are sentenced to prison for life; hence the title.
The Mississippi State Prison of LIFE is a fairly lenient one. The prison is actually a large farm with no gates, but a boundary called the "gun line". Ray and Claude form an unlikely partnership, even though Claude still blames Ray for getting them into the prison. Among the colleagues they meet, the most memorable ones(I forget his name, but it's long) is a silent man(Bokeem Woodbine) who, because of his baseball ablility, is able to escape the prison for the Negro Leagues, and a homosexual inmate who is granted a pardon but decides to commit suicide instead of letting his parents see what's happened to him while in jail.
As Ray and Claude get older, the film begins to grow on the viewer more and more. After a few failed escape attempts during their lifetime, the two men are beginning to ponder their own existence and wonder why they're wasting their time. But they never lose hope.
These qualities of the film, among others, compare favorably with the Oscar winning Italian film LIFE IS BEAUTIFUL. Like LIFE IS BEAUTIFUL, LIFE's characters try to provide humor and dreams to get them through their suffering. Ray sparks the interest of his cellmates when they all begin to dream about their place in Ray's Boom Boom Room, a nightclub in which they all play their own little part. Ray and Claude help prove the universal theory that hope and faith can get anyone through the worst of times.
Director Ted Demme(BEAUTIFUL GIRLS, MONUMENT AVE.), nephew of director Jonathan Demme(SILENCE OF THE LAMBS, PHILADELPHIA) lets his actors shine in roles that flaunt their dramatic and comedic acting abilities. The film never really addresses subjects like racism head-on, but the film does, in a much deeper way, help unite a feeling of peace, instead of violence. The film then ends on a happy note, before subjecting the viewer to the unneccesary outtakes. But LIFE is still one of the year's most unexpected surprises. The film pulls no punches in getting it's way to your heart, and it proves that life, though not always beautiful, is always worth living.
a review by Akiva Gottlieb, The Teenage Movie Critic<EMAIL_ADDRESS>http://www.angelfire.com/mo/film watch me on TBS' "Dinner And A Movie" May 21, 8:05pm EST
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Request
public class Request
An incoming HTTP request.
-
The URI of the incoming request, as a URL for convenience
Declaration
Swift
public var url: URL { get }
-
The HTTP method of the incoming request (GET, POST, etc)
See also
HTTPMethodDeclaration
Swift
public var method: HTTPMethod { get }
-
The content type of the incoming request.
Note
Defaults toapplication/octet-stream
if missingDeclaration
Swift
public var contentType: String { get }
-
The HTTP headers of the incoming request.
See also
HTTPHeadersDeclaration
Swift
public var headers: HTTPHeaders { get }
-
The body of the incoming request.
Declaration
Swift
public var body: Data { get }
-
The body of the incoming request, as a String for convencience.
Declaration
Swift
public var bodyString: String { get }
-
Attempts to decode the body of the incoming request from JSON into the specified
Codable
.Declaration
Swift
public func json<T>(as: T) throws -> T where T : Decodable, T : Encodable
Parameters
as
The type to decode into.


critcl_use - Using CriTcl
Welcome to the C Runtime In Tcl, CriTcl for short, a system to build C extension packages for Tcl on the fly, from C code embedded within Tcl scripts, for all who wish to make their code go faster.
This document is a (hopefully) gentle introduction to it by way of a series of examples, both for how to embed C into Tcl with it, and how to build the distributable packages. As such the intended audience are both writers of packages with embedded C, and people building such packages. To make things easier the two themes each have their own section in this document, enabling all readers to quickly skip the part they are not interested in.
For those readers which came directly to this document through a search or similar and thus are in need of an overview of the whole system, please go and read the Introduction To CriTcl.
This is the section for developers writing, or wishing to write, a package embedding C into Tcl via critcl.
I guess that we are allowed to asssume that you, gentle reader, are here because you have written some Tcl code which is not fast enough (any more) and you wish to make it "go faster" by replacing parts (or all) of it with speedy C.
Another, and I believe reasonable assumption to make would be that you have already investigated and ruled out or done things like changes to data structures and algorithms which reduce O(n*n) work to O (n*log n), O(n), or even O(1). Of course, nothing prevents you from forging ahead here even if you have not done such. Still, even in that case I would recommend that you consider investigating this line of making your code go faster as well.
Now, with these introductory words out of the way, lets jump into the meat of things.
Starting simple, let us assume that the Tcl code in question is something like
proc math {x y z} { return [expr {(sin($x)*rand())/$y**log($z)}] }
with the expression pretending to be something very complex and slow. Converting this to C we get:
package require critcl critcl::cproc math {double x double y double z} double { double up = rand () * sin (x); double down = pow(y, log (z); return up/down; }
Notable about this translation:
All the arguments got type information added to them, here "double". Like in C the type precedes the argument name. Other than that it is pretty much a Tcl dictionary, with keys and values swapped.
We now also have to declare the type of the result, here "double", again.
The reference manpage lists all the legal C types supported as arguments and results.
In A Simple Procedure we demonstrated how easy a translation to C can be. Is it still as easy when we introduce something moderately complex like handling a variable number of arguments ? A feature which is needed to handle commands with options and optional arguments ? Unfortunately not. We can use critcl::cproc only if the number of arguments is known beforehand, i.e. at the time of declaration. This of course also means that they do not support default arguments either.
Thus, to handle something like the example below
proc math {args} { set sum 0 foreach y { set sum [expr {$sum + $y}] } return $sum }
we have to use critcl::ccommand instead.
Its advantage: Access to the low-level C arguments representing the Tcl arguments of the command. That allows things like variable number of arguments, optional arguments, options, etc.
Its disadvantage: Access to the low-level C arguments representing the Tcl arguments of the command. Where critcl::cproc handles the task of converting from Tcl to C values (for arguments) and back (for the result), with critcl::commands we have to do this on our own.
Here is the translation of the example:
package require critcl critcl::ccommand math {cd ip oc ov} { double sum = 0; double y; while (oc) { if (Tcl_GetDoubleFromObj (ip, ov[oc], &y) != TCL_OK) { return TCL_ERROR; } sum += y; oc --; } Tcl_SetObjResult (ip, Tcl_NewDoubleObj (sum)); return TCL_OK: }
Notable about this translation:
As promised/threatened, all the conversions between the Tcl and C domains are exposed, and the developer should know her way around Tcl's C API.
The four arguments "cd ip oc ov" are our names for the low-level arguments holding
ClientData (reference)
Tcl_Interp (reference)
Number of arguments, and
Array of argument values, each a Tcl_Obj*.
This list of arguments, while not optional in itself, is allowed to be empty, and/or to contain empty strings as argument names. If we do that critcl will supply standard names for the missing pieces, namely:
clientdata
interp
objc
objv
Here we assume that we have a Tcl procedure which returns a fixed string. In the final product we are going to C to hide this string from the casual user.
proc somedata {} { return {... A large blob of characters ...} }
The translation of this is simple and easy:
package require critcl critcl::cdata somedata {... A large blob of characters ...}
There is nothing really notable here.
Often just defining Tcl commands in C, as demonstrated in the sections A Simple Procedure, Handling A Variable Number Of Arguments, and Data As A Tcl Command is not really enough. For example we may have several of our new C commands using the same code over and over, and we wish avoid this duplication. Or we wish to pull in declarations and definitions from some external library.
In both cases we require the ability to embed an unstructured block of C code which can contain whatever we want, defines, functions, includes, etc. without being directly tied to Tcl commands. The command critcl::code provides us with exactly that. As our example now an excerpt taken from real code, the top of the "sha1c.tcl" critcl file in the sha1 module of Tcllib:
critcl::ccode { #include "sha1.h" #include <stdlib.h> #include <assert.h> static Tcl_ObjType sha1_type; /* fast internal access representation */ static void sha1_free_rep(Tcl_Obj* obj) { SHA1_CTX* mp = (SHA1_CTX*) obj->internalRep.otherValuePtr; Tcl_Free(mp); } ... }
We see here the beginning of the C code defining a custom Tcl_ObjType holding the data of a SHA1 context used during the incremental calculation of sha1 hashes.
When writing a critcl-based package to make a third-party library available to scripts we do not only have to make the relevant functions available as commands, often we also have to know all the various constants, flags, etc. these functions take.
Rather than writing such magic numbers directly we would greatly prefer to use symbolic names instead. Instead of providing one or more commands to list and map the magic numbers to strings critcl only provides a single command which allows the export of C defines and enumeration values, mapping them to Tcl variables of the given names, whose values are the associated magic numbers.
This is good enough because the developers of the third-party library were very likely like us and wanted to use symbolic names instead of magic numbers. Which in C are declared as via defines and enumeration types. We just have to lift them up.
Our example comes from cryptkit, a Tcl binding to cryptlib, a cryptography library. The command
critcl::cdefines CRYPT_* ::crypt
maps all Cryptlib specific #defines and enums into the namespace ::crypt, telling critcl to create aliases to the symbols.
Similarly
critcl::cdefines { NULL TRUE FALSE TCL_OK TCL_ERROR } ::crypt
maps the listed defines into the namespace ::crypt.
An important thing to note: These commands do not create the defines in the C level. They only lift pre-existing material. Which can come from the headers of the third-party library, the usual case, but also from Blocks of arbitrary C.
A corrollary to the above: What is not where, cannot be lifted. All listed names and patterns which have no actual C code declaring them are ignored, i.e. not mapped.
A notable thing in the example shown in the section about Blocks of arbitrary C is the
#include "sha1.h"
statement. Where does this header come from ? Looking at the Tcllib module we will find that the header is actually a sibling to the "sha1c.tcl" file containing the embedded C code. However, critcl does not know that. It has to be told. While without that knowledge it will invoke the compiler just fine, the compilation will fail because the header is not on the include paths used by the compiler, and therefore will not be found.
For this we have the critcl::cheaders command. It enables us to either tell the compiler the path(s) where the required headers can be found, using
critcl::cheaders -I/path/to/headers/
or to tell it directly which headers we are using and where they live:
critcl::cheaders sha1.h
And now critcl knows that "sha1.h" is important, and that it lives besides the ".critcl" file which referenced it (because of the relative path used). Note that this doesn't absolve us of the need to "#include" the header through a critcl::ccode block. This only tells critcl where it lives so that it can configure the compiler with the proper include paths to actually find it on use.
Further note that a C development environment is usually configured to find all the system headers, obviating the need for a critcl::cheaders declaration when such are used. For these a plain "#include" in a critcl::ccode block is good enough. In other words, the second form of invoking critcl::cheaders is pretty much only for headers which accompany the ".critcl" file.
In all of the examples shown so far the C code was fully embedded in a ".critcl" file. However, if the C part is large it can make sense to break it out of the ".critcl" file into one or more separate proper ".c" file(s).
The critcl::csources command can then be used to make this code known to the original ".critcl" file again. This command accepts the paths to the ".c" files as arguments, and glob patterns as well. Our example comes from the struct::graph package in Tcllib. Its core C functions are in separate files, and the ".critcl" code then makes them known via:
namespace eval ::struct { # Supporting code for the main command. critcl::cheaders graph/*.h critcl::csources graph/*.c ... }
which tells critcl that these files are in the subdirectory "graph" relative to the location of "graph_c.tcl", which is the relevant ".critcl" file.
This example also demonstrates again the use of critcl::cheaders, which we also saw in section Finding header files.
When creating a package exposing some third-party library to Tcl Finding header files is only the first part, to enable failure-free compilation. We also have to find the library/ies themselves so that they can be linked to our package. This is described here. The last issue, Lifting constants from C to Tcl for the use by scripts is handled in a separate section and example.
The relevant command is critcl::clibraries. Its basic semantics are like that of critcl::cheaders, i.e. It enables us to tell the linker the path(s) where the required libraries can be found, using
critcl::clibraries -L/path/to/libraries/
name them
critcl::clibraries -lfoo
or tell it directly which libraries we are using and where they live:
critcl::clibraries /path/to/library/foo.so
This last way of using should be avoided however, as it intermingles searching and naming, plus the name is platform dependent.
For OS X we additionally have the critcl::framework command which enables us to name the frameworks used by our package. Note that this command can be used unconditionally. If the build target is not OS X it is ignored.
The commands critcl::cflags and critcl::ldflags enable you to provide custom options to the compile and link phases for a ".critcl" file.
This usually becomes necessary if the C code in question comes from an external library we are writing a Tcl binding for, with multiple configurations to select, non-standard header locations, and other things. Among the latter, especially platform-specific settings, for example byteorder.
This makes critcl::check an important adjunct command, as this is the API for Checking The Environment, and then selecting the compile & link flags to use.
I currently have no specific example to demonstrate these commands.
Often enough only pieces of a package require recoding in C to boost the whole system. Or, alternatively, the package in question consists of a low-level layer C with a Tcl layer above encoding policies and routing to the proper low-level calls, creating a nicer (high-level) API to the low-level functionality, etc.
For all of this we have to be able to write a package which contains both C and Tcl, nevermind the fact the C parts are embedded in Tcl.
The easiest way to structure such a package is to have several files, each with a different duty. First, a ".critcl" file containing the embedded C, and second one or more ".tcl" files providing the Tcl parts. Then use the critcl::tsources command in the ".critcl" file to link the two parts together, declaring the ".tcl" files as necessary companions of the C part.
package require critcl critcl::tsources your-companion.tcl ; # Companion file to use ... embedded C via critcl commands ...
With a declaration as shown above the companion file will be automatically sourced when the C parts are made available, thus making the Tcl parts available as well.
There is one special case of Having both C and Tcl functionality which deserves its own section.
The possibility of not having the fast C code on some platform, and using a slower Tcl implementation of the functionality. In other words, a fallback which keeps the package working in the face of failure to build the C parts. A more concrete example of this would be a module implementing the SHA hash, in both C and Tcl, and using the latter if and only if the C implementation is not available.
There two major possibilities in handling such a situation.
Keep all the pieces separated. In that scenario our concrete example would be spread over three packages. Two low-level packages sha::c and sha::tcl containing the two implementations of the algorithm, and, thirdly, a coordinator package sha which loads either of them, based on availability.
The Tcllib bundle of packages contains a number of packages structured in this manner, mostly in the struct module.
Writing the C and Tcl parts should be simple by now, with all the examples we had so far. The only non-trivial part is the coordinator, and even that if and only if we wish to make it easy to write a testsuite which can check both branches, C, and Tcl without gymnastics. So, the most basic coordinator would be
set sha::version 1 if {[catch { package require sha::c $sha::version }]} { package require sha::tcl $sha::version } package provide sha $sha::version
It tries to load the C implementation first, and falls back to the Tcl implementation if that fails. The code as is assumes that both implementations create exactly the same command names, leaving the caller unaware of the choice of implementations.
A concrete example of this scheme can be found in Tcllib's md5 package. While it actually uses ythe Trf as its accelerator, and not a critcl-based package the principle is the same. It also demonstrates the need for additional glue code when the C implementation doesn't exactly match the signature and semantics of the Tcl implementation.
This basic coordinator can be easily extended to try more than two packages to get the needed implementation. for example, the C implementation may not just exist in a sha::c package, but also bundled somewhere else. Tcllib, for example, has a tcllibc package which bundles all the C parts of its packages which have them in a single binary.
Another direction to take it in is to write code which allows the loading of multiple implementations at the same time, and then switching between them at runtime. Doing this requires effort to keep the implementations out of each others way, i.e. they cannot provide the same command names anymore, and a more complex coordinator as well, which is able to map from the public command names to whatever is provided by the implementation.
The main benefit of this extension is that it makes testing the two different implementations easier, simply run through the same set of tests multiple times, each time with different implementation active. The disadvantage is the additional complexity of the coordinator's internals. As a larger example of this technique here is the coordinator "modules/struct/queue.tcl" handling the C and Tcl implementations of Tcllib's struct::queue package:
# queue.tcl -- # Implementation of a queue data structure for Tcl. package require Tcl 8.4 namespace eval ::struct::queue {} ## Management of queue implementations. # ::struct::queue::LoadAccelerator -- # Loads a named implementation, if possible. proc ::struct::queue::LoadAccelerator {key} { variable accel set r 0 switch -exact -- $key { critcl { # Critcl implementation of queue requires Tcl 8.4. if {![package vsatisfies [package provide Tcl] 8.4]} {return 0} if {[catch {package require tcllibc}]} {return 0} set r [llength [info commands ::struct::queue_critcl]] } tcl { variable selfdir if { [package vsatisfies [package provide Tcl] 8.5] && ![catch {package require TclOO}] } { source [file join $selfdir queue_oo.tcl] } else { source [file join $selfdir queue_tcl.tcl] } set r 1 } default { return -code error "invalid accelerator/impl. package $key: must be one of [join [KnownImplementations] {, }]" } } set accel($key) $r return $r } # ::struct::queue::SwitchTo -- # Activates a loaded named implementation. proc ::struct::queue::SwitchTo {key} { variable accel variable loaded if {[string equal $key $loaded]} { # No change, nothing to do. return } elseif {![string equal $key ""]} { # Validate the target implementation of the switch. if {![info exists accel($key)]} { return -code error "Unable to activate unknown implementation \"$key\"" } elseif {![info exists accel($key)] || !$accel($key)} { return -code error "Unable to activate missing implementation \"$key\"" } } # Deactivate the previous implementation, if there was any. if {![string equal $loaded ""]} { rename ::struct::queue ::struct::queue_$loaded } # Activate the new implementation, if there is any. if {![string equal $key ""]} { rename ::struct::queue_$key ::struct::queue } # Remember the active implementation, for deactivation by future # switches. set loaded $key return } # ::struct::queue::Implementations -- # Determines which implementations are # present, i.e. loaded. proc ::struct::queue::Implementations {} { variable accel set res {} foreach n [array names accel] { if {!$accel($n)} continue lappend res $n } return $res } # ::struct::queue::KnownImplementations -- # Determines which implementations are known # as possible implementations. proc ::struct::queue::KnownImplementations {} { return {critcl tcl} } proc ::struct::queue::Names {} { return { critcl {tcllibc based} tcl {pure Tcl} } } ## Initialization: Data structures. namespace eval ::struct::queue { variable selfdir [file dirname [info script]] variable accel array set accel {tcl 0 critcl 0} variable loaded {} } ## Initialization: Choose an implementation, ## most prefered first. Loads only one of the ## possible implementations. And activates it. namespace eval ::struct::queue { variable e foreach e [KnownImplementations] { if {[LoadAccelerator $e]} { SwitchTo $e break } } unset e } ## Ready namespace eval ::struct { # Export the constructor command. namespace export queue } package provide struct::queue 1.4.2
In this implementation the coordinator renames the commands of the low-level packages to the public commands, making the future dispatch as fast as if the commands had these names anyway, but also forcing a spike of bytecode recompilation if switching is ever done at the runtime of an application, and not just used for testing, and possibly disrupting introspection by the commands, especially if they move between different namespaces.
A different implementation would be to provide the public commands as procedures which consult a variable to determine which of the loaded implementations is active, and then call on its commands. This doesn't disrupt introspection, nor does it trigger bytecode recompilation on switching. But it takes more time to dispatch to the actual implementation, in every call of the public API for the package in question.
A concrete example of this scheme can be found in Tcllib's crc32 package.
Mix the pieces together. Please note that while I am describing how to make this work I strongly prefer and recommend to use the previously shown approach using separate files/packages. It is much easier to understand and maintain. With this warning done, lets go into the nuts and bolts.
If we care only about mode "compile & run" things are easy:
package require critcl if {![critcl::compiling]} { proc mycommand {...} { ... } } else { critcl::cproc mycommand {...} { ... } }
The command critcl::compiling tells us whether we have a compiler available or not, and in the latter case we implement our command in Tcl.
Now what happens when we invoke mode "generate package" ? ... compiler failure ... ... ok - C code - everything fine ... fail - no package ? or just no C code ? declare self as tsource, to be used ? ... platform-specific C/Tcl -- uuid.
By default critcl is a bit inconsistent between modes "compile & run" and "generate package". The result of the latter is a standard Tcl package which loads and sources all of its files immediately when it is required. Whereas "compile & run" defers actual compilation, linking, and loading until the first time one of the declared commands is actually used, making this very lazy.
This behaviour can be quite unwanted if Tcl companion files, or other users of the C commands use introspection to determine the features they have available. Just using [info commands] doesn't cut it, the auto_index array has to be checked as well, making things quite inconvenient for the users.
To fix this issue at the source, instead of in each user, be it inside of the package itself, or other packages, we have the command critcl::load. Used as the last command in a ".critcl" file it forces the compile, link, and load trinity, ensuring that all C commands are available immediately.
package require critcl ... Declare C procedures, commands, etc. critcl::load ; # Force build and loading.
Note that is not allowed, nor possible to use critcl commands declaring anything after critcl::load has been called. I.e., code like
package require critcl ... Declare C procedures, commands, etc. critcl::load ; # Force build and loading. ... More declarations of C code, ... critcl::code { ... }
will result in an error. The only package-related commands still allowed are
critcl::done
critcl::failed
critcl::load
as these only query information, namely the build status, and are protected against multiple calls.
As said several times, by default critcl defers the compile and link steps for a file until it is needed, i.e. the first command of the ".critcl" file in question is actually invoked.
This not only has the effect of lazily loading the package's functionality, but also, when developing using mode "compile & run", of us not seeing any errors in our code until we are actually trying to run some demonstration.
If we do not wish to have such a delay we have to be able to force at least the execution of the compile step.
The command critcl::failed is exactly that. When called it forcibly builds the C code for the ".critcl" file it is part of, and returns a boolean vlaue signaling failure (true), or success (false).
package require critcl ... Declare C procedures, commands, etc. if {[critcl::failed]} { ... signal error }
It is related and similar to critcl::load, the command to overcome the lazy loading, as shown in section Unlazy Packages.
Like it is not allowed, nor possible to use critcl commands declaring anything after critcl::failed has been called, making it pretty much the last critcl command in a ".critcl" file. Code like
package require critcl ... Declare C procedures, commands, etc. if {[critcl::failed]} { ... } ... More declarations of C code, ... critcl::code { ... }
will result in an error. The only package-related commands still allowed are
critcl::done
critcl::failed
critcl::load
as these only query information, namely the build status, and are protected against multiple calls.
When building the shared library from the embedded C sources one of the things critcl does for us is to provide the Tcl headers, especially the stubs declarations.
By default these are the Tcl 8.4 headers and stubs, which covers 90% of the cases. What when the package in question is meant for use with Tcl 8.5 or higher, using C-level features of this version of Tcl.
Use the critcl::tcl command to declare to critcl the minimum version of Tcl required to operate the package. This can be either 8.4, 8.5, or 8.6, and critcl then supplies the proper headers and stubs.
package require critcl critcl::tcl 8.5 ... Declare your code ...
... requires compiling against the Tk headers, and linking with Tk's stubs. For our convenience we have a simple, single command to activate all the necessary machinery, with critcl supplying the header files and stubs C code, instead of having to make it work on our own via critcl::cflags, critcl::ldflags, critcl::cheaders, critcl::csources.
This command is critcl::tk.
package require critcl critcl::tk ; # And now critcl knows to put in the Tk headers and other support. ... Declare your code ...
Please note that this doesn't release you from the necessity of learning Tk's C API and how to use it to make a widget work. Sorry.
... may be necessary when creating a binding to some third-party library. The headers for this library may be found in non-standard locations, ditto for the library/ies itself. We may not have the headers and/or library on the build host. Types with platform-dependent sizes and definitions. Endianess issues. Any number of things.
TEA-based packages can use autoconf and various predefined macros to deal with all this. We have the Power Of Tcl (tm) and critcl::check.
This command takes a piece of C code as argument, like critcl::ccode. Instead of saving it for later it however tries to compile it immediately, using the current settings, and then returns a boolean value reporting on the success (true) or failure (false). From there we can then branch to different declarations.
As example let us check for the existence of some header "FOO.h":
package require critcl if {[critcl::check { #include <FOO.h> }]} { ... Code for when FOO.h is present. } else { ... Code for when FOO.h is not present. }
Should we, on the other hand, wish to search for the header ourselves, in non-standard locations we have the full power of Tcl available, i.e. loops, the file and glob commands, etc., which can then be followed by a critcl::cheader command to declare the location we found (See also Finding header files).
A nice extension to critcl would be a package collecting pocedures for common tasks like that, sort of like an autoconf for Tcl. critcl::config seems to be nice name for such a package.
Obvious adjunct commands which can be driven by results from critcl::check are
Less obvious, yet still valid are also
and pretty much everything else you can imagine.
When writing packages it is always good manners to provide prospective users with the license the package is under, so that they can decide whether they truly want to use the package, or not.
As critcl-based packages often consist of only a single file a nice way of doing that is to embed the license in that file. By using a critcl command, namely critcl::license this information is then also available to the critcl application, which can put it into a standard location, i.e. "license.terms", of the generated packages.
I currently have no specific example to demonstrate the command.
This is the section for developers having to generate packages from ".critcl" files, i.e binaries for deployment,
... Is easy. Running
critcl -help
prints the basics of using the application to stdout.
The default mode of the critcl application is to take a series of ".critcl" files, build their binaries, and leave them behind in the result cache. When the files are later actually used the compile and link steps can be skipped, leading to shorter load times.
The command line for this is
critcl foo.tcl
or, to process multiple files
critcl foo.tcl bar.tcl ...
One thing to be aware of, should critcl find that the cache already contains the results for the input files, no building will be done. If you are sure that these results are outdated use the option -force to force(sic!) critcl to rebuild the binaries.
critcl -force foo.tcl
For debugging purposes it may be handy to see the generated intermediate ".c" files as well. Their removal from the cache can be prevented by specifying the option -keep.
critcl -keep foo.tcl
These can be combined, of course.
To build the binary package for a ".critcl" file, instead of Pre-Filling The Result Cache, simply specify the option -pkg.
critcl -pkg foo.tcl
This will geneate a package named foo. A simpler alternative to the above is
critcl -pkg foo
The application will automatically assume that the input file to look for is "foo.tcl".
But what when the name of the input file is not the name of the package to build ? This we can handle as well:
critcl -pkg foo bar.tcl
The argument foo specifies the name, and "bar.tcl" is the file to process.
Going back to the very first example, it is of course possible to use an absolute path to specify the file to process:
critcl -pkg /path/to/foo.tcl
The package name derived from that is still foo.
Here we assume that you know the basics of how to build a package. If not, please read section Building A Package first.
By default critcl will place all newly-made packages in the subdirectory "lib" of the current working directory. I.e. running
critcl -pkg foo
will create the directory "lib/foo" which contains all the files of the package.
When this behaviour is unwanted the option -libdir is available, allowing the explicit specification of the destination location to use.
critcl -pkg -libdir /path/to/packages foo
A common use might be to not only build the package in question, but to also immediately install it directly in the path where the user's tclsh will be able to find it. Assuming, for example, that the tclsh in question is installed at "/path/to/bin/tclsh", with the packages searched for under "/path/to/lib" ([info library]), the command
critcl -pkg -libdir /path/to/lib foo
will build the package and place it in the directory "/path/to/lib/foo".
Here we assume that you know the basics of how to build a package. If not, please read section Building A Package first.
An important issue, when there is trouble with the package, debugging becomes necessary a evil. Critcl supports this through the -debug option. Using it enables various build modes which help with that.
For example, to activate the Tcl core's built-in memory debugging subsystem build your package with
critcl -pkg -debug memory foo
The resulting binary for package foo will use Tcl's debug-enabled (de)allocation functions, making them visible to Tcl's memory command. This of course assumes that the Tcl core used was also built for memory debugging.
Further, built your package with
critcl -pkg -debug symbols foo
to see the foo's symbols (types, functions, variables, etc.) when inspecting a "core" file it is involved in with a symbolic debugger,
To activate both memory debugging and symbols use either
critcl -pkg -debug all foo
or
critcl -pkg -debug symbols -debug memory foo
The configuration settings critcl uses to drive the compiler, linker, etc. are by default selected based on the platform it is run on, to generate binaries which properly work on this platform.
There is one main use-case for overriding this selection, which is done with the option -target:
Cross-compilation. The building of binaries for a platform T while critcl actually runs on platform B. The standard configuration of critcl currently has settings for two cross-compilation targets. So, to build 32bit Windows binaries on a Linux host which has the Xmingw cross-compilation development environment installed use
critcl -pkg -target mingw32 foo
Similarly, building a package for use on ARM processors while critcl is running in an Intel environment use
critcl -pkg -target linux-arm foo
Note that both configurations assume that the cross-compiling compiler, linke, etc. are found first in the PATH.
The compiler configurations coming with critcl currently cover all hosts having gcc installed (the foremost among these are Linux and OS X), plus the native compilers of the more common unix-like operating systems, i.e. Solaris, HP-UX, and AIX, and, on the non-unix side, Windows.
Developers using operating systems and compilers outside of this range will either have to install a gcc-based development environment, i.e. get into the covered range, or write their own custom configuration and then tell critcl about it.
The latter is the easier part, given that critcl supports the option -config whose argument is the path to the file containing the custom configuration(s). I.e.
critcl -config /path/to/config ...
will run critcl with the custom configuration in "/path/to/config", with the other options and arguments as explained in previous sections. Depending on the choice of name for the new configuration(s) this may or may not require a -target option to select the configuration needed.
For the former, the writing of the custom configuration, the reader is refered to the section "Configuration Internals" of the CriTcl Package Reference for the necessary details. This is an advanced topic pretty much out of scope for this tutorial beyond what was already said.
Sometimes the use of critcl::headers might not be enough for a package to find its headers. Maybe they are outside of the paths checked by the setup code. To help the application recognizes the option -I which allows the user to supply a single additional include path to use during the build phase of the package.
Simply use
critcl -I /path/to/header ...
and the specified header will be handed to the package to be built.
To see a list containing the names of all the available configurations, run
critcl -targets
The configuration settings for either the default or user-chosen target can be inspected on stdout with
critcl -show
and
critcl -show -target TARGET
The raw contents of the configuration file used by critcl are dumped to stdout with
critcl -showall
All of the above can of course be combined with custom configuration files.
Jean Claude Wippler, Steve Landers, Andreas Kupries
This document, and the package it describes, will undoubtedly contain bugs and other problems. Please report such at https://github.com/jcw/critcl. Please also report any ideas for enhancements you may have for either package and/or documentation.
C code, Embedded C Code, code generator, compile & run, compiler, dynamic code generation, dynamic compilation, generate package, linker, on demand compilation, on-the-fly compilation
Glueing/Embedded C code
Copyright © Jean-Claude Wippler
Copyright © Steve Landers
Copyright © 2011 Andreas Kupries


Space Wonders makes you discover the wonders of the universe by showing you one picture a day.
This website is a rework of the original Astronomy Picture of the Day.
You can also use the "Random Wonder" link to view a picture from a random past day.
Space Wonders is mobile compatible but keep in my that the images may be heavy and take some time to download.
Made by Julien Montavit


| Blaming herself for a tragic accident, Raven Michaels secludes herself at a remote family cabin. She wanders the woods on the verge of a breakdown, seeking peace in isolation. In a last ditch attempt to save her family, Kate Royce takes her two teenagers camping far from the distractions of technology and young romance. When Raven and Kate's worlds collide they offer each other unexpected opportunities for intimacy and healing. | |
| Genres: | Drama |
| Director: | Marina Rice Bader, Dreya Weber |
| Writer: | Dreya Weber |
Cast: | Raven - Dreya Weber Kate - Traci Dinwiddie Joe - David Hayward Maya - Victoria Park Jack - Chris O'Neal Angela - Nadège August Betty - Kathe Mazur Andy - Mike McAleer Niece - Isla Weber |


flat
: name
flat
is one of the three relations for compounding in UD (together
with compound and fixed).
It is used for proper nouns constituted of multiple nominal
elements. For example, flat
would be used between the words of
Hillary Rodham Clinton, New York, or Carl XVI Gustaf but not to
replace the usual relations in a phrasal or clausal name like The
king of Sweden or the novels The Lord of the Rings and Captured By
Aliens.
Words joined by flat
should all be part of a minimal noun phrase;
otherwise regular syntactic relations should be used. This is
basically similar to the treatment of noun compounds with
compound, except that in many cases parts of the name may be
another nominal element such as an adjective (United Airlines).
In general, names are annotated in a flat, head-initial structure, in
which all words in the name modify the first one using the flat
label.
Carl XVI Gustaf
name(Carl-1, Gustaf-3)
name(Carl-1, XVI-2)
For organization names with clear syntactic modification structure, the dependencies should reflect the syntactic modification structure using regular syntactic relation, as in:.
Natural Resources Conservation Service
amod(Resources-2, Natural-1)
compound(Conservation-3, Resources-2)
compound(Service-4, Conservation-3)
In addition, regular syntactic relations are used: (i) for a modifying English determiner or (ii) to connect together the words of a description or name which involve English embedded prepositional phrases, sentences, etc.
The king of Sweden
det(king-2, The-1)
nmod(king-2, Sweden-4)
case(Sweden-4, of-3)
If a name contains a function word in another language than English, we also use the flat
relation.
Río de la Plata
name(Río-1, de-2)
name(Río-1, la-3)
name(Río-1, Plata-4)
Ludwig van Beethoven
name(Ludwig, van)
name(Ludwig, Beethoven)
Miguel de Cervantes y Saavedra
name(Miguel, de)
name(Miguel, Cervantes)
name(Miguel, y)
name(Miguel, Saavedra)
San Francisco
name(San, Francisco)
Treebank Statistics (UD_English)
This relation is universal.
There are 1 language-specific subtypes of flat
: flat:foreign.
1645 nodes (1%) are attached to their parents as flat
.
1645 instances of flat
(100%) are left-to-right (parent precedes child).
Average distance between parent and child is 1.24376899696049.
   PUNCT . _ 3 punct _ _
Treebank Statistics (UD_English-LinES)
This relation is universal.
482 nodes (1%) are attached to their parents as flat
.
482 instances of flat
(100%) are left-to-right (parent precedes child).
Average distance between parent and child is 1.13070539419087.

There are 2 language-specific subtypes of flat
: flat:foreign, flat:name.
92 nodes (0%) are attached to their parents as flat
.
92 instances of flat
(100%) are left-to-right (parent precedes child).
Average distance between parent and child is 1.35869565217391.
   PUNCT FS _ 7 punct _ _
flat in other languages: [u]


Registration
Unity does not require Type
to be registered to resolve it.
Any concrete, constructable Type
could be resolved by Unity without any prior preparation. It will even create and supply parameters if required. In other words, if you can create a Type
with new
operator:
var value = new SomeClass(new SomeOtherClass());
you can resolve it from Unity:
var value = container.Resolve<SomeClass>();
Minimum Registration Requirements
A lot of times, if type does not require any custom steps, it is faster to resolve Type
from the container if it is not registered. You should only register a Type
if one of the following is required:
- Lifetime policy other than transient
- Nondefault constructor should be selected
- Properties or fields not marked with appropriate attributes should be injected
- Method should be called during initialization on the created object
- Mapping between service and implementation types
What is a Registration and how it works
Registration is how you control Unity to do it 'Your' way. When you register a Type
, you are instructing Unity to create and initialize an instance of that Type
in a very particular way. You also instruct Unity how to deal with the crated instance during its lifetime.
Once registration is complete, Unity creates a blueprint of the type factory where it stores implementation details (name, to and from types, etc.), information about what members to inject and how, and lifetime manager responsible for managing the instance.
At the later time, when that Type
is requested, Unity uses this blueprint to create a pipeline (resolver delegate) to be used to create type.
Each Unity container exposes a collection of available registrations presented as an enumeration of IContainerRegistration objects. This collection could be used to filter and select certain registrations as well as to check if the Type
is registered and how.
Different types of registrations
Unity recognizes three different scenarios of how instances and types are created and based on these allows three different types of registrations:
Instances created outside of Unity
A lot of times parts of system's infrastructure require to be available to clients and services of the application. These entities are created and managed outside of the Unity but should be accessible by consumers of the framework during resolution. To enable access to these objects Unity provides a way to register instances. For more information see Instance Registration.
Instances created by Unity using provided Type Factory
Although Unity is quite capable in creating instances of types, sometimes it is more efficient or desireable to use Type
factories. Unity provides API to register a special factory delegate. For more information see Factory Registration
Instances created by Unity
This is the most common scenario where objects are created by the container itself. Creation process is controlled by either Type
registrations associated with the container or implicit Unity defaults if none registered. For more information how Type
can be registered seeType Registration
Container Hierarchies
Unity container provides a way to create child containers (also referred as creating scopes) and allows building sophisticated hierarchical trees of registrations. There are just a few simple rules to follow when dealing with container hierarchies. For more information see Container Hierarchy


---
layout: post
title: 'Exchange: MonitoringLogs: Failed to write logs because of the error: Access
to the path.....'
categories:
- Exchange
tags: []
status: publish
type: post
published: true
meta:
_edit_last: '1'
_wpas_done_all: '1'
sharing_disabled: '1'
---
Error
- Log Name: Application
- Source: MSExchange Common
- Event ID: 6004
- Task Category: Logging
- Level: Error
- Keywords: Classic
- User: N/A
- Description:
- MonitoringLogs: Failed to write logs because of the error: Access to the path 'Monitoring20130626-1.LOG' is denied..
Resolution
- Check Permission
- Check free Hard Disk Space
- Rename the File


Ride for Life started with only the founders of the app and 2 drivers! We have since expanded into a full 24/7, 100+ team.
We have made sure that no matter what size our organization is, we keep connections to our community by giving back via donations and other services.
Our team has been thorougly trained to be able to provide the safest, best transportation service for mothers in need.
Are you a mother in need of assistance but are struggling with income? Please contact our office to set up an arrangement with Drive for Life.
Our first priority is to make sure all our residents get the care they need. Please do not hesitate to ask for help!
Not only do our drivers help save lives, but they also help with community services in their free time!
We do everything from Habitat for Humanity, food drives, to community cleanups. If you have a suggestion, please get in contact with us!


Module TexturePack
The TexturePack
class specifies a texture pack (or texture atlas).
A texture atlas is a large image which contains many smaller sub-images. Gideros supports dynamic creation of texture atlases and pre-packed texture atlasses by using "Gideros Texture Packer" tool.
Dynamic Creation of Texture Packs
To create a texture pack dynamically (at run-time), create TexturePack
object with a table of file names of textures.
local pack = TexturePack.new({"1.png", "2.png", "3.png", "4.png")}
Static Creation of Texture Packs
To create a pre-packed texture atlas, use "Gideros Texture Packer" tool:
This tool exports two files: A .txt file that specifes the positions of texture regions and a .png file of packed texture. Use these two files to create texture pack:
local pack = TexturePack.new("pack.txt", "pack.png")
Type TexturePack
| TexturePack:getHeight() |
Returns the height of the texture in pixels. |
| TexturePack:getTextureRegion(texturename) |
Returns the texture region of texture pack. |
| TexturePack:getWidth() |
Returns the width of the texture in pixels. |
| TexturePack.new(txtfile, imagefile, filtering, options) |
Creates a new |
Type TexturePack
Field(s)
- TexturePack:getHeight()
-
Returns the height of the texture in pixels.
Return value
The height of the texture in pixels.
- TexturePack:getTextureRegion(texturename)
-
Returns the texture region of texture pack.
Parameter
-
texturename
: (string)
Return value
TextureRegion
object that specifies the region within the texture pack. -
- TexturePack:getWidth()
-
Returns the width of the texture in pixels.
Return value
The width of the texture in pixels.
- TexturePack.new(txtfile, imagefile, filtering, options)
-
Creates a new
TexturePack
object.This function loads the pre-packed texture atlas created by "Gideros Texture Packer" tool.
Parameters
-
txtfile
: (string) -
imagefile
: (string) -
filtering
: (boolean, default = false) Whether or not the texture is filtered. -
options
: (table, optional) A table that specifies optional paramaters. Currently "transparentColor" field is supported.
Return value
-


Package Setup Assistant
The Package Setup Assistant is a different interface for package creation. It is accessible from the new file panel (File > New), “Assist Me…” button. It is capable of creating packages, metapackages, or distribution based on what settings are specified and what items are specified for the payload.
The assistant is intended to allow for quick and easy package creation with intelligent defaults. If you need different custom settings, simply open the output .pkg or .mpkg in PackageMaker.
The assistant will walk you through the package creation process in the following steps:
- Welcome: Prompts for basic package information.
More Info… - Contents: Prompts for the items to install.
More Info… - Bundle Identifiers: Displays what packages will be created and prompts for bundle identifiers and versions.
More Info… - Metadata: Prompts for package metadata. Not displayed when creating a distribution.
More Info… - Resources: Prompts for resources (e.g. license, readme, etc.)
More Info… - Package Creation: Will create all packages and bundle them in a metapackage or distribution if necessary.
More Info…


Woodchase Estates
News
Amenities
Social Media
Resources
Contact
HOA
Woodchase HOA
Documents
New Neighbors
Report Incident
Pay HOA Dues
Volunteer
Resources
Woodchase Estates
Resources
Online Resources
Emergency Services
Police Department
Sheriff’s Department
Fire & Rescue
EMS / Ambulance
Animal Control
Public Services
Report Street Light Repair
Report Trash NOT picked up
Find your property lines
Provide City-Parish Employee Feedback
My Government Services
Maps & GIS Resources
Open Data BR
Open Neighborhood BR
Louisiana Sex Offender Database
Flood Zone Map
Baton Rouge Assesors
Geaux Vote
Utility
Water/Trash (BR Water Co.)
Electric (Entergy)
Natural Gas (Entergy)
Natural Gas (DEMCO)
Baton Rouge Airport
Public Library
Post Office
Local Area Information
BR Proud
Best of 225
Best of Baton Rouge
NOLA.com
Baton Rouge Zoo
River Center Theater Tickets
Helpful Phone Numbers
Emergency Services
BR Police Dept.:<PHONE_NUMBER>
East BR Sheriff’s Dept.:<PHONE_NUMBER>
Fire & Rescue: 911
EMS / Ambulance: 911
Animal Control:<PHONE_NUMBER>
Utility & Public Services
Water/Trash (BR Water):<PHONE_NUMBER>
Electric Power (Entergy):<PHONE_NUMBER>
Natural Gas (Entergy):<PHONE_NUMBER>
Natural Gas (DEMCO):<PHONE_NUMBER>
Baton Rouge Airport:<PHONE_NUMBER>
Public Library:<PHONE_NUMBER>
Post Office:<PHONE_NUMBER>
Voting
Voter Registration:<PHONE_NUMBER>
Neighborhood Referrals
Please notify us of a referrals of previous work done so we can post it(good or bad). Also, please let us know about the service price and work. Ex.high/normal/cheap
HOA Documents
HOA Subdivision Restriction
Building Guidelines
Plat
Resident List
LSU Sports
LSU Football Schedule
LSU Baseball Schedule
TigerDroppings
LSU TAF
Dandy Don


Parse a URL with memoization.
This is a Node.js module available through the
npm registry. Installation is done using the
npm install
command:
sh
$ npm install parseurl
js
var parseurl = require('parseurl')
Parse the URL of the given request object (looks at the req.url
property)
and return the result. The result is the same as url.parse
in Node.js core.
Calling this function multiple times on the same req
where req.url
does
not change will return a cached parsed object, rather than parsing again.
Parse the original URL of the given request object and return the result.
This works by trying to parse req.originalUrl
if it is a string, otherwise
parses req.url
. The result is the same as url.parse
in Node.js core.
Calling this function multiple times on the same req
where req.originalUrl
does not change will return a cached parsed object, rather than parsing again.
```bash $ npm run-script bench
<EMAIL_ADDRESS>bench nodejs-parseurl node benchmark/index.js
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>modules@46 <EMAIL_ADDRESS>node benchmark/fullurl.js
Parsing URL “http://localhost:8888/foo/bar?user=tj&pet=fluffy”
3 tests completed.
fasturl x 1,246,766 ops/sec ±0.74% (188 runs sampled) nativeurl x 91,536 ops/sec ±0.54% (189 runs sampled) parseurl x 90,645 ops/sec ±0.38% (189 runs sampled)
node benchmark/pathquery.js
Parsing URL “/foo/bar?user=tj&pet=fluffy”
3 tests completed.
fasturl x 2,077,650 ops/sec ±0.69% (186 runs sampled) nativeurl x 638,669 ops/sec ±0.67% (189 runs sampled) parseurl x 2,431,842 ops/sec ±0.71% (189 runs sampled)
node benchmark/samerequest.js
Parsing URL “/foo/bar?user=tj&pet=fluffy” on same request object
3 tests completed.
fasturl x 2,135,391 ops/sec ±0.69% (188 runs sampled) nativeurl x 672,809 ops/sec ±3.83% (186 runs sampled) parseurl x 11,604,947 ops/sec ±0.70% (189 runs sampled)
node benchmark/simplepath.js
Parsing URL “/foo/bar”
3 tests completed.
fasturl x 4,961,391 ops/sec ±0.97% (186 runs sampled) nativeurl x 914,931 ops/sec ±0.83% (186 runs sampled) parseurl x 7,559,196 ops/sec ±0.66% (188 runs sampled)
node benchmark/slash.js
Parsing URL “/”
3 tests completed.
fasturl x 4,053,379 ops/sec ±0.91% (187 runs sampled) nativeurl x 963,999 ops/sec ±0.58% (189 runs sampled) parseurl x 11,516,143 ops/sec ±0.58% (188 runs sampled) ```


With this quiz, you'll be able to find out what D&D class best fits you.
 You studied magic for years to get where you are today. You can blast foes with fire, zap enemies with lightning, and much much more!
  You can turn into animals and communicate with them, or talk to the plants around you. You protect mother nature when no one else will!

 You were born with magic and can use it with little to no training. You're powerful skills will help you out in any situation!
Sorry! Something appears to have gone wrong! Please answer all the questions before submitting.


§490:2-308 Absence of specified place for delivery. Unless otherwise agreed:
(a) The place for delivery of goods is the seller's place of business or if he has none his residence; but
(b) In a contract for sale of identified goods which to the knowledge of the parties at the time of contracting are in some other place, that place is the place for their delivery; and
(c) Documents of title may be delivered through customary banking channels. [L 1965, c 208, §2-308; HRS §490:2-308]


# Summary
Siofra is a tool designed to identify and exploit DLL hijacking vulnerabilities
in Windows programs. It is able to simulate the Windows loader in order to give
visibility into all of the dependencies (and corresponding vulnerabilities) of
a PE on disk, or alternatively an image file in memory corresponding to an active
process. More significantly, the tool has the ability to easily generate DLLs to
exploit these types of vulnerabilities via PE infection with dynamic shellcode creation.
These infected DLLs retain the code (DllMain, exported functions) as well as the
resources of a DLL to seamlessly preserve the functionality of the application loading
them, while at the same time allowing the researcher to specify an executable payload
to be either run as a separate process or loaded into the target as a module. Additionally,
the tool contains automated methods of combining UAC auto-elevation criteria with
the aforementioned functionality in order to scan for UAC bypass vulnerabilities.
# Vulnerabilities
At present, there is a very large number of vulnerabilities which this tool exposes.
While testing this tool I encountered only several applications which were not vulnerable
out of hundreds which I tested against. Note that these vulnerabilities can be exploited
despite SafeDllSearchMode. A common misconception results from confusing the "current
directory" (fixed with SafeDllSearchMode) with the "application directory" (the
folder containing the .exe itself). The vast majority of DLL hijacking vulnerabilities
currently present in Windows programs stem from the application directory (which
comes first in the Windows search order). Several highlights are listed below in
the output produced by the scanner in the tool. The last time these vulnerabilities
were tested was in mid-July 2017.
* Application name: Internet Explorer
* Tested on OS: Windows 10 x64 Home/Pro
* Command/output:
Siofra64.exe --mode file-scan -f "c:\Program Files\Internet Explorer\iexplore.exe"
--enum-dependency --dll-hijack
======== c:\Program Files\Internet Explorer\iexplore.exe [64-bit PE] ========
iexplore.exe
USER32.dll [KnownDLL]
win32u.dll [Base]
api-ms-win-core-privateprofile-l1-1-1.dll [API set]
kernel32.dll [KnownDLL]
GDI32.dll [KnownDLL]
api-ms-win-gdi-internal-uap-l1-1-0.dll [API set]
gdi32full.dll [Base]
msvcp_win.dll [Base]
api-ms-win-crt-string-l1-1-0.dll [API set]
ucrtbase.dll [Base]
msvcrt.dll [KnownDLL]
api-ms-win-downlevel-shell32-l1-1-0.dll [API set]
shcore.dll [KnownDLL]
RPCRT4.dll [KnownDLL]
combase.dll [KnownDLL]
bcryptPrimitives.dll [Base]
ADVAPI32.dll [KnownDLL]
api-ms-win-eventing-controller-l1-1-0.dll [API set]
sechost.dll [KnownDLL]
iertutil.dll [!]
[!] Module iertutil.dll vulnerable at c:\Program Files\Internet Explorer\iertutil.dll
(real path: C:\WINDOWS\system32\iertutil.dll)
* Application name: Windows Defender
* Tested on OS: Windows 10 x64 Home/Pro
* Command/output:
Siofra64.exe --mode file-scan -f "c:\Program Files\Windows Defender\MpCmdRun.exe"
--enum-dependency --dll-hijack
======== c:\Program Files\Windows Defender\MpCmdRun.exe [64-bit PE] ========
MpCmdRun.exe
msvcrt.dll [KnownDLL]
KERNEL32.dll [KnownDLL]
OLEAUT32.dll [KnownDLL]
msvcp_win.dll [Base]
api-ms-win-crt-string-l1-1-0.dll [API set]
ucrtbase.dll [Base]
combase.dll [KnownDLL]
RPCRT4.dll [KnownDLL]
bcryptPrimitives.dll [Base]
ADVAPI32.dll [KnownDLL]
api-ms-win-eventing-controller-l1-1-0.dll [API set]
sechost.dll [KnownDLL]
OLE32.dll [KnownDLL]
GDI32.dll [KnownDLL]
api-ms-win-gdi-internal-uap-l1-1-0.dll [API set]
gdi32full.dll [Base]
USER32.dll [KnownDLL]
win32u.dll [Base]
SspiCli.dll [!]
mpclient.dll [!]
CRYPT32.dll [Base]
MSASN1.dll [Base]
WINTRUST.dll [Base]
[!] Module SspiCli.dll vulnerable at c:\Program Files\Windows Defender\SspiCli.dll
(real path: C:\WINDOWS\system32\SspiCli.dll)
* Application name: WMI
* Tested on OS: Windows 10 x64 Home/Pro
* Command/output:
Siofra64.exe --mode file-scan -f "c:\WINDOWS\System32\wbem\wmiprvse.exe" --enum-dependency
--dll-hijack
======== c:\WINDOWS\System32\wbem\wmiprvse.exe [64-bit PE] ========
wmiprvse.exe
msvcrt.dll [KnownDLL]
FastProx.dll [!]
wbemcomn.dll [!]
bcrypt.dll [!]
WS2_32.dll [KnownDLL]
api-ms-win-eventing-obsolete-l1-1-0.dll [API set]
sechost.dll [KnownDLL]
RPCRT4.dll [KnownDLL]
api-ms-win-core-heap-obsolete-l1-1-0.dll [API set]
kernel32.dll [KnownDLL]
NCObjAPI.DLL [!]
[!] Module wbemcomn.dll vulnerable at c:\WINDOWS\System32\wbem\wbemcomn.dll (real
path: C:\WINDOWS\system32\wbemcomn.dll)
[!] Module bcrypt.dll vulnerable at c:\WINDOWS\System32\wbem\bcrypt.dll (real path:
C:\WINDOWS\system32\bcrypt.dll)
[!] Module NCObjAPI.DLL vulnerable at c:\WINDOWS\System32\wbem\NCObjAPI.DLL (real
path: C:\WINDOWS\system32\NCObjAPI.DLL)
* Application name: Windows Search Indexer/Search Protocol Host
* Tested on OS: Windows 10 x64 Home/Pro
* Command/output:
Siofra64.exe --mode file-scan -f "c:\WINDOWS\System32\SearchProtocolHost.exe" --enum-dependency
--dll-hijack --explicit-loadlibrary
======== c:\WINDOWS\System32\SearchProtocolHost.exe [64-bit PE] ========
SearchProtocolHost.exe
msvcrt.dll [KnownDLL]
TQUERY.DLL [!]
OLEAUT32.dll [KnownDLL]
msvcp_win.dll [Base]
api-ms-win-crt-string-l1-1-0.dll [API set]
ucrtbase.dll [Base]
combase.dll [KnownDLL]
RPCRT4.dll [KnownDLL]
api-ms-win-core-heap-obsolete-l1-1-0.dll [API set]
kernel32.dll [KnownDLL]
bcryptPrimitives.dll [Base]
cryptdll.dll [!]
api-ms-win-security-lsalookup-l2-1-1.dll [API set]
advapi32.dll [KnownDLL]
api-ms-win-eventing-controller-l1-1-0.dll [API set]
sechost.dll [KnownDLL]
api-ms-win-shell-namespace-l1-1-0.dll [API set]
windows.storage.dll [Base]
api-ms-win-shlwapi-winrt-storage-l1-1-1.dll [API set]
shlwapi.dll [KnownDLL]
GDI32.dll [KnownDLL]
api-ms-win-gdi-internal-uap-l1-1-0.dll [API set]
gdi32full.dll [Base]
USER32.dll [KnownDLL]
win32u.dll [Base]
api-ms-win-appmodel-state-l1-2-0.dll [API set]
kernel.appcore.dll [Base]
api-ms-win-shcore-path-l1-1-0.dll [API set]
shcore.dll [KnownDLL]
api-ms-win-power-base-l1-1-0.dll [API set]
powrprof.dll [Base]
profapi.dll [Base]
msfte.dll [Potential explicit Unicode] [!]
msTracer.dll [Potential explicit Unicode] [!]
Msidle.dll [Potential explicit Unicode] [!]
winhttp.dll [Potential explicit Unicode] [!]
[!] Module msfte.dll vulnerable at C:\WINDOWS\system32\msfte.dll (real path: Unknown)
[!] Module msTracer.dll vulnerable at C:\WINDOWS\system32\msTracer.dll (real path:
Unknown)
# Capabilities
The capabilities of this tool can be split into 3 separate categories, each corresponding
to one of the execution modes of this tool.
## Infection mode
When in infection mode, the tool is capable of generating infected copies of both
32 and 64-bit DLL files. These infected files are able to hijack the execution flow
of a target application when they are loaded during process initialization, causing
either a payload DLL to be loaded or a payload executable to be launched prior to
the execution of the target application entry point.
## File scanning mode
When in file scanning mode, the tool may be given either an executable file path
or a folder (which will be searched for executable files, optionally with recursion)
which will recursively have its PE imports, delay load imports, API sets, assembly
dependencies, and explicitly loaded libraries enumerated and processed to determine
the path at which each will be loaded during runtime process initialization. With
this information, the tool is able to identify modules which are vulnerable to hijacking.
During PE processing and loader simulation, the tool is capable of handling:
1. Modules imported using the primary PE imports section.
2. Modules imported via delay load.
3. WinSxS assembly dependency resolution (the PE manifest resource is parsed, assembly
dependency IDs are extracted, and the WinSxS module path is identified using
a custom implementation).
4. Explicitly loaded modules, imported via LoadLibrary at runtime.
5. API set resolution of all of the above import types. This is achieved via a
custom implementation of a parser for the undocumented data structures found in
ApiSetSchema.dll (note that only versions 2, 4 and 6 have been tested).
6. Searching for specific imported modules by name.
7. Identifying Windows components which can be leveraged for UAC bypass attacks
(the UAC auto-elevation criteria are applied to a specified target PE in an
automated way, then used in conjunction with a hijacking attack if one is present).
8. Automatically detect and filter module dependencies which are not
vulnerable on the basis of:
* KnownDLLs
* Exempt ("Base") DLL status. Kernelbase.dll, ntdll.dll, etc.
* Manifest override security mechanism (used by Microsoft in sysprep.exe)
## Memory scanning mode
When in memory scanning mode, the tool can either enumerate local process names/IDs
or it can be given a process ID to scan. Rather than parsing the image file corresponding
to the given PID on disk, the tool will enumerate the modules currently loaded into
the process and identify which of them may be vulnerable to hijacking. This is useful
in instances where an executable on disk is packed/obfuscated and its imports cannot
be identified through parsing the PE header.
# Usage
In order to display the tool usage information, simply run it with no parameters
(output shown below). It is very important to use the appropriate compilation of
the tool (32 or 64-bit) for the desired target depending upon whether it is a 32-bit PE
or 64-bit PE file. Similarly, the 32-bit version of the tool can only enumerate and/or
target 32-bit processes (Wow64 on an x64 OS) and the 64-bit version can only enumerate
and/or target 64-bit processes. This principle applies both to scanning (Siofra64.exe
will skip 32-bit PE and Siofra32.exe will skip 64-bit PE) and to PE infection. Siofra32.exe
should be used to infect 32-bit DLLs and Siofra64.exe should be used to infect 64-bit
DLLs.
When the 32-bit version of the tool is run on x64 systems Wow64 path redirection
is explicitly disabled by the tool, which means that if you were to target \Windows\System32\notepad.exe
it would be a 64-bit PE (and therefore \Windows\Syswow64\notepad.exe should be used instead).
Similarly if you were to target \Program Files\Common Files\microsoft shared\MSInfo\msinfo32.exe
it would be a 64-bit PE, and therefore \Program Files (x86)\Common Files\microsoft shared\MSInfo\msinfo32.exe
should be used instead.
Siofra version 1.13 usage: Siofra32.exe --mode [Supported modes: "file-scan", "mem-scan"
and "infect"] -v [Optional. Output verbosity level]
Verbosity levels:
0 - No output
1 - Only critical success/failure status (default)
2 - Additional status details for success/failure status, including discarded PEs
3 - Everything
File scan mode:
-f [File or directory to scan]
-r [Optional. Recursive scan]
--signed [Optional. Process only signed binaries]
--delayload [Optional. Include delayload imports in dependency list]
--explicit-loadlibrary [Optional. Include potentially explicit imports in
dependency list (these are *.dll strings which may have been called via LoadLibrary(Ex)A/W]
--auto-elevate [Optional. Scan only auto-elevate binaries]
Memory scan mode:
--pid [Target process ID to scan. When not specified, a list of either 32
or 64-bit process names/PIDs will be enumerated (corresponding to either the 32
or 64-bit version of this tool)]
Any scan mode:
--enum-dependency [Enumerate dependencies]
--show-unmapped-apiset [Optional. Include API sets which failed to map to
a module from output (ignored by default)]
--dll-hijack [Enumerate DLL hijacking vulns]
--find-module [Optional. Scan dependencies for a specific module. Note that
this excludes KnownDLLs]
Infect mode:
-f [DLL file to infect]
-o [Output file]
--payload-path [Path of DLL to be loaded into infected DLL at runtime,
or path of executable to be launched at runtime]
--payload-type [The type of payload specified in the parasite payload path.
This can be "process" (generally indicating a exe) or "library" (generally indicating
a DLL)]
## Examples
1. Scanning the entire home drive for 32-bit programs vulnerable to DLL hijacking
using either standard or delay load imports through their PE headers.
Siofra32.exe --mode file-scan -f "C:/" -r --enum-dependency --dll-hijack --delayload
2. Scanning the Windows Defender application folder on an x64 version of Windows
for vulnerable modules loaded through the standard import table in their PE header.
Siofra64.exe --mode file-scan -f "C:\Program Files\Windows Defender" -r --enum-dependency
--dll-hijack
3. Scanning the 32-bit Java Update Scheduler program on an x64 version of Windows
for vulnerable modules loaded through any known channel (standard or delayload imports,
WinSxS, LoadLibrary).
Siofra32.exe --mode file-scan -f "C:\Program Files (x86)\Common Files\Java\Java
Update\jusched.exe" --enum-dependency --dll-hijack --delayload --explicit-loadlibrary
4. Scanning the Windows folder (and all its subfolders) for vulnerable modules
(imported via the standard imports table in the PE header) in 64-bit programs which
could be used for a UAC bypass attack (signed by Microsoft with an auto-elevate
manifest).
Siofra64.exe --mode file-scan -f "C:\Windows" -r --enum-dependency --dll-hijack
--auto-elevate --signed
5. Infecting a 32-bit copy of WININET.dll (copied from \Windows\SysWOW64\WININET.dll
to .\WININET_original.dll) with an implant which will launch a new notepad process
when loaded during process initialization by a vulnerable program. It's important
to note that simply loading an infected copy of this DLL (via LoadLibrary for example)
will not trigger the payload. Infected DLLs are only meant to work in the context
of a vulnerable module loaded via the standard imports section of its host process.
Siofra32.exe --mode infect -f WININET_original.dll -o WININET.dll --payload-type
process --payload-path c:\windows\system32\notepad.exe
6. Infecting a 64-bit copy of USERENV.dll (copied from \Windows\System32\USERENV.dll
to .\USERENV_original.dll) with an implant which will load a hypothetical payload
DLL stored at C:\Payload.dll. It's important to note that all DLLs loaded by a 64-bit
process must be 64-bit DLLs, and all DLLs loaded by a 32-bit process must be 32-bit
DLLs. Therefore in this hypothetical scenario, Payload.dll would need to be a 64-bit PE
file for it to be loaded successfully by the implant in USERENV.dll.
Siofra64.exe --mode infect -f USERENV_original.dll -o USERENV.dll --payload-type
library --payload-path "C:\Payload.dll"
# Future improvements
* 32 and 64-bit versions of the tool to be combined into a single executable.
* Capability to perform PE infections which can successfully load DLL/executable
payloads within infected DLL files loaded explicitly via LoadLibrary or through
delayed imports.
* Support for all API set versions.
# Source code
I've decided to make some of this tool open source to help other security
researchers understand the technical details of this project. Specifically I've
provided assembler source code for one of the 64-bit implant shellcodes (for 64-bit PE
DLL infection when specifying a "process" payload type).
Details surrounding other technical aspects of the tool and OS details related
to the Windows loader/search order, UAC, WinSxS etc. can be found within the
PDF for this project.
# License
Siofra is licensed under the GPL 3 license. See LICENSE.MD for details.
# Contact
Forrest Williams -<EMAIL_ADDRESS>/ forrest.williams@cybereason.com


Terms of Service
By accessing the website, you are agreeing to be bound by these terms of service, all applicable laws and regulations, and agree that you are responsible for compliance with any applicable local laws. If you do not agree with any of these terms, you are prohibited from using or accessing this site. The materials contained in this website are protected by applicable copyright and trademark law.
- Any error, omission, interruption, deletion, defect, delay, communications failure, theft or destruction or unauthorized access to, or alteration of, user or Member postings or communications.
- The accuracy, integrity, completeness, or quality of any information, outputs or Content available from or through the Site; rather, responsibility for verification resides with the user of the information, output or Content.
- Problems with telephone lines, computer systems, third party providers, or any technical problems or traffic congestion on the Internet or any website;
- Injury or damage to users’, members’ or other persons’ computers or networks resulting from participating or downloading materials in connection with the Site;
The materials appearing on this website could include technical, typographical, or photographic errors. We do not warrant that any of the materials on its website are accurate, complete or current. We may make changes to the materials contained on its website at any time without notice. However we do not make any commitment to update the materials.
These terms of service are subject to change at any time without notice. By using this website you are agreeing to be bound by the then current version of these terms of service.