XLS Pipeline scheduling
Pipeline scheduling divides the IR nodes of an XLS function or proc into a sequence of stages constituting a feed-forward pipeline. Sequential stages are separated by registers enabling pipeline parallelism. The schedule must satisfy dependency constraints between XLS nodes as well as timing constraints imposed by the target clock frequency. Pipeline scheduling has multiple competing optimization objectives: minimize number of stages (minimize pipeline latency), minimize maximum delay of any stage (maximize clock frequency), and minimize the number of pipeline registers.
Scheduling process
Pipeline scheduling occurs in two phases:
-
Determine the effective clock period. This clock period defines the maximum delay, based on XLS's internal delay model, through any pipeline stage and limits how many IR operations might be placed in each stage.
-
Given the constraints of the effective clock period and, optionally, a user-defined number of pipeline stages, find the schedule which minimizes the number of pipeline registers. Pipeline registers are required for any IR operation whose value which is used in a later stage.
The schedule process is controlled via several options defined
here.
These options are typically passed in as flags to the
codegen_main
binary
but maybe set programmatically. Each is optional though at least one of clock
period or pipeline stages must be specified. Different combinations of
options result in different strategies as described below.
Clock period : The target clock period.
Pipeline stages : The number of stages in the pipeline.
Clock margin percent : The percentage to reduce the target clock period before scheduling. May only be specified with clock period. This option is equivalent to specifying a reduced value for clock period.
Clock period relaxation percent : This is the percentage that the computed minimum clock period, as determined by the number of pipeline stages, is increased (relaxed) prior to scheduling. May not be specified with clock period.
Step 1: determine the effective clock period
The effective clock period determines the maximum delay through any pipeline stage for the purpose of scheduling. The value is determined in one of two ways depending upon whether the clock period option is specified.
-
clock period specified
The effective clock period is set the clock period value. If clock margin percent is also specified, then the effective clock period is also reduced by the given percentage. Example: if clock period is 800ps and clock margin percent is 20% then the effective clock period is 640ps.
-
clock period not specified
In this case, pipeline stages must be specified. The effective clock period is computed as the minimum clock period in which a schedule may be found that meets timing with the specified number of pipeline stages. This is done via a binary search through clock period values, where at each step of the binary search the scheduler is run in its entirety. If clock period relaxation percent is specified then the computed effective clock period is increased by the given percentage. The motivation is that this relaxation may result in fewer pipeline registers because of increased scheduling flexibility. Example: if the minimum clock period found by XLS was 1000ps and clock period relaxation percent is 10% the effective clock period is 1100ps.
Step 2: schedule to minimize pipeline registers
Once an effective clock period is determined, XLS computes a schedule which minimizes the number of registers (see below for details) while satisfying various constraints, including the critical path delay constraints imposed by the effective clock period. The number of stages in the pipeline may be specified by the user via the pipeline stages option. If the number of pipeline stages specified is too small an error such that no feasible schedule can be found then an error is returned. If pipeline stages is not given then the minimum number of stages which meets the delay constraint imposed by the effective clock period is used.
Options for common scheduling objectives
Different scheduling options result in different optimization strategies for the scheduler. Below are several common scheduling objectives and options which should be set to enable them.
-
Minimize the number of pipeline registers for a given clock period and given number of pipeline stages.
Specify both clock period and pipeline stages. The scheduler will attempt to minimize the number of pipeline registers given those constraints. The option clock margin percent can be swept to search the local design space (or equivalently, sweep clock period)
-
Minimize the clock period for a given number of pipeline stages
Specify only pipeline stages. XLS will find a schedule with minimum clock period with a secondary objective of minimizing the number of pipeline registers. Sweeping clock period relaxation percent explores relaxing the timing constraint which may result in fewer pipeline registers.
-
Minimize the number of pipeline stages for a given clock period
Specify only clock period. XLS will find a schedule of the minimum number of stages with a secondary objective of minimizing the number of pipeline registers. The option clock margin percent can be swept to search the local design space (or equivalently, sweep clock period)
-
Minimize the number of pipeline registers for a given clock period
Specify only clock period and sweep pipeline stages. Pick the schedule which produces the minimum number of pipeline registers.
-
Sweep the entire scheduling space
The various options directly or indirectly control the two degrees of freedom within the scheduler: pipeline stages and clock period. Sweeping these two degrees of freedom is most easily done by sweeping pipeline stages and clock period relaxation percent. The advantage of sweeping clock period relaxation percent instead of clock period directly is that the percent relaxation can be a fixed range (e.g., 0 to 50%) for all designs and each value will produce a feasible schedule. If clock period is swept some combinations of pipeline stages* and clock period** values will result in an error returned because the design point is infeasible.
Minimizing pipeline registers via SDC scheduling
For scheduling pipelines, XLS uses a variation on the approach described in SDC-Based Modulo Scheduling for Pipeline Synthesis. The basic principle is to create a set of real-valued variables, each corresponding to the cycle in which a node is scheduled or the lifetime1 of a node, and then carefully constrain the variables using linear inequality constraints such that minimizing a linear objective always gives an answer with integer values for all the variables. This avoids the need for integer linear programming, which is NP complete, and instead can be solved with linear programming, which is polynomial time in theory and takes roughly cubic time in practice.
Prior to the implementation of the SDC scheduler, we used a scheduler based on taking the min-cut of the node graph with Ford-Fulkerson. However, this design proved difficult to extend with needed features like IO constraints, and unlike the SDC algorithm was not optimal in the particular, narrow, sense that it assigns nodes to cycles such that the required register bits are minimized. We found that switching from the min-cut algorithm to SDC resulted in marginal improvements to benchmarks and increased compile times by an small and acceptable amount.
Constraints
Currently, we generate a variety of constraints:
- Causality constraints, i.e.: if node Y uses the output of node X, then the cycle of node X must be less than or equal to the cycle of node Y.
- Timing constraints, i.e.: if the critical path between node X and node Y is greater than the clock period, then the cycle of Y must be strictly greater than the cycle of X.
- IO constraints among sends and receives on a given channel (see the codegen documentation for more details).
- "Node in cycle" constraints, which allow forcing a given node to be scheduled in a given cycle. This is useful for incremental scheduling in the scheduling pass pipeline.
- "Receives first, sends last" constraints, which allow accessing the old behavior in which receives all went into the first cycle and sends all went into the last cycle.
- Backedge constraints: when the initiation interval is 1, a state parameter and its corresponding next state must be scheduled in the same cycle. More generally, we build up a graph of states where there is an edge between two states if the output of one affects the input of another, and then compute the strongly connected components of this graph. All nodes within a strongly connected component must be in the same cycle.
Additional technical details
The linear inequality constraints can be summarized by a matrix M and a vector y such that Mx ≤ y. If the linear program has the property described above (that minimizing a linear objective gives an integer answer), then the matrix M is considered to be integral. One class of integral matrices is that of the "totally unimodular matrices". The exact definition of this class is out of scope to discuss here, but it suffices to say that it includes constraints of the following form:
- Difference constraints between variables with an integer bound:
x - y ≤ k
wherek
is an integer - Constraints of the form
x - y - z ≤ k
wherek
is an integer
In the SDC scheduler, we use x - y ≤ k
constraints to express causality and
timing constraints, whereas x - y - z ≤ k
constraints are used to constrain
the lifetime variables to be equal to the difference between the max user cycle
and the cycle of a given node.
-
The lifetime of a node is the interval starting at the cycle number assigned to the node and ending at the maximum cycle number of the users of the node. ↩


everything you type is published to the /chat channel, unless you type: /whisper <username> <message>


Initializes search fields when user opens advanced search overlay.
initSearches()
Returns undefined.
Description
This method is called internally after advanced search overlay has been displayed and it will set initial values in the search
fields. This is an internal method, but it can be overwritten.


Fight of the Day: Mike Bernardo vs. Peter Aerts
by Luke Irwin
Date: October 18, 1996
Card: K-1 Star Wars ’96
Championship(s):
Venue: Yokohama Hall
Location: Yokohama, Japan
Date: October 18, 1996
Card: K-1 Star Wars ’96
Championship(s):
Venue: Yokohama Hall
Location: Yokohama, Japan


Exporting symbols from C++ to Lua API
Cuberite has a powerful plugin system which makes available hundreds of functions, variables and constants (symbols). When adding or removing functionality, these need to be taken into account - do we want to make this function available to the plugins? Did we remove a function that plugins could have used in the past?
The API maintenance is pretty straightforward once you figure out how to do it. This text will guide you through the process.
Introduction to ToLua++
Cuberite uses ToLua++ for handling bindings. Unfortunately this tool is no longer maintained, so we had to hack it ourselves whenever we needed a specific feature that it didn't support. Luckily, it turns out ToLua++ is greatly extensible and can quite easily be made to do our bidding.
This tool consists of a Lua script to parse C++ code and generate the glue code, and a runtime library providing support for the generated code. The C++ code parser doesn't implement full C++ syntax, just a reasonable subset that most if not all source files can be made to fit. Since it parses the C++ code using Lua patterns, it is only expected that some wild corner cases will confuse the parser. Therefore, all files that are to be processed by the parser need to be written in a simple subset of C++.
Once run, the tool generates a giant C++ source code file, src/Bindings/Bindings.cpp, which implements all the glue code needed for Lua plugins to interface with the C++ code.
Auto-export
The simplest way to export a symbol is to mark it for exporting and let ToLua++ do all the work. Basically, when ToLua++ parses files, it ignores everything that is not in between special comments, // tolua_begin and // tolua_end . There's a special comment, // tolua_export , that says "consider this single line". So adding new symbols in between existing tolua_begin / tolua_end comment pair, or marking them with tolua_export, is the simplest way to export them. However, since ToLua++ is limited, this works only for simple things: variables, constants and (overloaded) (member) functions, all of which must use only numbers, strings or enums or classes known to ToLua++. Note that this means that arrays, vectors, lists and callbacks are not supported by this simple export, all of those need to be exported manually. Based on experience, about 90 % of API functions can be exported this way.
The following piece of code shows how to export a class with some of its functions:
// tolua_begin class ExportedClass { public: // tolua_end ExportedClass(); // NOT exported void notExported(); void exported(int a_Param1); // tolua_export void anotherNotExported(); // tolua_begin void exported(int a_Param1, int a_Param2); // Note that overloads are supported void anotherExported(const AString & a_Text); }; // tolua_end
From this input, the ToLua++ sees the following "preprocessed" code, for which it will generate the bindings:
class ExportedClass { public: void exported(int a_Param1); void exported(int a_Param1, int a_Param2); void anotherExported(const AString & a_Text); };
Manual export
First, a quick primer on binding Lua in general. You can have a look at the Lua manual for details, since this is only a summary.
Lua uses a concept of stack. It keeps a stack through the lifetime of program, and calling a function means that under the hood the parameters are first pushed onto the stack, then the function implementation is called, it can read the values on the stack and it can push return values onto the same stack, and when it returns, Lua reads the return values from the top of that stack. This allows Lua to have functions that take a variable amount of parameters, return any number of values, and all of these parameters / values can be of any Lua-supported type. If you consider the datatype a "variant", it's good enough.
The signature for a function call, therefore, is simple - it takes an opaque pointer to a Lua engine (struct lua_State *), and it returns a single number that specifies how many return values there are on the stack. In C/C++ terms:
static int fnImplementation(lua_State * a_LuaState) { // ... // Push return values onto the stack return numReturnValues; }
Although it is referred to as The Stack, it can be manipulated in any way - a value can be read from any position, and it supports insertion to and deletion from any position.
A typical API function should do these actions:
- Check that parameter types are correct
- Read the parameter values
- Execute the C++ function
- Publish any return values
Cuberite wraps the lua_State pointer into a nice interface, cLuaState, that (among other things) provides easy functions for interfacing with Lua. Checking parameter types is done using the cLuaState::CheckParam...() family of functions. Each of these functions checks the type of the specified parameter / parameter range, returns true if the parameters are okay, or logs an error message to console and returns false if they aren't. Note that this is not usable for overloaded functions, they need to use tolua_is...() functions for checking.
Example code doing the parameter check:
static int tolua_cRoot_DoWithPlayerByUUID(lua_State * tolua_S) { // Function signature: cRoot:DoWithPlayerByUUID(cUUID, function) // Check params: cLuaState L(tolua_S); if ( !L.CheckParamSelf("cRoot") || !L.CheckParamUUID(2) || !L.CheckParamFunction(3) || !L.CheckParamEnd(4) ) { return 0; }
This code checks that the API function is called on a cRoot instance (first hidden parameter) and has a UUID and a callback function as its parameters. It also checks that there are no more parameters on the stack.
Reading the parameter values is rather simple: Declare variables to hold the parameter values, then use cLuaState::GetStackValues() to read them all at once. This function will return true if successful, false on an error. The return value should be checked even if parameter types were correct, because a failure can be due to other means as well - the number in Lua might be too large to fit the C++ datatype, or the enum value is out of range. Note that GetStackValues() doesn't report which parameter failed, so it should not be used for reporting problems to the user (plugin dev).
The following example is a continuation of the previous example function that reads the parameters into local variables:
// Get parameters: cRoot * Self; cUUID PlayerUUID; cLuaState::cRef FnRef; // Holds a Lua function (callback) L.GetStackValues(1, Self, PlayerUUID, FnRef); // Check parameters validity: if (PlayerUUID.IsNil()) { return L.ApiParamError("Expected a non-nil UUID for parameter #1"); } if (!FnRef.IsValid()) { return L.ApiParamError("Expected a valid callback function for parameter #2"); }
After executing the C++ function, if there are any return values, they should be pushed onto the Lua stack using the cLuaState::Push() function, and finally the returned number should indicate the number of return values. Note that it is up to you to keep the stack counts. If your code pushes more values onto the stack than it reports as return values, it will cause a memory leak.
The following example contains the rest of the previous example function, it executes the C++ code and gives the return value back to Lua:
// Call the function: bool res = Self->DoWithPlayerByUUID(PlayerUUID, [&](cPlayer & a_Player) { bool ret = false; L.Call(FnRef, &a_Player, cLuaState::Return, ret); return ret; } ); // Push the result as the return value: L.Push(res); return 1; }
The manual API function export glue should be written into one of src/Bindings/ManualBindings*.cpp files, based on the group it belongs to (or into src/Bindings/DeprecatedBindings.cpp if it is an obsolete function, see the Removing a symbol chapter). There are a lot of examples already in those files. Note that there was some development in the process of writing manual bindings, and some of the manual bindings use old code. Do not copy code that makes use of tolua_Error struct, or tolua_push...() or tolua_to...() functions.
Finally, after writing the API function, it needs to be registered ("bound" in our terminology). Each of the CPP files has a cManualBindings::Bind...() function at the bottom for this purpose. The function first registers classes (tolua_usertype(), tolua_cclass()) and then fills each class with manually-exported functions. A call to tolua_beginmodule() signifies start of class, tolua_endmodule() ends the class. In between, calls to tolua_function() register the API functions. It is good practice to keep the classes and the sybmols within classes alpha-sorted and tabulated.
The following code is an example of binding our previous example function:
tolua_beginmodule(tolua_S, "cRoot"); // ... tolua_function(tolua_S, "DoWithPlayerByUUID", tolua_cRoot_DoWithPlayerByUUID); // ... tolua_endmodule(tolua_S);
Cuberite conventions
Specifically for Cuberite, we've built some conventions over the years. They are in place for good reasons - to make the API well documented, somewhat stable and reasonably fool-proof
New symbols
When adding a new symbol to the API, there's no version number to bump up to indicate this. Plugins can simply check the symbol's existence in the runtime, if they wish to do so. However, it is necessary to properly document the symbol, so that the automatically-generated documentation stays up to date.
The API documentation is handled by the APIDump plugin, contained in the main repository in the Server/Plugins/APIDump folder. It can automatically generate the HTML API documentation locally, based on the actual API that it detects Cuberite is giving it, and joins it with developer-provided per-symbol descriptions. Most of the description is in the Server/Plugins/APIDump/APIDesc.lua file, but some well-defined groups of symbols have been pulled out into separate files in the Server/Plugins/APIDump/Classes folder and Server/Plugins/APIDump/Hooks folder. The format of the files is pretty self-explanatory - they each return a Lua table containing the descriptions, organized in sub-tables.
To generate the documentation locally, start up Cuberite, load the APIDump plugin (if not already enabled) and execute the "api" command. It will create an API subfolder next to the Cuberite executable and write the HTML files into it.
The APIDump plugin can also check the difference between official documentation and local documentation, and can report if any symbol is new locally, without proper description. Execute the "apicheck" command to do that; note that this requires "wget" to be installed, since the official API description needs to be downloaded from the Internet. This command is used as part of Cuberite CI builds to detect any forgotten API description.
Removing a symbol
To keep the API from changing too much under plugin devs' hands, the recommendation is not to remove API symbols, but rather mark them as obsolete, while keeping the functionality (possibly emulating it through a new API, if the old symbol was replaced with a new way of doing things). The preffered way is to export the old symbol mnually in a specific file, src/Bindings/DeprecatedBindings.cpp, and add a warning message to the function implementation, together with the Lua stacktrace, to aid plugin authors with the migration. It is always a good idea to add a hint as to what the developers should use instead ("Warning in function call 'StringToMobType': StringToMobType() is deprecated. Please use cMonster:StringToMobType()").
After a reasonable amount of time (typically, on the order of a year) the removed symbol can be considered unused and will be removed from the API. Usually this happens in batches as a cleanup of the codebase.
ZeroBrane Studio API description
The APIDump plugin also outputs API description for the ZeroBrane Studio IDE. It is written into the cuberite_api.lua file next to the Cuberite executable. See the Docs article about ZBS for details on how to use that file.
Plugin Checker
There is a CuberitePluginChecker project that aims to provide automatic testing to plugins. It uses the APIDump's descriptions to provide dummy implementations for all API functions. See the project page for details.


BELOVED Cast: Oprah Winfrey, Danny Glover, Thandie Newton, Kimberly Elise, Beah Richards, Lisa Gay Hamilton, Albert Hall, Irma P. Hall Director: Jonathan Demme Screenplay: Adam Brooks, Akosua Busia, Richard LaGravenese based on the novel by Toni Morrison Australian theatrical release: May 6, 1999 Reviewed by Luke Buckmaster
On the Buckmaster scale of 0 stars (bomb), to 5 stars (a masterpiece): 2 and a half stars
To its credit, Beloved is not a conventional period piece. In fact, there is really nothing ordinary in the themes that are explored in this film. Oprah Winfrey's labor of love that she nurtured for over a decade is a peculiar and often unsettling mixture of horror and drama. The film succeeds in crafting extraordinary characters and moments, but with an almost three-hour running time one might question the existence of an editor. It's difficult to put a finger on what director Jonathan Demme (Silence of the Lambs, Philadelphia) and the screenwriters are trying to tell us, not because it is something incredibly profound, but rather because there are too many subplots that detract from the story's meaning.
Sethe (Winfrey) is a runaway slave who has a simple existence with her daughter Denver (Kimberley Elise), in rural Ohio. The year is 1873, and an angry spirit haunts the house they live in. Sethe's past, we learn, contains disturbing memories of unforgettable sins, which seem to get progressively worse as the film plods along. The two are joined by Paul D (Danny Glover), a former slave who stays with Sethe and Denver in the hope of becoming a family. But a mysterious guest who goes by the name of Beloved (Thandie Newton) arrives on the scene. Where she came from, who she came with and why she is there is at first a mystery, but later things are revealed as the past once again comes up to bite Sethe.
Although adapted from Toni Morrison's Pulitzer Prize winning novel, Beloved doesn't seem very literate. There are moments in novels that cannot retain much of their power once a conversion to film has been made; that's just the way it is, I guess. As easily as a picture can tell a thousand words, words usually have greater meaning. The pictures that cinematographer Tak Fujimoto uses are very fine indeed, ranging from the ghostly looking old house (which was built especially for the film) to the grainy texture of the story's flashbacks. Where Beloved fails is sustaining power in its imagery; for all the disturbing images evoked, the script doesn't have the power to back them up. Illiterate is not the right word - inferior, perhaps, is.
That's not to say that Beloved was a mistake to make, since Jonathan Demme has a solid shot at getting it right. He squeezes strong performances from all of his cast, notably Oprah Winfrey and Danny Glover. Beloved's strange actions and manner of speaking no doubt demanded a lot of talent from Thandie Newton, but her character frustrated me for those reasons. I was patiently waiting for Beloved's emotional climax in which her actions would form a basis of understanding for her character, but that never came.
Demme also directs with a flair for the bizarre, which isn't surprising considering this is the man who turned the grim Silence of the Lambs into an Oscar winning success. Needless of how good the final product turned out to be, Beloved deserves respect as an artistic creation that ventures into the realms of the extraordinary, without losing sight of what _makes_ something extraordinary. But Beloved as a whole does not fit into that category. It is a film that attempts to be better than most but ends up falling behind, primarily due to inefficient scripting and editing. To see an extraordinary film that is extraordinarily made - now that would be something.
Read more of my reviews at In Film Australia http://infilmau.iah.net
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


Select Test File "parsingtest.data". Will reject any other file.
On success, this input will be removed.
Select Test HTML File "testhtml.data". Will reject any other file.


Congratulations on getting a callback! We're really excited to hear more from you. Below, you can find mp3's for the parts you'll be singing in callbacks. Let us know if you have any questions! See you at the barbecue Thursday, September 27 from 4:00pm-7:00pm at Terman Fountain!
River/Bottom of the River Excerpt (MIDI)


Form version: 26 February 2003 (return buttons added)
Date audit undertaken:
Auditor:
Print a copy of this form to fill out. Maintain a copy of the audit in the Delta insurances file. Copy any summary or corrective actions to the Management Review Diary, to be included in the legislative compliance section.
A |
Access and Egress |
B |
Amenities |
C |
Buildings and their Precincts |
D |
Electrical |
E |
Emergency Facilities |
F |
Lighting |
G |
Manual Handling |
H |
Noise |
I |
Occupational First Aid |
J |
Personal Protection |
K |
Prevention of Falls |
L |
Remote or Isolated Work |
M |
Storage |
N |
Traffic Control |
O |
Ventilation |
P |
Workplace Cleanliness and Hygiene |
Q |
Plant |
R |
Hazardous Substances |
| S | Administration and Record Keeping |
| ACTION SUMMARY |
A |
Access and Egress | References OHS&W Regulations 1995: Divisions: 2.1, 2.3, 2.13 Australian Standards AS1657, AS1318 | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
A1 |
Buildings to be clean no significant rubbish on floors, shelves, on work spaces, or in storage areas. | |||
A2 |
Floors are non slip and free of defects | |||
A3 |
Hand-holds, hand rails to all stairways | |||
A4 |
Treads on steps in good condition and slip resistant | |||
A5 |
The nose or edge of steps clearly defined | |||
A6 |
Access to fire extinguishers is uninhibited. | |||
A7 |
Openings have gratings installed. | |||
A8 |
There is safe access to and egress from any place of work. | |||
A9 |
Walkways/aisles and spaces where people are required to move are at least 600mm wide. |
B |
Amenities Part 1 |
References OHS&W Regulations 1995: Divisions: 2.2 Approved Code of Practice on Amenities No issue of Australian Standards | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
B2 |
Change and wash rooms are available. | |||
B3 |
Adequate seating is provided in all change rooms. | |||
B4 |
Adequate shelving and mirrors are provided. | |||
B5 |
Wash areas are maintained with access to hygiene facilities such as soap, hot/cold running water and drying facilities. | |||
B6 |
Hygienic facilities are provided for eating meals. | |||
B7 |
Dish washing and food storage facilities are provided. | |||
B8 |
Rubbish bins are provided and regularly emptied. |
B |
Amenities
Part 2 |
References OHS&W Regulations 1995: Divisions: 2.2 Approved Code of Practice on Amenities No issue of Australian Standards | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
B9 |
There is at least one toilet per 15 employees. | |||
B10 |
Sanitary disposal is provided for women. | |||
B11 |
Toilets are attached to a sewer or septic system. | |||
B12 |
Privacy measures are taken into consideration in the toilets. | |||
B13 |
Showers where provided are maintained and provide hot and cold water. | |||
B14 |
An adequate supply of cool drinking water is provided. |
C |
Buildings and their Precincts | References OHS&W Regulations 1995: Divisions: 2.3 Approved Code of Practice on Amenities Australian Standards AS1319 | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
C1 |
Floors are sufficiently strong to safely support plant, materials and people at work. | |||
C2 |
Floors are even, unbroken and slip resistant and free of indentations. | |||
C3 |
Floors have adequate drainage where liquids may be involved. | |||
C4 |
Fixed coverings on the floor are installed in a manner so as to prevent tripping. | |||
C5 |
Warning devices are available when a spillage of a liquid or a material on a floor occurs. | |||
C6 |
Persons are not required to stand for long periods of time (stool provided) OR have a mat or floor covering provided that provides reasonable relief. | |||
C7 |
A minimum of 3 square metres of floor area excluding furniture, fittings and equipment is provided for each employee. | |||
C8 |
The floor to ceiling distance of any room where a person works on a regular basis is at least 2.4 metres. |
D |
Electrical | References OHS&W Regulations 1995: Divisions: 2.5 Approved Code of Practice Australian Standards AS 1680, AS 2293, AS/NZS 3760, AS 3100, AS 1543, AS/NZS 3160, AS 3190, AS 3191. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
D1 |
Work on electrical installations and equipment is only done by a qualified electrician. | |||
D2 |
New power circuits, other than for lighting, have non-portable Residual Current Devices (RCDs) included. | |||
D3 |
RCD is tagged to indicate test and next check date. | |||
D4 |
RCD test (in accordance with AS/NZS 3760 and AS 3190) results are recorded in RCD logbook and held for 5 years. | |||
D5 |
Leads, plugs and sockets are in good order. | |||
D6 |
Computer cables and leads not allowed to dangle where they could cause entanglement. | |||
D7 |
Electrical leads not wrapped around metal structures. |
E |
Emergency Facilities and Procedures
Part 1 |
References OHS&W Regulations 1995: Divisions: 2.6 & 2.7 Code of General Principles Section 11 Australian Standards AS 1221, AS 1715, AS 1851, AS 3745, AS 1657, AS 1318. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
E1 |
Adequate numbers and types of fire extinguishers are available. | |||
E2 |
Fire extinguishers are in sound condition (colour, label, hose). | |||
E3 |
Fire extinguisher seals are intact and pressure gauges are in green range. | |||
E4 |
An up to date fire fighting equipment plan is displayed. |
E |
Emergency
Facilities and Procedures Part 2 |
References OHS&W Regulations 1995: Divisions: 2.6 & 2.7 Code of General Principles Section 11 Australian Standards AS 1221, AS 1715, AS 1851, AS 3745, AS 1657, AS 1318. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
E5 |
An emergency evacuation plan is developed displayed and practiced at least twice yearly and documented. | |||
E6 |
All exits are kept clear. | |||
E7 |
Appropriate deluge facilities are available and accessible at site where corrosive substances could cause injury to skin or eyes. |
F |
Lighting | References OHS&W Regulations 1995: Division: 2.8. Code of General Principles. Australian Standards AS 1680, AS 2293 | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
F1 |
Lights are clean, effective and appropriate for each application. | |||
F2 |
Lighting adequate for tasks being performed. | |||
F3 |
All lights functional. | |||
F4 |
No flickering lights. | |||
F5 |
Computer terminals situated so that screen glare is minimised. |
G |
Manual Handling Part 1 |
References OHS&W Regulations 1995: Division: 2.9 Approved Code of Practice for Manual Handling. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
G1 |
Equipment and containers used in the work place are constructed and maintained, to ensure no risk to health when loaded manually. | |||
G2 |
Mechanical aids are available where manual handling cannot be eliminated. | |||
G3 |
Staff and clients are trained in the use of mechanical aids where necessary. | |||
G4 |
Prolonged bending activities are minimised. | |||
G5 |
Frequent reaching above shoulder height is minimised. | |||
G6 |
Frequent or prolonged twisting of the back is minimised. |
G |
Manual
Handling Part 2 |
References OHS&W Regulations 1995: Division: 2.9 Approved Code of Practice for Manual Handling. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
G7 |
Work chairs are adjustable and designed to enable proper seating posture. | |||
G8 |
Footrests are available where required. | |||
G9 |
Barriers, gates and doors are maintained so that they are easy to operate. |
H |
Noise | References OHS&W Regulations 1995: Division: 2.10 Australian Standards: AS 1269, AS 1270 | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
H1 |
All plant and work activities where noise levels exceed 85 dBA are identified and have hearing protection signs displayed. | |||
H2 |
Employees are provided with information and training on noise control measures for use in the field. | |||
H3 |
Hearing protection equipment is provided for use in the field. |
I |
Occupational First Aid | References OHS&W Regulations 1995: Division: 2.11 Approved Code of Practice for Occupational Health and First Aid in the Workplace. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
I1 |
First aid kits are stocked with minimum requirements as outlined in leaflet contained in kits. | |||
I2 |
Regular first aid training is provided. | |||
I3 |
The locations of first aid kits are clearly identified. | |||
I4 |
First aid kits are maintained. | |||
I5 |
The size of the first aid kit is suitable for the number of personnel in the area. |
J |
Personal
Protection Part 1 |
References OHS&W Regulations 1995: Division: 2.12 Australian Standards AS 1336, AS 1338, AS 1715, AS 1716, AS 1270, AS 2161, AS 2210, AS 2626. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
J 1 |
All personnel have been issued with personal protective equipment relevant to their work activities. | |||
J 2 |
All personal protective equipment (PPE) is maintained. | |||
J 3 |
Hearing protection devices are suitable for noise levels encountered. | |||
J 4 |
If the sharing of PPE could present a hygiene risk it is issued as a personal issue or is sanitised/sterilised after each use. | |||
J 5 |
Safety footwear is in good condition with soles having adequate tread. | |||
J 6 |
Personnel are trained in the use of personal safety equipment relevant to the work activity. | |||
J 7 |
Safety glasses/ goggles/face shields are cleaned and have minimal scratches. | |||
J 8 |
Safety glasses have side shields fitted. |
J |
Personal
Protection Part 2 |
References OHS&W Regulations 1995: Division: 2.12 Australian Standards AS 1336, AS 1338, AS 1715, AS 1716, AS 1270, AS 2161, AS 2210, AS 2626. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
J 9 |
Gloves are maintained and are suitable for the work activity. | |||
J 10 |
Safety vests are provided in good condition and worn by personnel working on or near roads. | |||
J 11 |
PPE is an appropriate size and fit and is reasonably comfortable for the user to wear. |
K |
Prevention of Falls | References OHS&W Regulations 1995: Division: 2.13 Approved Code of Practice for the Safe Erection of Structural Steelwork. Australian Standards AS 1418, AS 1576, AS 1657, AS/NZS 1892, AS 2626. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
K 1 |
All tanks, pits, chambers etc. have secure covers or other forms of safeguarding. | |||
K 2 |
All covers and safeguarding are maintained and are not removed except for allowing access or egress. | |||
K 3 |
Stepladders are fitted with a rigid spreader connecting the back legs to the stiles. |
L |
Remote or Isolated Work | References OHS&W Regulations 1995: Division: 2.14 Penrice Soda Products OHS Remote Areas Policy. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
L 1 |
Personnel working in remote locations or alone on a regular basis carry a mobile phone and/or radio. | |||
L 2 |
Procedures and training are in place for communication with personnel who are working with plant and are isolated from assistance. | |||
L 3 |
Approved first aid kit is in all vehicles. |
M |
Storage | References OHS&W Regulations 1995: Division: 2.15 Australian Standard AS 1940 and AS 1216. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
M 1 |
Heavy items are stored between waist and knee height. | |||
M 2 |
Storage areas are designed to minimise lifting problems. | |||
M 3 |
Storage areas are free of sharp edges. | |||
M 4 |
Storage areas with items above head height have a suitable step ladder/stool provided. | |||
M 5 |
All gas cylinders are stored securely. |
N |
Traffic Control | References OHS&W Regulations 1995: Division: 2.16 Australian Standard AS 1742. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
N 1 |
Personnel required to drive vehicles have appropriate licences. | |||
N 2 |
General purpose safety vests are available to all personnel working on or adjacent to roads. |
O |
Ventilation | References OHS&W Regulations 1995: Division: 2.17 Australian Standard AS 1668. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
O 1 |
Systems are in place for an adequate supply of clean fresh air. | |||
O 2 |
Enclosed area air exhaust operates effectively. | |||
O 3 |
Portable coolers and fans are maintained. |
P |
Workplace Cleanliness and Hygiene | References OHS&W Regulations 1995: Division: 2.18 | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
P 1 |
The workplace and anywhere personnel may be required to work are kept clean and hygienic. | |||
P 2 |
Windows and skylights are cleaned regularly to allow adequate light into the workplace. | |||
P 3 |
Refuse and litter is not allowed to accumulate in work, storage, recreational or eating areas. | |||
P 4 |
Any amenity provided for the use of personnel is maintained in a clean and tidy condition. |
Q |
Plant Part 1 |
References OHS&W Regulations 1995: Division: 3.1 Australian Standards: AS 1200, AS 1418, AS 1638, AS 2030, AS 3788. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
Q 1 |
All plant is located in a position to enable safe operation. | |||
Q 2 |
Sufficient space is provided around plant for safe maintenance and repair. | |||
Q 3 |
Gas cylinders are in good condition and are in date. |
R |
Hazardous Substances | References OHS&W Regulations 1995: Division: 4 Approved Codes of Practice: Control of Workplace Hazardous Substances, Labeling of Workplace Substances. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
R 1 |
All hazardous substances are identified and recorded in a register. | |||
R 2 |
Material Safety Data Sheets (MSDS) for each substance is recorded in a register. | |||
R 3 |
Containers holding hazardous substances are labeled appropriately with the product name and the relevant risk and safety wording. | |||
R 4 |
The register or particular MSDS is readily available to all personnel who could be exposed to the hazardous substances. | |||
R 5 |
MSDS are obtained on all new hazardous substances. | |||
R 6 |
Personnel are provided with instruction and training in relation to hazardous substances used in the workplace. |
S |
Administration and Record Keeping | References OHS&W Regulations 1995: Regulations; 1.3.4, 2.5.5(4), 3.2.15, 3.2.35, 4.2.8, 4.1.14(4), 4.1.17, 4.1.18, 4.1.19, 4.1.20. | ||
| Bench Mark Criterion | Yes |
No |
Comments | |
S 1 |
Records are established on incidents, first aid treatments, accident investigation and workplace injuries and kept for 3 years. | |||
S 2 |
Records of Hazard/Workplace Inspections are kept for 5 years. | |||
S 3 |
Records of maintenance, inspection and testing of plant is kept for 5 years. | |||
S 4 |
Records of staff training are kept for 5 years. Training includes First aid and the use of Delta procedures for the safe use of hazardous substances | |||
S 5 |
Records of electrical testing of electrical equipment and RCDs are kept for 5 years. | |||
S 6 |
Records of workplace hazardous substances are readily available to any emergency service. |
| Item
Number |
Description | Proposed corrective Action | Responsible
Person |
Comp.
Date |


|
Dear MindTrails Staff, A participant with ID in the study just completed the assessment scale and received a score that exceeds our threshold. The participant will receive a notification explaining these declining results. Their original score was , they recently scored |


Most entry-level computer engineering jobs require at least a bachelor's degree in computer engineering (or computer science and engineering). Typically one must learn an array of mathematics such as calculus, algebra and trigonometry and some computer science classes.[citation needed] Sometimes a degree in electronic engineering is accepted, due to the similarity of the two fields. Because hardware engineers commonly work with computer software systems, a strong background in computer programming is necessary. According to BLS, "a computer engineering major is similar to electrical engineering but with some computer science courses added to the curriculum".[20] Some large firms or specialized jobs require a master's degree.
It is also important for computer engineers to keep up with rapid advances in technology. Therefore, many continue learning throughout their careers. This can be helpful, especially when it comes to learning new skills or improving existing ones. For example, as the relative cost of fixing a bug increases the further along it is in the software development cycle, there can be greater cost savings attributed to developing and testing for quality code as soon as possible in the process, and particularly before release.


course description
artists who create by writing or producing other representations of what the world is or could be are also laying out a map for how the world could become.
richard p. gabriel, science is not enough.
the world is a work of carefully assembled, organized and presented pieces of fiction, which intersect more or less intimately with our beliefs and experiences. this course will propose a suspension of disbelief in order to construct virtual cosmogonies in the Unity game engine.
how can we pick, lay out and program texts, images, films, objects, spaces and procedures to persuade a virtual visitor of the coherence of our world?
drawing on environmental storytelling, procedural rhetoric, literary studies and museography, this class will explore how we can build accounts of untold stories, alternate realities and possible worlds.
the whole class website can be found here.
course worlds
find all the worlds created during the course here.


FROM THE SHADOWS
From the Shadows is a cooperative puzzle platformer game where players have to work their way through a mysterious mansion by resolving puzzles that revolve around the mechanics of Light and Shadow.
This game is an end of studies project for the Gamagora Game Show. It was made in 4 months between January and May 2020, with 2 months under quarantine due to COVID-19 that brought an additional challenge. We were a team of 18 students including programmers, level designers, 3D artists, and composers.
I was both lead developer and project manager. I was in charge of the character controller, and I created various tools for the game design, such as an automatic camera boundaries system, or customs UI components.
We're all very proud of our work, so don't hesitate to grab the game for free on Steam or Itch.io (links bellow)
Steam Itchio Github


Below is a list of all html tags with links to their page on this site, W3C.org and www.w3schools.com.
W3C is the principle organization that sets standards for HTML. While I like what they are doing with HTML5, W3C's site is next to impossible to navigate and their language tangled at best. However, they are the powers that be. As a web designer you will eventually find yourself on their site. You may as well start now.
I often use W3schools as a reference site, plus they have good intermediate level tutorials. In fact I recommend them as a good site to continue your studies after you have gotten the basics down here.
Below I have links to the appropriate page on this site, on W3C and w3schools. There are a number of elements that do not yet have a page on this site, and therefore don't have links. I will add them as the site grows.
|
HTML-5-tutorial
|
W3C |
W3schools |
HTML-5-tutorial
|
W3C |
W3schools |
|


Choose best books from the millions to prepare your best
Explore the world of fictions at your fingers
Get inspired and learn from the leaders of tomorrow to be the leader today
Benjamin Franklin at Rs.999Shop Now
Memory at Rs.399Shop Now
The King Of Drugs at Rs.499Shop Now
The Paying Guests at Rs.299Shop Now
Follow me to grouhd at Rs.399Shop Now
Little Mermaid Rs.299Shop Now
Cold River at Rs.199Shop Now
Origin at Rs.399Shop Now
Venus at Rs.299Shop Now
A Million To One at Rs.499Shop Now
The Black Sea at Rs.799Shop Now
The Healer Within at Rs.399Shop Now
The Act Of Life at Rs.399Shop Now
Sin Eater at Rs.299Shop Now
Spirit's Voice at Rs.999Shop Now


Sorpi
Nico
Juan
Pepe
Yuan
Welcome
Registered as "Sorpi"
Hola, Sorpi
Send
Welcome to WebRTCnetmesh's Chat Example!
Please choose a nickname in order to login
Connect


The InputBuffer (read-only buffer). More...
#include <Buffer.hh>
Classes | |
| class | ShallowCopy |
| Class to indicate that a copy of a OutputBuffer to InputBuffer should be a shallow copy, used to enable reading of the contents of an OutputBuffer without need to convert it to InputBuffer using a deep copy. | |
Public Types | |
| typedef detail::size_type | size_type |
| typedef detail::data_type | data_type |
| typedef detail::InputBufferIterator | const_iterator |
Public Member Functions | |
| InputBuffer () | |
| Default InputBuffer creates an empty buffer. | |
| InputBuffer (const OutputBuffer &src) | |
| Construct an InputBuffer that contains the contents of an OutputBuffer. | |
| bool | empty () const |
| Does the buffer have any data? | |
| size_type | size () const |
| Returns the size of the buffer, in bytes. | |
| const_iterator | begin () const |
| Return an iterator pointing to the first data chunk of this buffer that contains data. | |
| const_iterator | end () const |
| Return the end iterator. | |
| int | numChunks () const |
| Returns the number of chunks containing data. | |
Friends | |
| class | OutputBuffer |
| class | istreambuf |
| class | BufferReader |
The InputBuffer (read-only buffer).
InputBuffer is an immutable buffer which that may be constructed from an OutputBuffer, or several of OutputBuffer's methods. Once the data is transfered to an InputBuffer it cannot be modified, only read (via BufferReader, istream, or its iterator).
Assignments and copies are shallow copies.
| avro::InputBuffer::InputBuffer | ( | ) | [inline] |
Default InputBuffer creates an empty buffer.
Copy/assignment functions use the default ones. They will do a shallow copy, and because InputBuffer is immutable, the copies will be identical.
Destructor also uses the default, which resets a shared pointer, deleting the underlying data if no other copies of exist.
| avro::InputBuffer::InputBuffer | ( | const OutputBuffer & | src | ) | [inline] |
Construct an InputBuffer that contains the contents of an OutputBuffer.
The two buffers will have the same contents, but this copy will be immutable, while the the OutputBuffer may still be written to.
If you wish to move the data from the OutputBuffer to a new InputBuffer (leaving only free space in the OutputBuffer), OutputBuffer::extractData() will do this more efficiently.
Implicit conversion is allowed.


You can also use this form to request an update to an existing resource.
Thank you for suggesting a resource! Your suggestion will be considered and may appear on the site within a few days.
Company Name, Company Type, and Link are all required fields.


Help
Markers explained
- Start, marks the beginpoint of the route.
- Stop, marks the endpoint of the route.
- Clicking on 'Add waypoint' button will add a waypoint to the route.
- Waypoint 1, the first waypoint in the route. You can add 2 waypoints at this moment (server side limitation).
Create a route
A route is created by placing at least one Start and one Finish marker on the map. Placing a marker on the map is easy. Open the 'Route' tab and either:- Click on a green, orange or number balloon and then click somewhere on the map. You should see that a marker is places where you click on the map. Click the map again to move the marker to a different position, or drag the marker on the map.
- Type a name in the searchbox and hit the Enter key. For better results you can add the place- or country-name as well to narrow the search results. The marker will be placed on the map when the search is completed successfully.
You can create a more advanced route by adding one or more Waypoints. Click the 'Add Waypoint' button and you will see a new entry in the waypoint list. Add the new Waypoint to the map just like the Start and Finish waypoint as described above. Waypoints can be reordered by dragging the balloon up and down in the list. Click 'Find route' when you've added the Start and Finish markers (and maybe even some Waypoint markers too) on the map. The Routing Service will now try to calculate a route. The route is automatically plotted on the map when the calculation has finished.
Change the route parameters
You can change the route parameters (e.g. from 'Car' to 'Bicycle') by clicking on the radio button on the Route tab and then click the 'Find Route' button. A new route will be calculated based on the given parameters.Partial new route (single click map/routing data testing)
If you click on the map again a new TO or FROM marker is placed. Click on 'Find Route' and the new route is calculated. This is very handy for mappers when testing the route network of a certain area. Once you've spotted a bug in the data you can click on the 'EDIT MAP' button and the online 'Potlatch' map data editor is automatically loaded in a new window/tab with the current map view.Reverse a route
If you want to know how the return trip might look like then click on the 'Reverse' button on the 'Route' tab. All Waypoints will be reversed and a new route will be calculated.Completely new route
Click the 'Clear' button if you want to generate a completely new route (or when things go wrong, which happens sometimes...). This should work as a reset. If the site continues to be non-functional please try a forced reload of your browser by pressing ctrl-F5.Adding previously traveled routes
Sometimes, it might be desired to view a route already traveled alongside the planned route. This can be done by dragging a GPX file onto the map. (This feature requires a browser with support for the HTML5 File API.)Known issues
- Gosmore is usually very quick in returning a route, often a route is calculated in under 0.1 seconds and downloading the resulting route takes more time. If it takes more then 30 seconds to calculate a route then you can assume there is some problem in the underlying OSM data and often your route won't be complete.
- Moped and Mofa routing currently behaves identically to car routing.
- The route data is updated approximately once a week after a new planet dump is available, so it is possible that the map is not always in sync with the routing engine.
- Due to lack of memory on the server, calculation time can take very long. The server is then busy loading data from the harddisk into memory which is very slow compared to reading cached data from memory. This can be a problem especially when multiple pleople are requesting routes and the routing engines are fighting for resources as a result.


Like youtube and google, twitter is blocked in the same way, if you want to know how firewall filter system works, you can read my previous articles, this article I introduce some ways to walk around firewall, and visit twitter freely.
The main idea is avoid any DNS packets send out for all blocked sites, when visit twitter, we should find out the IP addresses of blocked sites servers, which reachable, and append them into host file.
how can we know all the blocked sites ?
we can find them out following steps below:
1) open capture tool, like warshark, or sniffer, and start to capture packets
2) input twitter.com into your browser
3) when browser notify connection time-out or connection reset, stop capturing
4) packet analyze, we need to check all the DNS reply, and the connection establish between our device and site’s server IP address in DNS reply, if that server never answer our device’s request, or connection reset by server, which TTL value is obvious different with other packets in the same connection, they will be the sites blocked by firewall.
After knowing all the blocked sites, the next step we need to do is find out valid IP addresses for all blocked sites, we can do it via ping these blocked site outside firewall, like online ping website in other countries, or iterate these sites’s IP pool.
For twitter, there are at least two sites, twitter.com and domain with suffix twimg.com, which server store images, like pbs.twimg.com, we need to find out these two sites’s IP addresses, and it seems not like google, all services can visit via a single server, in twitter, text and image store at different servers, so we should find them all, or web page won’t display normally.
The last step is append IP address and domain name into host file, flush DNS cache, and enjoy.


PETSc algebraic solvers can now use pthreads on Vec and Mat operations. This sometimes provides an alternative to the all MPI approach.
We recommend working with petsc master (git branch) if you want to explore this feature.
- Installation of PETSc with threads
-
Quick summary of usage in petsc-master:
- Threads can be used via native pthread lockfree implementation or OpenMP.
-
The three important run-time options for using threads are:
- -threadcomm_nthreads <nthreads>: Sets the number of threads
- -threadcomm_affinities <list_of_affinities>: Sets the core affinities of threads
- -threadcomm_type <nothread,pthread,openmp>: Threading model (OpenMP, pthread, nothread)
- Run with -help to see the avialable options with threads.
- A few tutorial examples are located at $PETSC_DIR/src/sys/threadcomm/examples/tutorials
- We could use your help in further developing PETSc with threads; see PETSc Developers site


Border Patrol Agent Returns Fire, Kills Shooter in New Mexico
Officials say an El Paso Sector Border Patrol agent exchanged gunfire with a subject on Monday morning in Sunland Park, New Mexico. The agent returned fire, striking and killing the alleged shooter.
by Bob.Price.Texas, Bob PriceA U.S. Border Patrol agent came under fire near the Mexican border Monday morning after encountering a group of four people, according to a statement from El Paso Sector Border Patrol officials.
Officials tweeted the agent returned fire and that one person was transported to an area hospital. Doctors reported the subject died from his wounds at the hospital, officials stated. No Border Patrol agents received injuries during the exchange of gunfire, say federal authorities.
“During the encounter, the subject produced a firearm and shot at the agent,” El Paso Sector officials reported. “The agent returned fire striking the subject. An agent rendered aid to the subject until emergency medical personnel arrived.”
No additional information about the events leading up to the shooting is available at this time. The shooting will be investigated by the FBI and the CBP Office of Professional Responsibility.
Last week, Del Rio Sector Border Patrol agents encountered an alleged human smuggler who had a 9mm pistol in the door pocket of the vehicle driven by the smuggler, Breitbart Texas reported. One day before that, Brackettville Station agents found a backpack containing another 9mm pistol in an area where a human smuggler and a group of migrants had been found.
“Smugglers arming themselves with firearms is becoming a common trend,” Del Rio Sector Chief Patrol Agent Raul L. Ortiz said in a written statement. “This poses a threat to not only our agents but the community and those being smuggled as well.”
Bob Price serves as associate editor and senior political news contributor for the Breitbart Border team. He is an original member of the Breitbart Texas team. Follow him on Twitter @BobPriceBBTX and Facebook .


--- layout: post title: Character mood board date: '2016-05-02T18:30:31+02:00' categories: - Sketches picture_url: https://film-Storyboards.tumblr.com/post/143762202393 ---


To access the full-text of Harvard Business Review articles, you must search for the article title at the journal's homepage.
Full text available via: {{oadoilinktext}}


Publications on the IHACRES model
Croke, B.F.W., Jakeman, A.J. (2004)
"A catchment moisture deficit module for the IHACRES rainfall-runoff model",
Environmental Modelling & Software, 19(1), pp. 1–5.
<https://doi.org/10.1016/j.envsoft.2003.09.001
Croke, B.F.W. and Jakeman, A.J. (2005)
Corrigendum to "A Catchment Moisture Deficit module for the IHACRES rainfall-runoff model [Environ. Model. Softw. 19 (1) (2004) 1–5]"
Environmental Modelling & Software, 20(7), p. 997.
https://doi.org/10.1016/j.envsoft.2004.11.004
Evans, J.P. and Jakeman, A.J., (1998).
Development of a simple, catchment-scale, rainfall-evapotranspiration-runoff model.
Environmental Modelling & Software 13, 385–393.
https://doi.org/10.1016/S1364-8152(98)00043-7
Jakeman, A.J. and Hornberger, G.M. (1993).
"How much complexity is warranted in a rainfall-runoff model?"
Water Resources Research 29, 2637-2649.
https://doi.org/10.1029/93WR00877
Jakeman, A.J., Littlewood, I.G. and Whitehead, P.G. (1990).
Computation of the instantaneous unit hydrograph and identifiable component flows with application to two small upland catchments.
Journal of Hydrology 117, 275-300.
https://doi.org/10.1016/0022-1694(90)90097-H
Other implementations
Andrews, F.T., Croke, B.F.W. and Jakeman, A.J. (2011).
"An open software environment for hydrological model assessment and development",
Environmental Modelling and Software, 26 (10) 1171-1185.
https://doi.org/10.1016/j.envsoft.2011.04.006
Croke, B.F.W., Andrews, F., Jakeman, A.J., Cuddy, S.M. and Luddy, A. (2006)
"IHACRES Classic Plus: A redesign of the IHACRES rainfall-runoff model",
Environmental Modelling and Software, 21 426-427.
https://doi.org/10.1016/j.envsoft.2005.07.003
Applications of IHACRES model
Borzì, I., Bonaccorso, B., Fiori, A., (2019).
A Modified IHACRES Rainfall-Runoff Model for Predicting the Hydrologic Response of a River Basin Connected with a Deep Groundwater Aquifer.
Water 11, 2031.
https://doi.org/10.3390/w11102031
Croke, B.F.W. and Jakeman, A.J. (2008).
Use of the IHACRES rainfall-runoff model in semi-arid regions.
In Hydrological Modelling in Arid and Semi-Arid Areas, Wheater, H., Sorooshian, S. and Sharma, K.D. (Eds),
International hydrology Series, Cambridge University Press, pp 41-48.
https://doi.org/10.1017/CBO9780511535734.005
Croke, B.F.W., Islam, A., Ghosh, J. and Khan, M.A. (2011).
"Evaluation of approaches for estimation of rainfall and the Unit Hydrograph",
Hydrology Research, 42(5), 372-385.
https://doi.org/10.2166/nh.2011.017
Croke, B.F.W., Letcher, R.A. and Jakeman, A.J. (2006).
"Development of a flow network for the Namoi River Basin, Australia",
Journal of Hydrology, 319, 51-71.
https://doi.org/10.1016/j.jhydrol.2005.07.001
Croke, B.F.W., Merritt, W.S. and Jakeman, A.J. (2004).
"A Dynamic Model for Predicting Hydrologic Response to Land Cover Changes in Gauged and Ungauged Catchments",
Journal of Hydrology, 291, 115-131.
https://doi.org/10.1016/j.jhydrol.2003.12.012
Herron, N.F. and Croke, B.F.W. (2009)
"Including the Influence of Groundwater Exchanges in a Lumped Rainfall-Runoff Model",
Mathematics and Computers in Simulation, 79, 2689-2700,
https://doi.org/10.1016/j.matcom.2008.08.007
Ivkovic, K.M., Croke, B.F.W. and Kelly, R.A. (2014)
"Overcoming the challenges of using a rainfall-runoff model to estimate the impacts of groundwater extraction on low flows in an ephemeral stream"
Hydrology Research, 45 (1), 58-72.
https://doi.org/10.2166/nh.2013.204
Ivkovic, K.M., Letcher, R.A. and Croke, B.F.W. (2009).
"Use of a simple surface-groundwater interaction model to inform water management",
Australian Journal of Earth Sciences, 56, 71-80.
https://doi.org/10.1080/08120090802541945
Iwanaga, T., Partington, D., Ticehurst, J., Croke, B.F.W. and Jakeman, A.J. (2020).
"A socio-environmental model for exploring sustainable water management futures: Participatory and collaborative modelling in the Lower Campaspe catchment."
Journal of Hydrology: Regional Studies 28, 100669.
https://doi.org/10.1016/j.ejrh.2020.100669
Kokkonen, T., Koivusalo, H., Karvonen, T., Croke, B. and Jakeman, A.J. (2004)
"Exploring streamflow response to effective rainfall across event magnitude scale".
Hydrological Processes, 18: 1467-1486.
https://doi.org/10.1002/hyp.1423
Littlewood, I.G., Clarke, R.T, Collischonn, W. and Croke, B.F.W. (2007).
"Predicting daily streamflow using rainfall forecasts, a simple loss module and unit hydrographs: Two Brazilian catchments",
Environmental Modelling and Software 22(9), 1229-1239
https://doi.org/10.1016/j.envsoft.2006.07.004
Littlewood, I.G. and Croke, B.F.W. (2008).
"Data time-step dependency of conceptual rainfall-streamflow model parameters: an empirical study with implications for regionalisation",
Hydrological Sciences Journal, 53 (4), 685-695.
https://doi.org/10.1623/hysj.53.4.685
import nimib
nbInit
nbText: """
## Publications on the IHACRES model
Croke, B.F.W., Jakeman, A.J. (2004)
"A catchment moisture deficit module for the IHACRES rainfall-runoff model",
Environmental Modelling & Software, 19(1), pp. 1–5.
<<https://doi.org/10.1016/j.envsoft.2003.09.001>
Croke, B.F.W. and Jakeman, A.J. (2005)
Corrigendum to "A Catchment Moisture Deficit module for the IHACRES rainfall-runoff model [Environ. Model. Softw. 19 (1) (2004) 1–5]"
Environmental Modelling & Software, 20(7), p. 997.
<https://doi.org/10.1016/j.envsoft.2004.11.004>
Evans, J.P. and Jakeman, A.J., (1998).
Development of a simple, catchment-scale, rainfall-evapotranspiration-runoff model.
Environmental Modelling & Software 13, 385–393.
<https://doi.org/10.1016/S1364-8152(98)00043-7>
Jakeman, A.J. and Hornberger, G.M. (1993).
"How much complexity is warranted in a rainfall-runoff model?"
Water Resources Research 29, 2637-2649.
<https://doi.org/10.1029/93WR00877>
Jakeman, A.J., Littlewood, I.G. and Whitehead, P.G. (1990).
Computation of the instantaneous unit hydrograph and identifiable component flows with application to two small upland catchments.
Journal of Hydrology 117, 275-300.
<https://doi.org/10.1016/0022-1694(90)90097-H>
## Other implementations
Andrews, F.T., Croke, B.F.W. and Jakeman, A.J. (2011).
"An open software environment for hydrological model assessment and development",
Environmental Modelling and Software, 26 (10) 1171-1185.
<https://doi.org/10.1016/j.envsoft.2011.04.006>
Croke, B.F.W., Andrews, F., Jakeman, A.J., Cuddy, S.M. and Luddy, A. (2006)
"IHACRES Classic Plus: A redesign of the IHACRES rainfall-runoff model",
Environmental Modelling and Software, 21 426-427.
<https://doi.org/10.1016/j.envsoft.2005.07.003>
## Applications of IHACRES model
Borzì, I., Bonaccorso, B., Fiori, A., (2019).
A Modified IHACRES Rainfall-Runoff Model for Predicting the Hydrologic Response of a River Basin Connected with a Deep Groundwater Aquifer.
Water 11, 2031.
<https://doi.org/10.3390/w11102031>
Croke, B.F.W. and Jakeman, A.J. (2008).
Use of the IHACRES rainfall-runoff model in semi-arid regions.
In Hydrological Modelling in Arid and Semi-Arid Areas, Wheater, H., Sorooshian, S. and Sharma, K.D. (Eds),
International hydrology Series, Cambridge University Press, pp 41-48.
<https://doi.org/10.1017/CBO9780511535734.005>
Croke, B.F.W., Islam, A., Ghosh, J. and Khan, M.A. (2011).
"Evaluation of approaches for estimation of rainfall and the Unit Hydrograph",
Hydrology Research, 42(5), 372-385.
<https://doi.org/10.2166/nh.2011.017>
Croke, B.F.W., Letcher, R.A. and Jakeman, A.J. (2006).
"Development of a flow network for the Namoi River Basin, Australia",
Journal of Hydrology, 319, 51-71.
<https://doi.org/10.1016/j.jhydrol.2005.07.001>
Croke, B.F.W., Merritt, W.S. and Jakeman, A.J. (2004).
"A Dynamic Model for Predicting Hydrologic Response to Land Cover Changes in Gauged and Ungauged Catchments",
Journal of Hydrology, 291, 115-131.
<https://doi.org/10.1016/j.jhydrol.2003.12.012>
Herron, N.F. and Croke, B.F.W. (2009)
"Including the Influence of Groundwater Exchanges in a Lumped Rainfall-Runoff Model",
Mathematics and Computers in Simulation, 79, 2689-2700,
<https://doi.org/10.1016/j.matcom.2008.08.007>
Ivkovic, K.M., Croke, B.F.W. and Kelly, R.A. (2014)
"Overcoming the challenges of using a rainfall-runoff model to estimate the impacts of groundwater extraction on low flows in an ephemeral stream"
Hydrology Research, 45 (1), 58-72.
<https://doi.org/10.2166/nh.2013.204>
Ivkovic, K.M., Letcher, R.A. and Croke, B.F.W. (2009).
"Use of a simple surface-groundwater interaction model to inform water management",
Australian Journal of Earth Sciences, 56, 71-80.
<https://doi.org/10.1080/08120090802541945>
Iwanaga, T., Partington, D., Ticehurst, J., Croke, B.F.W. and Jakeman, A.J. (2020).
"A socio-environmental model for exploring sustainable water management futures: Participatory and collaborative modelling in the Lower Campaspe catchment."
Journal of Hydrology: Regional Studies 28, 100669.
<https://doi.org/10.1016/j.ejrh.2020.100669>
Kokkonen, T., Koivusalo, H., Karvonen, T., Croke, B. and Jakeman, A.J. (2004)
"Exploring streamflow response to effective rainfall across event magnitude scale".
Hydrological Processes, 18: 1467-1486.
<https://doi.org/10.1002/hyp.1423>
Littlewood, I.G., Clarke, R.T, Collischonn, W. and Croke, B.F.W. (2007).
"Predicting daily streamflow using rainfall forecasts, a simple loss module and unit hydrographs: Two Brazilian catchments",
Environmental Modelling and Software 22(9), 1229-1239
<https://doi.org/10.1016/j.envsoft.2006.07.004>
Littlewood, I.G. and Croke, B.F.W. (2008).
"Data time-step dependency of conceptual rainfall-streamflow model parameters: an empirical study with implications for regionalisation",
Hydrological Sciences Journal, 53 (4), 685-695.
<https://doi.org/10.1623/hysj.53.4.685>
"""
nbSave


Symphony Garden
posts
Archives for Symphony Garden
Mon 01 July 2019
The Elf Family
Mon 01 July 2019
Four Girls in the Monstre Orphanage
Mon 01 July 2019
Innocence Elf
Mon 01 July 2019
La Fille de Moustache


|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object android.app.Activity android.support.v4.app.FragmentActivity android.support.v7.app.ActionBarActivity
public class ActionBarActivity
Base class for activities that use the support library action bar features.
| Constructor Summary | |
|---|---|
ActionBarActivity()
|
| Method Summary | |
|---|---|
void |
addContentView(View view,
ViewGroup.LayoutParams params)
|
android.support.v4.app.ActionBarDrawerToggle.Delegate |
getDrawerToggleDelegate()
|
MenuInflater |
getMenuInflater()
|
ActionBar |
getSupportActionBar()
Support library version of Activity#getActionBar . |
android.support.v4.app.FragmentManager |
getSupportFragmentManager()
|
Intent |
getSupportParentActivityIntent()
Obtain an Intent that will launch an explicit target activity
specified by sourceActivity's NavUtils.PARENT_ACTIVITY <meta-data>
element in the application's manifest. |
void |
onBackPressed()
|
void |
onConfigurationChanged(Configuration newConfig)
|
boolean |
onCreatePanelMenu(int featureId,
Menu menu)
|
View |
onCreatePanelView(int featureId)
|
void |
onCreateSupportNavigateUpTaskStack(android.support.v4.app.TaskStackBuilder builder)
Support version of #onCreateNavigateUpTaskStack(android.app.TaskStackBuilder) . |
boolean |
onMenuItemSelected(int featureId,
android.view.MenuItem item)
|
boolean |
onPreparePanel(int featureId,
View view,
Menu menu)
|
void |
onPrepareSupportNavigateUpTaskStack(android.support.v4.app.TaskStackBuilder builder)
Support version of #onPrepareNavigateUpTaskStack(android.app.TaskStackBuilder) . |
void |
onSupportActionModeFinished(ActionMode mode)
Notifies the activity that a support action mode has finished. |
void |
onSupportActionModeStarted(ActionMode mode)
Notifies the Activity that a support action mode has been started. |
boolean |
onSupportNavigateUp()
This method is called whenever the user chooses to navigate Up within your application's activity hierarchy from the action bar. |
void |
setContentView(int layoutResID)
|
void |
setContentView(View view)
|
void |
setContentView(View view,
ViewGroup.LayoutParams params)
|
void |
setSupportProgress(int progress)
Support library version of Activity#setProgress(int) . |
void |
setSupportProgressBarIndeterminate(boolean indeterminate)
Support library version of Activity#setProgressBarIndeterminate(boolean) |
void |
setSupportProgressBarIndeterminateVisibility(boolean visible)
Support library version of Activity#setProgressBarIndeterminateVisibility(boolean) |
void |
setSupportProgressBarVisibility(boolean visible)
Support library version of Activity#setProgressBarVisibility(boolean) |
ActionMode |
startSupportActionMode(ActionMode.Callback callback)
|
void |
supportInvalidateOptionsMenu()
|
void |
supportNavigateUpTo(Intent upIntent)
Navigate from sourceActivity to the activity specified by upIntent, finishing sourceActivity in the process. |
boolean |
supportRequestWindowFeature(int featureId)
Enable extended support library window features. |
boolean |
supportShouldUpRecreateTask(Intent targetIntent)
Returns true if sourceActivity should recreate the task when navigating 'up' by using targetIntent. |
| Methods inherited from class android.support.v4.app.FragmentActivity |
|---|
dump, getLastCustomNonConfigurationInstance, getSupportFragmentManager, getSupportLoaderManager, onAttachFragment, onCreateView, onKeyDown, onLowMemory, onPanelClosed, onRetainCustomNonConfigurationInstance, onRetainNonConfigurationInstance, startActivityForResult, startActivityFromFragment |
| Methods inherited from class java.lang.Object |
|---|
equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Constructor Detail |
|---|
public ActionBarActivity()
| Method Detail |
|---|
public ActionBar getSupportActionBar()
Activity#getActionBar
.
Retrieve a reference to this activity's ActionBar.
public MenuInflater getMenuInflater()
public void setContentView(int layoutResID)
public void setContentView(View view)
public void setContentView(View view, ViewGroup.LayoutParams params)
public void addContentView(View view, ViewGroup.LayoutParams params)
public void onConfigurationChanged(Configuration newConfig)
onConfigurationChanged
in class android.support.v4.app.FragmentActivity
public View onCreatePanelView(int featureId)
public final boolean onMenuItemSelected(int featureId, android.view.MenuItem item)
onMenuItemSelected
in class android.support.v4.app.FragmentActivity
public boolean supportRequestWindowFeature(int featureId)
This is a convenience for calling
getWindow().requestFeature()
.
featureId
- The desired feature as defined in
android.view.Window
or WindowCompat
.
android.app.Activity#requestWindowFeature
,
android.view.Window#requestFeature
public void supportInvalidateOptionsMenu()
supportInvalidateOptionsMenu
in class android.support.v4.app.FragmentActivity
public void onSupportActionModeStarted(ActionMode mode)
mode
- The new action mode.public void onSupportActionModeFinished(ActionMode mode)
mode
- The action mode that just finished.public ActionMode startSupportActionMode(ActionMode.Callback callback)
public boolean onCreatePanelMenu(int featureId, Menu menu)
onCreatePanelMenu
in class android.support.v4.app.FragmentActivity
public boolean onPreparePanel(int featureId, View view, Menu menu)
onPreparePanel
in class android.support.v4.app.FragmentActivity
public void onBackPressed()
onBackPressed
in class android.support.v4.app.FragmentActivity
public void setSupportProgressBarVisibility(boolean visible)
Activity#setProgressBarVisibility(boolean)
Sets the visibility of the progress bar in the title.
In order for the progress bar to be shown, the feature must be requested
via supportRequestWindowFeature(int)
.
visible
- Whether to show the progress bars in the title.public void setSupportProgressBarIndeterminateVisibility(boolean visible)
Activity#setProgressBarIndeterminateVisibility(boolean)
Sets the visibility of the indeterminate progress bar in the title.
In order for the progress bar to be shown, the feature must be requested
via supportRequestWindowFeature(int)
.
visible
- Whether to show the progress bars in the title.public void setSupportProgressBarIndeterminate(boolean indeterminate)
Activity#setProgressBarIndeterminate(boolean)
Sets whether the horizontal progress bar in the title should be indeterminate (the circular is always indeterminate).
In order for the progress bar to be shown, the feature must be requested
via supportRequestWindowFeature(int)
.
indeterminate
- Whether the horizontal progress bar should be indeterminate.public void setSupportProgress(int progress)
Activity#setProgress(int)
.
Sets the progress for the progress bars in the title.
In order for the progress bar to be shown, the feature must be requested
via supportRequestWindowFeature(int)
.
progress
- The progress for the progress bar. Valid ranges are from
0 to 10000 (both inclusive). If 10000 is given, the progress
bar will be completely filled and will fade out.public void onCreateSupportNavigateUpTaskStack(android.support.v4.app.TaskStackBuilder builder)
#onCreateNavigateUpTaskStack(android.app.TaskStackBuilder)
.
This method will be called on all platform versions.
Define the synthetic task stack that will be generated during Up navigation from
a different task.
The default implementation of this method adds the parent chain of this activity
as specified in the manifest to the supplied TaskStackBuilder
. Applications
may choose to override this method to construct the desired task stack in a different
way.
This method will be invoked by the default implementation of #onNavigateUp()
if #shouldUpRecreateTask(Intent)
returns true when supplied with the intent
returned by #getParentActivityIntent()
.
Applications that wish to supply extra Intent parameters to the parent stack defined
by the manifest should override
onPrepareSupportNavigateUpTaskStack(TaskStackBuilder)
.
builder
- An empty TaskStackBuilder - the application should add intents representing
the desired task stackpublic void onPrepareSupportNavigateUpTaskStack(android.support.v4.app.TaskStackBuilder builder)
#onPrepareNavigateUpTaskStack(android.app.TaskStackBuilder)
.
This method will be called on all platform versions.
Prepare the synthetic task stack that will be generated during Up navigation
from a different task.
This method receives the TaskStackBuilder
with the constructed series of
Intents as generated by onCreateSupportNavigateUpTaskStack(TaskStackBuilder)
.
If any extra data should be added to these intents before launching the new task,
the application should override this method and add that data here.
builder
- A TaskStackBuilder that has been populated with Intents by
onCreateNavigateUpTaskStack.public boolean onSupportNavigateUp()
If a parent was specified in the manifest for this activity or an activity-alias to it,
default Up navigation will be handled automatically. See
getSupportParentActivityIntent()
for how to specify the parent. If any activity
along the parent chain requires extra Intent arguments, the Activity subclass
should override the method onPrepareSupportNavigateUpTaskStack(TaskStackBuilder)
to supply those arguments.
See Tasks and Back Stack from the developer guide and Navigation from the design guide for more information about navigating within your app.
See the TaskStackBuilder
class and the Activity methods
getSupportParentActivityIntent()
, supportShouldUpRecreateTask(Intent)
, and
supportNavigateUpTo(Intent)
for help implementing custom Up navigation.
public Intent getSupportParentActivityIntent()
Intent
that will launch an explicit target activity
specified by sourceActivity's NavUtils.PARENT_ACTIVITY
<meta-data>
element in the application's manifest. If the device is running
Jellybean or newer, the android:parentActivityName attribute will be preferred
if it is present.
getSupportParentActivityIntent
in interface android.support.v4.app.TaskStackBuilder.SupportParentable
public boolean supportShouldUpRecreateTask(Intent targetIntent)
If this method returns false the app can trivially call
supportNavigateUpTo(Intent)
using the same parameters to correctly perform
up navigation. If this method returns false, the app should synthesize a new task stack
by using TaskStackBuilder
or another similar mechanism to perform up navigation.
targetIntent
- An intent representing the target destination for up navigation
public void supportNavigateUpTo(Intent upIntent)
Intent#FLAG_ACTIVITY_CLEAR_TOP
set
by this method, along with any others required for proper up navigation as outlined
in the Android Design Guide.
This method should be used when performing up navigation from within the same task
as the destination. If up navigation should cross tasks in some cases, see
supportShouldUpRecreateTask(Intent)
.
upIntent
- An intent representing the target destination for up navigationpublic final android.support.v4.app.ActionBarDrawerToggle.Delegate getDrawerToggleDelegate()
getDrawerToggleDelegate
in interface android.support.v4.app.ActionBarDrawerToggle.DelegateProvider
public android.support.v4.app.FragmentManager getSupportFragmentManager()
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |