#include "graphics_afx.h"
#include "GrDXT.h"
Go to the source code of this file.
Defines | |
| #define | COLORBOX_INSET_SHIFT 4 |
| Purpose: To perform DXT compression in realtime. | |
| #define | ALIGN_16 __declspec( align( 16 ) ) |
Functions | |
| void | Extract4x4 (unsigned int *block, unsigned int *src, unsigned int srcWidth) |
| forward declarations. | |
| void | Extract4x4BGR (unsigned char *block, unsigned char *src, unsigned int srcStride) |
| void | Extract4x4XY1 (unsigned char *block, unsigned char *src, unsigned int srcStride) |
| void | MinMax (unsigned char *min, unsigned char *max, unsigned char *block) |
| int | ColorDistSqr (unsigned char *color0, unsigned char *color1) |
| unsigned short | ColorTo565 (const unsigned char *color) |
| void | CompressBlockBGR (unsigned int *dest, unsigned char *block, unsigned char *min, unsigned char *max) |
| void | CompressBlockAlpha (unsigned int *dest, unsigned char *block, unsigned char *min, unsigned char *max) |
| unsigned int | CalcImageSizeDXT1 (unsigned int width, unsigned int height) |
| global functions. | |
| unsigned int | CalcImageSizeDXT5 (unsigned int width, unsigned int height) |
| void | CompressDXT1 (unsigned int *dst, unsigned int width, unsigned int height, void *src) |
| BGRX to DXT1. | |
| void | CompressDXT1BGR (unsigned int *dst, unsigned int width, unsigned int height, void *src) |
| void | CompressDXT5 (unsigned int *dst, unsigned int width, unsigned int height, void *src) |
| BGRA to DXT5. | |
| void | CompressDXT5XY1 (unsigned int *dst, unsigned int width, unsigned int height, void *src) |
| void | FillDXT1 (void *dst, unsigned int width, unsigned int height, unsigned char *bgrxColor) |
| fills a DXT encoded image with the color specified. | |
| void | FillDXT5 (void *dst, unsigned int width, unsigned int height, unsigned char *bgraColor) |
| #define COLORBOX_INSET_SHIFT 4 |
Purpose: To perform DXT compression in realtime.
File: GrDXT.cpp Author: Kevin Bray Created: 04-03-08 Copyright © 2004 Bootstrap Studios. All rights reserved. file header. this decreases the size of the bounding box by 1/16th of it's size. This makes the min/max through color space closer together, and thus reduces the overall error in the image (makes error tend towards the average of a 4x4 block).
| unsigned int CalcImageSizeDXT1 | ( | unsigned int | width, | |
| unsigned int | height | |||
| ) |
| unsigned int CalcImageSizeDXT5 | ( | unsigned int | width, | |
| unsigned int | height | |||
| ) |
| int ColorDistSqr | ( | unsigned char * | color0, | |
| unsigned char * | color1 | |||
| ) |
| void CompressBlockAlpha | ( | unsigned int * | dest, | |
| unsigned char * | block, | |||
| unsigned char * | min, | |||
| unsigned char * | max | |||
| ) |
| void CompressBlockBGR | ( | unsigned int * | dest, | |
| unsigned char * | block, | |||
| unsigned char * | min, | |||
| unsigned char * | max | |||
| ) |
| void CompressDXT1 | ( | unsigned int * | dst, | |
| unsigned int | width, | |||
| unsigned int | height, | |||
| void * | src | |||
| ) |
| void CompressDXT1BGR | ( | unsigned int * | dst, | |
| unsigned int | width, | |||
| unsigned int | height, | |||
| void * | src | |||
| ) |
| void CompressDXT5 | ( | unsigned int * | dst, | |
| unsigned int | width, | |||
| unsigned int | height, | |||
| void * | src | |||
| ) |
BGRA to DXT5.
reserve some space for the 4x4 block of pixels.
iterate through blocks.
note: by treating these as DWORDs, this could cause problems with store forwarding. Basically, the block is getting written to and read from in bytes by other functions, so the different addresses would simply cause store forwarding not to work for 3 out of 4 read operations!
get the color space min/max.
write out the alpha indices.
write out the color indices.
| void CompressDXT5XY1 | ( | unsigned int * | dst, | |
| unsigned int | width, | |||
| unsigned int | height, | |||
| void * | src | |||
| ) |
reserve some space for the 4x4 block of pixels.
iterate through blocks.
note: by treating these as DWORDs, this could cause problems with store forwarding. Basically, the block is getting written to and read from in bytes by other functions, so the different addresses would simply cause store forwarding not to work for 3 out of 4 read operations!
get the color space min/max.
write out the alpha indices.
NOTE: we can do a faster technique for this since we know that that two of the three color values are set to 1.0 (255). write out the color indices.
| void Extract4x4 | ( | unsigned int * | block, | |
| unsigned int * | src, | |||
| unsigned int | srcWidth | |||
| ) |
| void Extract4x4BGR | ( | unsigned char * | block, | |
| unsigned char * | src, | |||
| unsigned int | srcStride | |||
| ) |
| void Extract4x4XY1 | ( | unsigned char * | block, | |
| unsigned char * | src, | |||
| unsigned int | srcStride | |||
| ) |
| void FillDXT1 | ( | void * | dst, | |
| unsigned int | width, | |||
| unsigned int | height, | |||
| unsigned char * | bgrxColor | |||
| ) |
| void FillDXT5 | ( | void * | dst, | |
| unsigned int | width, | |||
| unsigned int | height, | |||
| unsigned char * | bgraColor | |||
| ) |
calculate the color palette for each block.
calculate the alpha palette for each block. Technically, only the first 2 bytes of alphaPelette are the palette. The remaining two bytes are part of the indices.
fill each DXT block with the palette data specified.
color palette.
color indices.
alpha palette.
alpha indices.
| void MinMax | ( | unsigned char * | min, | |
| unsigned char * | max, | |||
| unsigned char * | block | |||
| ) |
clear.
calculate the min/max of the color cube.
calculate the min/max.
is this really even worth it?
calculate the inset of the box.
CAN dstMin + inset be larger than 255? adjust the minimum.
CAN dstMax - inset be negative? adjust the maximum.
adjust the min to ensure that it isn't equal to max.
adjust the max to ensure that it isn't equal to min.


RunsFor individual runs and if regular test reports have been generated click on the run.
Test packagesThis list shows the average pass rate for test packages. For individual package executions click on the package name.
Test modulesThis list shows the average pass rate for test objects/modules. For individual module executions click on the module name.
Test module execution totalsThis is a summary of all executed test in all runs.
|


Step 1: Initialize your algorithm by setting the start date, end date and cash. Then implement the coarse selection of options contracts.
def Initialize(self): self.SetStartDate(2017, 4, 1) self.SetEndDate(2017, 5, 30) self.SetCash(1000000) equity = self.AddEquity("GOOG", Resolution.Minute) option = self.AddOption("GOOG", Resolution.Minute) self.symbol = option.Symbol # set our strike/expiry filter for this option chain option.SetFilter(-10, +10, timedelta(0), timedelta(30)) # use the underlying equity as the benchmark self.SetBenchmark(equity.Symbol)
Step 2: Choose the expiration date for your options traded and break the options into the call and put contracts. The choice of expiration date depends on the holding period of stocks in your portfolio.
def TradeOptions(self,optionchain): for i in optionchain: if i.Key != self.symbol: continue chain = i.Value # choose the furthest expiration date within 30 days from now on expiry = sorted(chain, key = lambda x: x.Expiry)[-1] # filter the call options contracts call = [x for x in chain if x.Right == 0 and x.Expiry == expiry] # filter the put options contracts put = [x for x in chain if x.Right == 1 and x.Expiry == expiry]
Step 3: Choose the deep in-the-money call and put options in the list and then sell the call options and buy the put options.
self.otm_call = sorted(call, key = lambda x: x.Strike)[-1] self.otm_put = sorted(put, key = lambda x: x.Strike)[0] if (self.otm_call is None) or (self.otm_put is None): continue self.Sell(self.otm_call.Symbol, 1) # sell the OTM call self.Buy(self.otm_put.Symbol, 1) # buy the OTM put
Step 4: In OnData, if there are no assets in our portfolio, we buy the undelying stock. After that, we trade the options written on the same number of shares of underlying asset (one option contracts equals 100 undelying shares).
def OnData(self,slice): optionchain = slice.OptionChains for i in slice.OptionChains: if i.Key != self.symbol: continue chains = i.Value contract_list = [x for x in chains] if (slice.OptionChains.Count == 0) or (len(contract_list) == 0): return # if you don't hold options and stocks, buy the stocks and trade the options if not self.Portfolio.Invested: self.Buy("GOOG",100) # buy 100 shares of the underlying stock self.TradeOptions(optionchain) # sell OTM call and buy OTM put


Standard box joints with fingers and slots of equal width.
Standard box joints with a specified number of fingers and slots adjusted to fit within an overall width.
Custom box joint profile. Give the new profile a name below to create the new file, and the profile can be edited on the next screen.


To improve your user experience and data security, we recommend that you use
Google Chrome.
Download Google Chrome:
Click here for users in mainland China
Click here for other users
Please paste the following secure website into your browser's URL bar:


Boston’s Massachusetts Bay Transit Authority (MBTA) operates the 4th busiest subway system in the U.S. after New York, Washington, and Chicago. If you live in or around the city you have probably ridden on it. The MBTA recently began publishing substantial amount of subway data through its public APIs. They provide the full schedule in General Transit Feed Specification (GTFS) format which powers Google’s transit directions. They also publish realtime train locations for the Red, Orange, Blue, and Green lines. The following visualizations use data captured from these feeds for the entire month of February, 2014. Green Line data became available in October, 2014 so is not shown here. Also, working with the MBTA, we were able to acquire per-minute entry and exit counts at each station measured at the turnstiles used for payment.
We attempt to present this information to help people in Boston better understand the trains, how people use the trains, and how the people and trains interact with each other.
In a typical weekday, trains make approximately 1150 trips on the red, orange, and blue lines starting at 5AM and continuing through 1AM the next morning. On Saturdays trains make 870 trips and on Sundays they make 760.
To better understand how the trains operate on a typical day, below are all trips that trains took on the red, orange, and blue lines on Monday February 3 2014. Each vertical line represents a station, and time extends from top to bottom. Steeper lines indicate slower trains. This visualization was first used by Étienne-Jules Marey to visualize train schedules and is typically called a “Marey Diagram.”
| Weekdays | Saturdays | Sundays | |
|---|---|---|---|
| Red | 450 | 350 | 300 |
| Orange | 320 | 260 | 220 |
| Blue | 380 | 260 | 240 |
| Total | 1150 | 870 | 760 |
To better compare the individual trips on this day, the visualization below shows all of the trips from the above diagram juxtaposed with the the starting points lined up so you can see the range of fastest to slowest trips, as well as variation in trip times based on the time of day. The trains slow down a little bit during the morning rush-hour, primarily on the outbound blue line. The afternoon rush-hour is by-far the worst time of day for the red line. The midday lull and evening lull are both fairly consistent. Hover over the time scale on the left to highlight trips during different parts of the day. Click on a line to see all at what time the train was at each stop.
In a typical weekday, 425,000 people enter a station along the red, orange, or blue lines. On weekends and holidays, that number drops to 200,000. The busiest day was Friday February 7 when 470,187 people entered the system.
This heatmap shows the average number of people that enter and exit stations along the red, orange, and blue line for every hour over the entire month based on records from turnstiles at each station. Each row represents one week. You can see weekends and weekdays with daily peaks at rush hour, as well as a holiday, and two snow storms. Our exit data is less reliable since not all stations require that people exit through a turnstile.
The table and map below breaks down February's turnstile entries and exits by station. Hover over a row in the table to highlight the corresponding circle on the map, or vice-versa. Click on a row in the table to show a detailed heatmap for the entrances to and exits from that station over the month. Click and drag on several table rows to highlight a range of stations.
You can see the busiest stations are all along the Red Line. Harvard topped the list, followed close by South Station , and then Downtown Crossing . Next to each station are heatmaps showing entrances and exits to each station per-hour for weekdays and weekends/holidays. You can see that some stations are work stations since their exits peak in the morning and entrances peak in the afternoon and that some stations are home stations since their entrances peak in the morning and exits peak in the afternoon. Some stations are just busy all the time.
When you look back at the Marey diagram, the slope of each line tells you how fast a train is going and the time it takes to get between stations. When all of the start and stop times are lined up you can see a drastic variation in the time it takes to get between stops throughout the day. If you have ever ridden the subway during rush hour then you have experienced what the steep lines in the Marey diagram feel like first-hand.
What causes these delays? It’s hard to know for sure, but it appears that number of people riding the subway is a factor.
This visualization shows congestion and delay on the red, blue, and orange lines for the first full week in February. The gray bands show the total number of entries into the all stations per minute over time for each day of the week. The colored bands below indicate whether the trains are running faster or slower than normal.
The map shows the congestion and delay across the system at a time when you hover over the chart on the right. The thickness of each line at a stop indicates number of entries per minute at that stop, and the color on the right-hand side of a track indicates delay in that direction using the same scale as the colored bands.
You can see basketball games letting out on Monday, Tuesday, Friday, and Sunday. You can also tell that it snowed on Wednesday and people stayed home, especially when you compare how light Wednesday evening's rush hour was compared to Thursday evening's rush hour.
How do all of these factors affect your commute? Click and drag on the map from a starting station to an ending station to see a detailed breakdown of how long that trip takes at different points during a typical workday. The points on top show all of the trip durations for a given starting time from the start to destination and the points on bottom show all of the times between when when trains leave the start station going to the destination station. The time between trains is the longest you would possibly need to wait if you arrived just as the previous train was leaving. The blue band excludes the shortest and longest 10% of all transit times, leaving behind the most-likely 80% range and the orange band does the same for wait times between trains. The dark lines show the middle point where 50% of the time wait/transit times are higher and 50% of the time they are lower.
In general, delays go up during rush hour but trains come more frequently, for example if you look at South Station to Kendall/MIT you will notice that the transit times go up as the wait times go down. If you drag across the chart, the paragraph below will tell you that these effects roughly balance eachother out and the most-likely trip duration (half the normal time between trains plus total transit time) stays constant around 10-12 minutes. It is also interesting to note that transit times on the blue line, for example State St. to Wonderland are much less variable than the red line. Orange line trips like Downtown Crossing to Forest Hills are less variable in transit time - but trains come much less frequently and reliably.
Through publicly available data, we have the tools to understand the subway system better than we ever have before. We have seen how the system operates on a daily basis, how people use the system, how that affects the trains and also how this ties back to your daily commute. To see a live version of this data, check out MBTA Trains for real-time subway delays and real-time commuter rail delays.
This project was created by Michael Barry and Brian Card for a graduate course in Data Visualization at WPI taught by Matthew Ward. Several open-source projects were used under the MIT License including D3, Bootstrap, Glyphicons, Underscore, Moment.js, es6-shim, and D3-tip. Data courtesy of the MBTA and their Developer Relations Program.
Much of the inspiration for this report comes from Bret Victor's Ladder of Abstraction and the works of Edward Tufte and Étienne-Jules Marey.
The source code and raw data are available on github and described in this blog post.
For any questions, please reach out to Michael Barry or Brian Card on Twitter.


{include file="../application/index/view/include/header.html" uname="$userInfo.uname" /}
{include file="../application/index/view/include/left.html" /}
我的课程


{% import "macros.html" as macros %} {% extends "base.html" %} {% block title %}chip's blog things{% endblock title %} {% block head %} {% endblock head %} {% block content %}
A collection of thoughts and ideas I figure are worth spending time writing up.
{{ page.description }}


Another view of the extractor showing the relative position of a frame and the parts mentioned in the previous page. It should be mentioned that this frame is a different one than shown in the last photo.
<Previous Next>
HOME


Local from Ithaki kills 40-year-old man after believing wife was having affair
by GCTPolice have charged a 54-year-old local resident from the island of Ithaki with the murder of a 40-year-old man, originally from Great Britain, after the husband believed his wife was having an affair with the victim.
According to local reports, a fight broke out on Saturday at a hotel in Ithaki, with the assailant viciously bashing the victim in the head and body, resulting in his death.
The violent crime involving the 54-year-old resident of the island and the 40-year-old foreign victim has rocked the island of Ithaki.
Police said the 54-year-old attacked the victim then caught a taxi back to a village north of the island where he lives. The husband is said to have been in a jealous rage, believing that his 42-year-old wife, with whom he has a seven-year-old child was in a long term relationship with the victim.
Reports claim the 40-year-old man, only arrived in Ithaca a few days ago and was found dead at the hotel room where he was staying. Other reports claim that the wife was in the hotel room when the attack occurred and she tried to save the man but was unable to keep him alive until the ambulance arrived.
Locals who knew the couple told Alpha TV that the couple had been having problems with their marriage for some time and the husband was enraged when his wife told him she was planning on leaving the island with their daughter.
Police are continuing the investigation.


148 Appendix B. APL features The book A Programming Language was published by mathematician Kenneth E. Iverson in 1962. He wanted a formal language that would look like what mathematicians write on chalkboards. The then-unnamed language would later take its name from the ﬁrst letters of the words in the book’s title. It was little-known until 1964, when a formal description of the just-announced IBM System/360 in the IBM Systems Journal used APL notation. (Around the same time, Iverson’s associate Adin Falkoff gave a talk on APL to a New York Association for Computing Machinery chapter, with an excited 14-year-old Brian Harvey in the audience.) But it wasn’t until 1966 that the ﬁrst public implementation of the language for the System/360 was published by IBM. (It was called “APL\360” because the normal slash character / represents the “reduce” operator in APL, while backslash is “expand.”) The crucial idea behind APL is that mathematicians think about collections of numbers, one-dimensional vectors and two-dimensional matrices, as valid objects in themselves, what computer scientists later learned to call “ﬁrst class data.” A mathematician who wants to add two vectors writes v1 + v2, not “for i = 1 to length(v1), result[i]=v1[i]+v2[i].” Same for a programmer using APL. There are three kinds of function in APL: scalar functions, mixed functions, and operators. A scalar function is one whose natural domain is individual numbers or text characters. A mixed function is one whose domain includes arrays (vectors, matrices, or higher-dimensional collections). In Snap ! , scalar functions are generally found in the green Operators palette, while mixed functions are in the red Lists palette. The third category, confusingly for Snap ! users, is called operators in APL, but corresponds to what we call higher order functions: functions whose domain includes functions. Snap ! hyperblocks are scalar functions that behave like APL scalar functions: they can be called with arrays as inputs, and the underlying function is applied to each number in the arrays. (If the function is monadic, meaning that it takes one input, then there’s no complexity to this idea. Take the square root of an array, and you are taking the square root of each number in the array. If the function is dyadic, taking two inputs, then the two arrays must have the same shape. Snap ! is more forgiving than APL; if the arrays don’t agree in number of dimensions, called the rank of the array, the lower-rank array is matched repeatedly with subsets of the higher- rank one; if they don’t agree in length along one dimension, the result has the shorter length and some of the numbers in the longer-length array are ignored. An exception in both languages is that if one of the two inputs is a scalar, then it is matched with every number in the other array input.) As explained in Section I.G, this termwise extension of scalar functions is the main APL-like feature built into Snap ! itself. We also include an extension of the item block to address multiple dimensions, an extension to the length block with ﬁve list functions from APL, and a new primitive reshape block. The APL library extends the implementation of APL features to include a few missing scalar functions and several missing mixed functions and operators. Programming in APL really is very different in style from programming in other languages, even Snap ! . This appendix can’t hope to be a complete reference for APL, let alone a tutorial. If you’re interested, ﬁnd one of those in a library or a (probably used) bookstore, read it, and do the exercises. Sorry to sound like a teacher, but the notation is sufﬁciently weird as to take a lot of practice before you start to think in APL. A note on versions: There is a widely standardized APL2, several idiosyncratic extensions, and a successor language named J. The latter uses plain ASCII characters, unlike the ones with APL in their names, which use the mathematician’s character set, with Greek letters, typestyles (boldface and/or italics in books; underlined,


Note:This goal should be used as a Maven report.
Full name:
org.revapi:revapi-maven-plugin:0.15.0:report
Description:
Attributes:
0.1
.site
.| Name | Type | Since | Description |
|---|---|---|---|
<alwaysCheckForReleaseVersion> |
boolean |
0.1 |
If true (the default) revapi will always download the information
about the latest version from the remote repositories (instead of
using locally cached info). This will respect the offline settings. Default value is: true .User property is: revapi.alwaysCheckForReleaseVersion . |
<analysisConfiguration> |
PlexusConfiguration |
0.1 |
The JSON or XML configuration of various analysis options. The
available options depend on what analyzers are present on the
plugin classpath through the <dependencies> .
Consult configuration
documentation for more details.
These settings take precedence over the configuration loaded
from |
<analysisConfigurationFiles> |
Object[] |
0.1 |
The list of files containing the configuration of various analysis
options. The available options depend on what analyzers are present
on the plugins classpath through the
<dependencies> .
The The list is either a list of strings or has the following form:
path or resource has to be
specified but not both. The configuration/root1 and
configuration/root2 are paths to the roots of the
configuration inside that JSON/XML config file. This might be used
in cases where multiple configurations are stored within a single
file and you want to use a particular one.
An example of this might be a config file which contains API changes to be ignored in all past versions of a library. The classes to be ignored are specified in a configuration that is specific for each version:
User property is: revapi.analysisConfigurationFiles . |
<checkDependencies> |
boolean |
0.1 |
Whether to include the dependencies in the API checks. This is the
default thing to do because your API might be exposing classes from
the dependencies and thus classes from your dependencies could
become part of your API.
However, setting this to false might be useful in situations where you have checked your dependencies in another module and don't want do that again. In that case, you might want to configure Revapi to ignore missing classes because it might find the classes from your dependencies as used in your API and would complain that it could not find it. See the docs. Default value is: true .User property is: revapi.checkDependencies . |
<disallowedExtensions> |
String |
0.1 |
A comma-separated list of extensions (fully-qualified class names
thereof) that are not taken into account during API analysis. By
default, all extensions that are found on the classpath are used.
You can modify this set if you use another extensions that change the found differences in a way that the determined new version would not correspond to what it should be. User property is: revapi.disallowedExtensions . |
<expandProperties> |
boolean |
0.11.6 |
If set to true, the Maven properties will be expanded in the
configuration before it is supplied to Revapi. I.e. any
${var } appearing in the configuration values
will be replaced with the value of the var property as
known to Maven. If the property is not defined, the expansion
doesn't take place.Default value is: false .User property is: revapi.expandProperties . |
<failOnMissingConfigurationFiles> |
boolean |
0.1 |
Set to false if you want to tolerate files referenced in the
analysisConfigurationFiles missing on the filesystem
and therefore not contributing to the analysis configuration.
The default is Default value is: true .User property is: revapi.failOnMissingConfigurationFiles . |
<failOnUnresolvedArtifacts> |
boolean |
0.1 |
If true, the build will fail if one of the old or new artifacts
fails to be resolved. Defaults to false. Default value is: false .User property is: revapi.failOnUnresolvedArtifacts . |
<failOnUnresolvedDependencies> |
boolean |
0.1 |
If true, the build will fail if some of the dependencies of the old
or new artifacts fail to be resolved. Defaults to false. Default value is: false .User property is: revapi.failOnUnresolvedDependencies . |
<generateSiteReport> |
boolean |
0.1 |
Set this to false if you want to use the goal to generate other
kind of output than the default report for the Maven-generated
site. You can generate such output by using different reporting
extensions (like revapi-reporter-text). Default value is: true .User property is: revapi.generateSiteReport . |
<newArtifacts> |
String[] |
0.1 |
The coordinates of the new artifacts. These are the full GAVs of
the artifacts, which means that you can compare different artifacts
than the one being built. If you merely want to specify the
artifact being built, use newVersion property instead.User property is: revapi.newArtifacts . |
<newPromotedDependencies> |
PromotedDependency[] |
0.13.6 |
A list of dependencies of the new artifact(s) that should be
considered part of the new API. |
<newVersion> |
String |
0.1 |
The new version of the artifact. Defaults to "${project.version}". Default value is: ${project.version} .User property is: revapi.newVersion . |
<oldArtifacts> |
String[] |
0.1 |
The coordinates of the old artifacts. Defaults to single artifact
with the latest released version of the current project.
If the this property is null, the User property is: revapi.oldArtifacts . |
<oldPromotedDependencies> |
PromotedDependency[] |
0.13.6 |
A list of dependencies of the old artifact(s) that should be
considered part of the old API. |
<oldVersion> |
String |
0.1 |
If you don't want to compare a different artifact than the one
being built, specifying the just the old version is simpler way of
specifying the old artifact.
The default value is "RELEASE" meaning that the old version is the last released version of the artifact being built. Default value is: RELEASE .User property is: revapi.oldVersion . |
<pipelineConfiguration> |
PlexusConfiguration |
0.11.0 |
The JSON or XML configuration of the extensions pipeline. This
enables the users easily specify which extensions should be
included/excluded in the Revapi analysis pipeline and also to
define transformation blocks - a way of grouping transforms
together to enable more fine grained control over how differences
are transformed. |
<promotedDependencies> |
PromotedDependency[] |
0.13.6 |
A list of dependencies of both the old and new artifact(s) that
should be considered part of the old/new API. This is a convenience
property if you just need to specify a set of dependencies to
promote into the API and that set can be specified in a way common
to both old and new APIs. If you need to specify different sets for
the old and new, use oldPromotedDependencies or
newPromotedDependencies respectively. If
oldPromotedDependencies or
newPromotedDependencies are specified, they override
whatever is specified using this property.
The individual properties of the dependency (e.g.
E.g. |
<reportCriticality> |
String |
0.1 |
The minimum criticality of the differences that should be included
in the report. This has to be one of the criticalities configured
in the pipeline configuration (if the pipeline configuration
doesn't define any, the following are the default ones:
allowed , documented ,
highlight , error ). If not defined, the
value is derived from reportSeverity using the
severity-to-criticality mapping (which is again configured in the
pipeline configuration. If not defined in the pipeline
configuration explicitly, the default mapping is the following:
EQUIVALENT = allowed ,
NON_BREAKING = documented ,
POTENTIALLY_BREAKING = error ,
BREAKING = error.User property is: revapi.minimumCriticality . |
<reportSeverity> |
FailSeverity |
0.1 |
Deprecated. use reportCriticality insteadDefault value is: potentiallyBreaking .User property is: revapi.reportSeverity . |
<resolveProvidedDependencies> |
boolean |
0.1 |
When establishing the API classes, Revapi by default also looks
through the provided dependencies. The reason for this
is that even though such dependencies do not appear in the
transitive dependency set established by maven, they need to be
present both on the compilation and runtime classpath of the
module. Therefore, the classes in the module are free to expose
classes from a provided dependency as API elements.
In rare circumstances this is not a desired behavior though. It is undesired if for example the classes from the provided dependency are used only for establishing desired build order or when they are used in some non-standard scenarios during the build and actually not needed at runtime. Note that this property only influences the resolution of
provided dependencies of the main artifacts, not the transitively
reachable provided dependencies. For those, use the
Default value is: true .User property is: revapi.resolveProvidedDependencies . |
<resolveTransitiveProvidedDependencies> |
boolean |
0.1 |
In addition to resolveProvidedDependencies this
property further controls how provided dependencies are resolved.
Using this property you can control how the indirect, transitively
reachable, provided dependencies are treated. The default is to not
consider them, which is almost always the right thing to do. It
might be necessary to set this property to true in the
rare circumstances where the API of the main artifacts includes
types from such transitively included provided dependencies. Such
occurrence will manifest itself by Revapi considering such types as
missing (which is by default reported as a potentially breaking
change). When you then resolve the transitive provided dependencies
(by setting this parameter to true), Revapi will be able to find
such types and do a proper analysis of them.Default value is: false .User property is: revapi.resolveTransitiveProvidedDependencies . |
<skip> |
boolean |
0.1 |
Whether to skip the mojo execution. Default value is: false .User property is: revapi.skip . |
<versionFormat> |
String |
0.1 |
If set, this property demands a format of the version string when
the oldVersion or newVersion parameters
are set to RELEASE or LATEST special
version strings.
Because Maven will report the newest non-snapshot version as the
latest release, we might end up comparing a This parameter is a regular expression pattern that the version
string needs to match in order to be considered a
User property is: revapi.versionFormat . |
boolean
0.1
No
revapi.alwaysCheckForReleaseVersion
true
<dependencies>
.
Consult configuration
documentation for more details.
These settings take precedence over the configuration loaded
from analysisConfigurationFiles
.
org.codehaus.plexus.configuration.PlexusConfiguration
0.1
No
<dependencies>
.
The analysisConfiguration
can override the settings
present in the files.
The list is either a list of strings or has the following form:
<analysisConfigurationFiles>
<configurationFile>
<path>path/to/the/file/relative/to/project/base/dir</path>
<resource>path/to/the/file/in/one/of/the/dependencies</resource>
<roots>
<root>configuration/root1</root>
<root>configuration/root2</root>
...
</roots>
</configurationFile>
...
</analysisConfigurationFiles>
path
is the path on the filesystem,resource
is the path to the resource file in one
of the artifacts the plugin depends onroots
is optional and specifies the subtrees of
the JSON/XML config that should be used for configuration. If not
specified, the whole file is taken into account.path
or resource
has to be
specified but not both. The configuration/root1
and
configuration/root2
are paths to the roots of the
configuration inside that JSON/XML config file. This might be used
in cases where multiple configurations are stored within a single
file and you want to use a particular one.
An example of this might be a config file which contains API changes to be ignored in all past versions of a library. The classes to be ignored are specified in a configuration that is specific for each version:
{
"0.1.0" : [
{
"extension": "revapi.ignore",
"configuration": [
{
"code" : "java.method.addedToInterface",
"new" : "method void com.example.MyInterface::newMethod()",
"justification" : "This interface is not supposed to be implemented by clients."
},
...
]
}
],
"0.2.0" : [
...
]
}
java.lang.Object[]
0.1
No
revapi.analysisConfigurationFiles
However, setting this to false might be useful in situations where you have checked your dependencies in another module and don't want do that again. In that case, you might want to configure Revapi to ignore missing classes because it might find the classes from your dependencies as used in your API and would complain that it could not find it. See the docs.
boolean
0.1
No
revapi.checkDependencies
true
You can modify this set if you use another extensions that change the found differences in a way that the determined new version would not correspond to what it should be.
java.lang.String
0.1
No
revapi.disallowedExtensions
${var
} appearing in the configuration values
will be replaced with the value of the var
property as
known to Maven. If the property is not defined, the expansion
doesn't take place.boolean
0.11.6
No
revapi.expandProperties
false
analysisConfigurationFiles
missing on the filesystem
and therefore not contributing to the analysis configuration.
The default is true
, which means that a missing
analysis configuration file will fail the build.
boolean
0.1
No
revapi.failOnMissingConfigurationFiles
true
boolean
0.1
No
revapi.failOnUnresolvedArtifacts
false
boolean
0.1
No
revapi.failOnUnresolvedDependencies
false
boolean
0.1
No
revapi.generateSiteReport
true
newVersion
property instead.java.lang.String[]
0.1
No
revapi.newArtifacts
org.revapi.maven.PromotedDependency[]
0.13.6
No
java.lang.String
0.1
No
revapi.newVersion
${project.version}
If the this property is null, the oldVersion
property is checked for a value of the old version of the artifact
being built.
java.lang.String[]
0.1
No
revapi.oldArtifacts
org.revapi.maven.PromotedDependency[]
0.13.6
No
The default value is "RELEASE" meaning that the old version is the last released version of the artifact being built.
java.lang.String
0.1
No
revapi.oldVersion
RELEASE
org.codehaus.plexus.configuration.PlexusConfiguration
0.11.0
No
oldPromotedDependencies
or
newPromotedDependencies
respectively. If
oldPromotedDependencies
or
newPromotedDependencies
are specified, they override
whatever is specified using this property.
The individual properties of the dependency (e.g.
groupId
, artifactId
,
version
, type
or classifier
)
are matched exactly. If you enclose the value in forward slashes,
they are matched as regular expressions instead.
E.g. <groupId>com.acme</groupId>
will
only match dependencies with that exact groupId
, while
<groupId>/com\.acme(\..*)?/</groupId>
will
match "com.acme" groupId
or any "sub-groupId" thereof
(e.g. "com.acme.utils", etc.) using a regular expression.
org.revapi.maven.PromotedDependency[]
0.13.6
No
allowed
, documented
,
highlight
, error
). If not defined, the
value is derived from reportSeverity
using the
severity-to-criticality mapping (which is again configured in the
pipeline configuration. If not defined in the pipeline
configuration explicitly, the default mapping is the following:
EQUIVALENT
= allowed
,
NON_BREAKING
= documented
,
POTENTIALLY_BREAKING
= error
,
BREAKING
= error.java.lang.String
0.1
No
revapi.minimumCriticality
reportCriticality
insteadorg.revapi.maven.FailSeverity
0.1
No
revapi.reportSeverity
potentiallyBreaking
provided
dependencies. The reason for this
is that even though such dependencies do not appear in the
transitive dependency set established by maven, they need to be
present both on the compilation and runtime classpath of the
module. Therefore, the classes in the module are free to expose
classes from a provided dependency as API elements.
In rare circumstances this is not a desired behavior though. It is undesired if for example the classes from the provided dependency are used only for establishing desired build order or when they are used in some non-standard scenarios during the build and actually not needed at runtime.
Note that this property only influences the resolution of
provided dependencies of the main artifacts, not the transitively
reachable provided dependencies. For those, use the
resolveTransitiveProvidedDependencies
parameter.
boolean
0.1
No
revapi.resolveProvidedDependencies
true
resolveProvidedDependencies
this
property further controls how provided dependencies are resolved.
Using this property you can control how the indirect, transitively
reachable, provided dependencies are treated. The default is to not
consider them, which is almost always the right thing to do. It
might be necessary to set this property to true
in the
rare circumstances where the API of the main artifacts includes
types from such transitively included provided dependencies. Such
occurrence will manifest itself by Revapi considering such types as
missing (which is by default reported as a potentially breaking
change). When you then resolve the transitive provided dependencies
(by setting this parameter to true), Revapi will be able to find
such types and do a proper analysis of them.boolean
0.1
No
revapi.resolveTransitiveProvidedDependencies
false
boolean
0.1
No
revapi.skip
false
oldVersion
or newVersion
parameters
are set to RELEASE
or LATEST
special
version strings.
Because Maven will report the newest non-snapshot version as the
latest release, we might end up comparing a .Beta
or
other pre-release versions with the new version. This might not be
what you want and setting the versionFormat will make sure that a
newest version conforming to the version format is used instead of
the one resolved by Maven by default.
This parameter is a regular expression pattern that the version
string needs to match in order to be considered a
RELEASE
.
java.lang.String
0.1
No
revapi.versionFormat


{# This template will display whenever a 404 Not Found error is thrown. You won't see this template when Dev Mode is on, however. To see it while Dev Mode is on, go to `yoursite.test/404` See: https://docs.craftcms.com/v3/routing.html #} {% extends "_private/layout" %} {% block content %}
The page you’re looking for can’t be found. Go to the home page?
{% endblock %}


Get your pizza delivered to you any where any time with pizza pap app
You simply click on the order button of the toppings that you want.
When you want to choose a size,please
fill in the number assigned to the size you need eg 1-small.type 1 for the small size option.
keep adding
to your list.
When you are done click on delivery or pick up option,
On delivery please enter your
location.
Complete the order by clicking the total cost button that will show all cost including
delivery.
THANK YOU FOR TRUSTING US.


1. Introduction¶
A Claim is the process of a worker checking out a message to perform a task. Claiming a message prevents other workers from attempting to process the same messages.
2. Setup¶
A Claim is initialized on its parent object, a Queue:
// To initialize an empty object:
$claim = $queue->getClaim();
// or retrieve a specific claim:
$claim = $queue->getClaim('51db7067821e727dc24df754');
3. Claim messages¶
3.1 Description¶
This operation claims a set of messages (up to the value of the limit parameter) from oldest to newest and skips any messages that are already claimed. If no unclaimed messages are available, the API returns a 204 No Content message.
When a client (worker) finishes processing a message, it should delete the message before the claim expires to ensure that the message is processed only once. As part of the delete operation, workers should specify the claim ID (which is best done by simply using the provided href). If workers perform these actions, then if a claim simply expires, the server can return an error and notify the worker of the race condition. This action gives the worker a chance to roll back its own processing of the given message because another worker can claim the message and process it.
The age given for a claim is relative to the server’s clock. The claim’s age is useful for determining how quickly messages are getting processed and whether a given message’s claim is about to expire.
When a claim expires, it is released. If the original worker failed to process the message, another client worker can then claim the message.
3.2 Attributes¶
The ttl attribute specifies how long the server waits before releasing the claim. The ttl value must be between 60 and 43200 seconds (12 hours). You must include a value for this attribute in your request.
The grace attribute specifies the message grace period in seconds. The value of grace value must be between 60 and 43200 seconds (12 hours). You must include a value for this attribute in your request. To deal with workers that have stopped responding (for up to 1209600 seconds or 14 days, including claim lifetime), the server extends the lifetime of claimed messages to be at least as long as the lifetime of the claim itself, plus the specified grace period. If a claimed message would normally live longer than the grace period, its expiration is not adjusted.
The limit attribute specifies the number of messages to return, up to 20 messages. If limit is not specified, limit defaults to 10. The limit parameter is optional.
3.3 Code¶
use OpenCloud\Common\Constants\Datetime;
$queue->claimMessages(array(
'limit' => 15,
'grace' => 5 * Datetime::MINUTE,
'ttl' => 5 * Datetime::MINUTE
));
4. Query claim¶
4.1 Description¶
This operation queries the specified claim for the specified queue. Claims with malformed IDs or claims that are not found by ID are ignored.
4.2 Attributes¶
Claim ID.
4.3 Code¶
$claim = $queue->getClaim('51db7067821e727dc24df754');
5. Update claim¶
5.1 Description¶
This operation updates the specified claim for the specified queue. Claims with malformed IDs or claims that are not found by ID are ignored.
Clients should periodically renew claims during long-running batches of work to avoid losing a claim while processing a message. The client can renew a claim by executing this method on a specific Claim and including a new TTL. The API will then reset the age of the claim and apply the new TTL.
5.2 Attributes¶
See section 4.2.
5.3 Code¶
use OpenCloud\Common\Constants\Datetime;
$claim->update(array(
'ttl' => 10 * Datetime::MINUTE
));
6. Release claim¶
6.1 Description¶
This operation immediately releases a claim, making any remaining undeleted messages that are associated with the claim available to other workers. Claims with malformed IDs or claims that are not found by ID are ignored.
This operation is useful when a worker is performing a graceful shutdown, fails to process one or more messages, or is taking longer than expected to process messages, and wants to make the remainder of the messages available to other workers.
6.2 Attributes¶
See section 4.2.
6.3 Code¶
$message->delete();


8 December 2010 - The Ministry of Health of Egypt has announced a new case of human infection of H5N1 avian influenza. A 30-year-old female from Gharbia Governorate, developed symptoms on 28 November, was hospitalized on 1st of December, where she received oseltamivir treatment, and died on 2nd of December.
Investigations into the source of infection indicated that the case had exposure to sick and dead poultry.
The case was confirmed by the Egyptian Central Public Health Laboratories, a National Influenza Center of the WHO Global Influenza Surveillance Network (GISN).
Of the 113 cases confirmed to date in Egypt, 37 have been fatal.


HIRedux Setup
Organize and Compress the Data
- Create a new directory for the night (e.g. 08sep04) and enter it
- Create a 'Raw/' directory and put all the raw data in it.
- gzip the data as necessary
unix> gzip *.fits
- Launch idl in the directory above Raw/
unix> idl -32 (or idlde -32)
Create/Edit the Structure
- hires_strct :: Create the HIRES structure.
- This structure organizes
the entire night of data and is the most important file created.
- The routine creates a few things:
- An IDL structure in memory with whatever name you choose (e.g. hires).
Here is a copy of the file which
defines the structure and lists the tags.
- The file 'hiresstrct.fits' which is a fits
version of the structure;
- The file 'hires.list' which is an ASCII
version of the fits file which lists the values of some of the tags.
- If you run with /EDIT the program will launch a
gui which allows some editing of the hires structure
(see next step).
We recommend you use an IDL script to do the
editing. It will save time if you have to start over from scratch
and
it gives a permanent record of what you changed.
Example: IDL> hires_strct, hires, [/EDIT]
Time : <1s per image
- You know the code is working properly when:
- It runs through the completion after checking each Raw file
- The majority of files are correctly identified by type. Note the
code will not get them all right all of the time. We typically create
a script like this one to set a number of the tags.
- Recommended: Edit the structure with a script
hires_strct creates the structure and takes a guess at the
initial values of many of the tags based on the header card info. It
is difficult, however, to automate all of the values for the tags and
therefore the user should carefully check the structure. Also, the
user should set flg_anly = 0 for all of images which should
be ignored during data reduction (bad flats, tests, etc.). For most of
the important tags, one can use hires_editstrct. The rest must
be done from the command line by hand or through a simple
IDL script (recommended). The obvious tags to modify are:
- hires_editstrct
:: Modify the HIRES structure. See above
- Obj :: Object name (this propagates into the final spectra
and should have no spaces!)
- flg_anly :: Include in analysis (defaulted to 1 for yes)
- type :: ARC, TFLT, MFLT, TWI, OBJ, STD, ZRO, etc.
- setup :: 1L, 2L, etc. (unique integer for each instrument
setup including slit width)
Example: IDL> hires_editstrct, hires
Time : User interaction
Example: IDL> set_crds, hires
(see doc/set_crds.pro for an example)
- You know the code is working right when the GUI appears.
- hires_updstrct
:: Append new files to the current structure.
This is mainly useful at the telescope as you are taking new data.
The code simply searches the Raw directory, notes any new files,
and adds them to the structure.
Example: IDL> hires_updstrct, hires
Time : Fast
- You know the code is working right when it finds the files.
- hires_wrstrct ::
Write the HIRES structure to disk. In IDL you can modify the values
of any of the tags. You can then save the structure in fits form and
rewrite the ASCII file with the routine hires_wrstrct.
Example: IDL> hires_wrstrct, hires, FITS='hires_name.fits'
Time : fast
- If you exit (or crash) IDL, you will need to read the structure back in.
hires_ar ::
Read the HIRES structure from disk.
If no name is given, the file looks for the first fits
file starting 'hires' that contains a '_'.
Example: IDL> hires = hires_ar()
Example: IDL> hires = hires_ar('hires_name.fits')
Time : fast
- You know the code is working right when
IDL> help, hires, /str ---- lists the structure.
Setup
- A unique setup is defined by the slit width, the binning, the
angles of the echelle and cross-disperser, the blocking filter, and the
cross-dispersor (UV or RED).
Obviously, each setup requires its own set of calibration files.
- It is important to make sure the objects are properly named
at this point. At the least, multiple exposures of the same object
should have identical object name (tag: hires.obj).
- hires_setup ::
This routine examines the hires structure and looks for calibration
files associated with the various setups.
It groups together exposures with identical Obj name (hires.obj) and
sets the obj_id tags accordingly.
A list of the setups and the corresponding files is put
in 'hires_summ.txt'. See 'setup_summ.txt' for a very brief
listing.
- Note: With v2.0 it is highly recommended that you only run this
program once. The calibration files produced by the pipeline have the
setup# as a tag and rerunning hires_setup could compromise things.
Example: IDL> hires_setup, hires
Time : Fast
- You know the code is working right when you
check the output file 'hires_summ.txt' and everything is
properly setup. Modify the obj_id and other tags and rerun
hires_setup as necessary.
- Perhaps the main failure mode of this routine is when the cross-disperser
angle floats between exposures. Right now the default tolerance is 0.0015
for the angle. So if your exposures differ by more than this, the code will
assign unique setup values. You can override this limit by increasing the
XTOLER parameter.
Last modified 2005-10-10


"A wall divided horizontally and vertically into four equal parts. Within each part, three of the four kinds of lines are superimposed."
Implemented by Paul Smith, 2016
HTML, CSS and JavaScript with D3.js
Other interpretations of LeWitt's Wall Drawing #11 seek symmetry in patterns of grid-like repeated lines. This one instead embraces all four distinct combinations of "three of the four kinds of lines", and replaces the license to add repitition (which creates a unified pattern out of the four quandrants) with a license to add color (which distinguishes the four separate figures).


vignettes/docker.Rmd
docker.Rmd
In progress
In this tutorial, we will go through ways to
There are many fun ways to do it, here I am more focused for R developers.
Before you create any, make sure you don’t re-invent the wheel and use the best base image for your container as your tool chain may save your lots of time later on.
Official R Docker images is called “Rocker”" project and is on GitHub, please visit the page to find more details and Dockerfile.
| Image | Description |
|---|---|
rocker/r-base |
base package to build from |
rocker/r-devel |
base + R-devel from SVN |
rocker/rstudio |
base + RStudio Server |
rocker/hadleyverse |
rstudio + Hadley’s packages, LaTeX |
rocker/ropensci |
hadleyverse + rOpenSci packages |
rocker/r-devel-san |
base, SVN’s R-devel and SAN |
Bioconductor have a nice page about the official Docker images, please read for more details.
| Image (release branch) | Image (development branch) |
|---|---|
bioconductor/release_base |
bioconductor/devel_base |
bioconductor/release_core |
bioconductor/devel_core |
bioconductor/release_flow |
bioconductor/devel_flow |
bioconductor/release_microarray |
bioconductor/devel_microarray |
bioconductor/release_proteomics |
bioconductor/devel_proteomics |
bioconductor/release_sequencing |
bioconductor/devel_sequencing |
bioconductor/release_metabolomics |
bioconductor/devel_metabolomics |
To understand the image quickly here is the short instruction for the image name:
release images are based on rocker/rstudio
devel images are based on rocker/rstudio-daily
base: Contains R, RStudio, and system dependencies.
core: base + a selection of core packages.
flow: core + all packages tagged with the FlowCytometry biocView.
microarray: core + all packages tagged with the Microarray biocView.
proteomics: core + all packages tagged with the Proteomics biocView.
sequencing: core + all packages tagged with the Sequencing biocView.
metabolomics: core + all packages tagged with the Metabolomics biocView.
Docker Hub also provide public/private repos, you can search existing tools without building yourself, it’s very likely some popular tool already have Docker container well maintained there.
Our goal here is to making a CWL app to generate uniform random numbers, yes, the core function is runif()
, it’s a native function in R.
dput(runif)
## function (n, min = 0, max = 1)
## .Call(C_runif, n, min, max)
## [1] 0.985688783 0.412628483 0.429539246 0.419172236 0.426506559 0.887797565
## [7] 0.006096034 0.081215761 0.288657362 0.765342145
docopt
PackageIn R, we also have a nice implementation in a package called docopt
, developed by Edwin de Jonge. Check out its tutorial on GitHub.
So let’s quickly create a command line interface for our R scripts with a dummy example. Let’s turn the uniform distribution function runif
into a command line tool.
when you check out the help page for runif
, here is the key information you want to markdown.
Usage
runif(n, min = 0, max = 1)
Arguments
n
number of observations. If length(n) > 1, the length is taken to be the number required.
min, max
lower and upper limits of the distribution. Must be finite.
I will add one more parameter to set seed, here is the R script file called runif.R
.
At the beginning of the command line script, I use the docopt standard to write my tool help.
"usage: runif.R [--n=<int> --min=<float> --max=<float> --seed=<float>]\n\noptions:\n --n=<int> number of observations. If length(n) > 1, the length is taken to be the number required [default: 1].\n --min=<float> lower limits of the distribution. Must be finite [default: 0].\n --max=<float> upper limits of the distribution. Must be finite [default: 1].\n --seed=<float> seed for set.seed() function [default: 1]" -> doc library("docopt")
Let’s first do some testing in your R session before you make it a full functional command line tool.
docopt(doc) # with no argumetns provided
## List of 8
## $ --n : chr "1"
## $ --min : chr "0"
## $ --max : chr "1"
## $ --seed: chr "1"
## $ n : chr "1"
## $ min : chr "0"
## $ max : chr "1"
## $ seed : chr "1"
## NULL
docopt(doc, "--n 10 --min=3 --max=5")
## List of 8
## $ --n : chr "10"
## $ --min : chr "3"
## $ --max : chr "5"
## $ --seed: chr "1"
## $ n : chr "10"
## $ min : chr "3"
## $ max : chr "5"
## $ seed : chr "1"
## NULL
Looks like it works, now let’s add main function script for this command line tool.
opts <- docopt(doc) set.seed(opts$seed) runif( n = as.integer(opts$n), min = as.numeric(opts$min), max = as.numeric(opts$max) )
## [1] 0.2655087
Add Shebang at the top of the file, this is a complete example for runif.R
command line will be like this
#!/usr/bin/Rscript "usage: runif.R [--n=<int> --min=<float> --max=<float> --seed=<float>]\n\noptions:\n --n=<int> number of observations. If length(n) > 1, the length is taken to be the number required [default: 1].\n --min=<float> lower limits of the distribution. Must be finite [default: 0].\n --max=<float> upper limits of the distribution. Must be finite [default: 1].\n --seed=<float> seed for set.seed() function [default: 1]" -> doc library("docopt") opts <- docopt(doc) set.seed(opts$seed) runif( n = as.integer(opts$n), min = as.numeric(opts$min), max = as.numeric(opts$max) )
Let’s test this command line.
$ runif.R --help
Loading required package: methods
usage: runif.R [--n=<int> --min=<float> --max=<float> --seed=<float>]
options:
--n=<int> number of observations. If length(n) > 1, the length is taken to be the number required [default: 1].
--min=<float> lower limits of the distribution. Must be finite [default: 0].
--max=<float> upper limits of the distribution. Must be finite [default: 1].
--seed=<float> seed for set.seed() function [default: 1]
$ runif.R
Loading required package: methods
[1] 0.2655087
$ runif.R
Loading required package: methods
[1] 0.2655087
$ runif.R --seed=123 --n 10 --min=1 --max=100
Loading required package: methods
[1] 29.470174 79.042208 41.488715 88.418723 94.106261 5.510093 53.282443
[8] 89.349485 55.592066 46.204859
For full example you can check my GitHub example.
commandArgs
(Position and Named Args)For advanced users, please read another tutorial “Creating Your Docker Container and Command Line Interface (with docopt)”, “docopt” is more formal way to construct your command line interface, but there is a quick way to make command line interface here using just commandArgs
.
Suppose I already have a R script like this using position mapping the arguments
numbers
min
max
fl <- system.file("docker/sevenbridges/src", "runif2spin.R", package = "sevenbridges") cat(readLines(fl), sep = "\n")
#' ---
#' title: "Uniform random number generator example"
#' output:
#' html_document:
#' toc: true
#' number_sections: true
#' ---
#' # summary report
#'
#' This is a random number generator
#+
args = commandArgs(TRUE)
r = runif(n = as.integer(args[1]),
min = as.numeric(args[2]),
max = as.numeric(args[3]))
head(r)
summary(r)
hist(r)
Ignore the comment part, I will introduce spin/stich later. My base command will be something like
Rscript runif2spin.R 10 30 50
I just describe my tool in this way
library("sevenbridges") fd <- fileDef( name = "runif.R", content = readr::read_file(fl) ) rbx <- Tool( id = "runif", label = "runif", hints = requirements(docker(pull = "rocker/r-base"), cpu(1), mem(2000)), requirements = requirements(fd), baseCommand = "Rscript runif.R", stdout = "output.txt", inputs = list( input( id = "number", type = "integer", position = 1 ), input( id = "min", type = "float", position = 2 ), input( id = "max", type = "float", position = 3 ) ), outputs = output(id = "random", glob = "output.txt") )
Now copy-paste the JSON into your project app and run it in the cloud to test it
How about named arguments? I will still recommend use “docopt” package, but for simple way.
fl <- system.file("docker/sevenbridges/src", "runif_args.R", package = "sevenbridges") cat(readLines(fl), sep = "\n")
#' ---
#' title: "Uniform random number generator example"
#' output:
#' html_document:
#' toc: true
#' number_sections: true
#' ---
#' # summary report
#'
#' This is a random number generator
#+
args <- commandArgs(TRUE)
## quick hack to split named arguments
splitArgs <- function(x) {
res <- do.call(rbind, lapply(x, function(i){
res <- strsplit(i, "=")[[1]]
nm <- gsub("-+", "",res[1])
c(nm, res[2])
}))
.r <- res[,2]
names(.r) <- res[,1]
.r
}
args <- splitArgs(args)
#+
r <- runif(n = as.integer(args["n"]),
min = as.numeric(args["min"]),
max = as.numeric(args["max"]))
summary(r)
hist(r)
write.csv(r, file = "out.csv")
Rscript runif_args.R --n=10 --min=30 --max=50
I just describe my tool in this way, note, I use separate=FALSE
and add =
to my prefix as a hack.
fd <- fileDef( name = "runif.R", content = readr::read_file(fl) ) rbx <- Tool( id = "runif", label = "runif", hints = requirements(docker(pull = "rocker/r-base"), cpu(1), mem(2000)), requirements = requirements(fd), baseCommand = "Rscript runif.R", stdout = "output.txt", inputs = list( input( id = "number", type = "integer", separate = FALSE, prefix = "--n=" ), input( id = "min", type = "float", separate = FALSE, prefix = "--min=" ), input( id = "max", type = "float", separate = FALSE, prefix = "--max=" ) ), outputs = output(id = "random", glob = "output.txt") )
Alternative, you can use spin/stich from knitr to generate report directly from an R script with special format. For example, let’s use the above example
fl <- system.file("docker/sevenbridges/src", "runif_args.R", package = "sevenbridges") cat(readLines(fl), sep = "\n")
#' ---
#' title: "Uniform random number generator example"
#' output:
#' html_document:
#' toc: true
#' number_sections: true
#' ---
#' # summary report
#'
#' This is a random number generator
#+
args <- commandArgs(TRUE)
## quick hack to split named arguments
splitArgs <- function(x) {
res <- do.call(rbind, lapply(x, function(i){
res <- strsplit(i, "=")[[1]]
nm <- gsub("-+", "",res[1])
c(nm, res[2])
}))
.r <- res[,2]
names(.r) <- res[,1]
.r
}
args <- splitArgs(args)
#+
r <- runif(n = as.integer(args["n"]),
min = as.numeric(args["min"]),
max = as.numeric(args["max"]))
summary(r)
hist(r)
write.csv(r, file = "out.csv")
You command is something like this
Rscript -e "rmarkdown::render(knitr::spin('runif_args.R', FALSE))" --args --n=100 --min=30 --max=50
And so I describe my tool like this with Docker image rocker/hadleyverse
this contains knitr and rmarkdown package.
fd <- fileDef( name = "runif.R", content = readr::read_file(fl) ) rbx <- Tool( id = "runif", label = "runif", hints = requirements(docker(pull = "rocker/hadleyverse"), cpu(1), mem(2000)), requirements = requirements(fd), baseCommand = "Rscript -e \"rmarkdown::render(knitr::spin('runif.R', FALSE))\" --args", stdout = "output.txt", inputs = list( input( id = "number", type = "integer", separate = FALSE, prefix = "--n=" ), input( id = "min", type = "float", separate = FALSE, prefix = "--min=" ), input( id = "max", type = "float", separate = FALSE, prefix = "--max=" ) ), outputs = list( output(id = "stdout", type = "file", glob = "output.txt"), output(id = "random", type = "file", glob = "*.csv"), output(id = "report", type = "file", glob = "*.html") ) )
You will get a report in the end.
We cannot really make a R Markdown file executable in it by simply put
#!/bin/bash/Rscript
In your markdown document.
Of course, we can figure out a way to do it in liftr
or knitr
. But R Markdown allow you to pass parameters to your R Markdown template, please read this tutorial Parameterized Reports. This doesn’t solve my problem that I want to directly describe command line interface in the markdown template. However, here is alternative method:
Create an command line interface to pass params
from docopt into rmarkdown::render()
function. In this way, we can pass as many as possible parameters from command line interface into our R Markdown template.
So here we go, here is updated methods and it’s also what I use for another tutorial about RNA-seq workflow.
fl <- system.file("docker/sevenbridges/src/", "runif.R", package = "sevenbridges")
Here is the current content of command line interface
#!/usr/local/bin/Rscript
'usage: runif.R [--n=<int> --min=<float> --max=<float> --seed=<float>]
options:
--n=<int> number of observations. If length(n) > 1, the length is taken to be the number required [default: 1].
--min=<float> lower limits of the distribution. Must be finite [default: 0].
--max=<float> upper limits of the distribution. Must be finite [default: 1].
--seed=<float> seed for set.seed() function [default: 1]' -> doc
library("docopt")
opts <- docopt(doc)
# create param list
lst <- list(
n = as.integer(opts$n),
min = as.numeric(opts$min),
max = as.numeric(opts$max),
seed = as.numeric(opts$seed)
)
# execute your Rmarkdown with these parameters
rmarkdown::render("/report/report.Rmd", rmarkdown::html_document(toc = TRUE), output_dir = ".", params = lst)
And here is the report template
---
title: "Uniform random number generator example"
output:
rmarkdown::html_document:
toc: true
number_sections: true
css: style.css
params:
seed: 1
n: 1
min: 0
max: 1
---
## Summary
```{r}
set.seed(params$seed)
r <- runif(
n = as.integer(params$n),
min = as.numeric(params$min),
max = as.numeric(params$max)
)
summary(r)
hist(r)
```
To make things more reproducible and explicit and automatic, you can do a autohook to automatically build your container/image on Docker Hub. Here is what I do
tengfei/runif
.


"{{quote.quoteName}}" Name - {{quote.personName}} Author - {{quote.authorName}} Uploaded {{quote.dateCreated|timePassed}} minutes ago.
{{quote.votes}} 5'>Favourite Quote


Message ID
Correlation ID
Timestamp
Delivery Mode
Reply To
Redelivered
Priority
Group ID
Expiration
Type
Destination


All Classes
Alerts
Alerts.ConfirmType
Appointment
AppointmentDao
AppointmentDetails
Calendar
Contact
ContactDao
Country
CountryDao
Customer
CustomerDao
CustomerDetails
DAO
DBConnection
Division
DivisionsDao
Logger
Login
Main
User
UserDao


HW-Wireframe
About
|
Portfolio
|
Contact
Profile:
Skills:
HTML
CSS
Javascript
Project 1
Project 2
Project 3
Project 4
Project 5
Project 6


|
From Text to Concepts
|
#include <functional>
#include <initializer_list>
#include <iostream>
#include <type_traits>
#include "String.hpp"
Go to the source code of this file.
Classes | |
| class | Concept::Vector< T, SmallVectorSize > |
Functions | |
| template<typename T , size_t N> | |
| std::ostream & | Concept::operator<< (std::ostream &os, const Vector< T, N > &buffer) |
Variables | |
| const size_t | Concept::DEFAULT_SMALL_VECTOR_MAX_SIZE = 8 |
| Default size of small vector storage. | |
The MIT License
Copyright(c) 2019 Leonce Mekinda
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files(the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and / or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions :
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE
| std::ostream& Concept::operator<< | ( | std::ostream & | os, |
| const Vector< T, N > & | buffer | ||
| ) |
Stream operator


This page explains the design details of Storm that make it a fault-tolerant system.
What happens when a worker dies?
When a worker dies, the supervisor will restart it. If it continuously fails on startup and is unable to heartbeat to Nimbus, Nimbus will reassign the worker to another machine.
What happens when a node dies?
The tasks assigned to that machine will time-out and Nimbus will reassign those tasks to other machines.
What happens when Nimbus or Supervisor daemons die?
The Nimbus and Supervisor daemons are designed to be fail-fast (process self-destructs whenever any unexpected situation is encountered) and stateless (all state is kept in Zookeeper or on disk). As described in Setting up a Storm cluster, the Nimbus and Supervisor daemons must be run under supervision using a tool like daemontools or monit. So if the Nimbus or Supervisor daemons die, they restart like nothing happened.
Most notably, no worker processes are affected by the death of Nimbus or the Supervisors. This is in contrast to Hadoop, where if the JobTracker dies, all the running jobs are lost.
Is Nimbus a single point of failure?
If you lose the Nimbus node, the workers will still continue to function. Additionally, supervisors will continue to restart workers if they die. However, without Nimbus, workers won’t be reassigned to other machines when necessary (like if you lose a worker machine).
So the answer is that Nimbus is “sort of” a SPOF. In practice, it’s not a big deal since nothing catastrophic happens when the Nimbus daemon dies. There are plans to make Nimbus highly available in the future.
How does Storm guarantee data processing?
Storm provides mechanisms to guarantee data processing even if nodes die or messages are lost. See Guaranteeing message processing for the details.


Robert Kilmer Photography
Contact
(current)
About
Galleries
Portraits
Sports
Landscape/Nature
contact page
Email address
Subject
Message:
Submit


--- layout: default title: ICHTD'17 - Results meta: The search results for the conference. keyword: heat transfer, heat transfer devices, cfd, boilers, compact heat exchangers, heat transfer enhancement, mechanical design, heat transfer conference, heat transfer devices conference, cfd conference, boilers conference, compact heat exchangers conference, heat transfer enhancement conference, mechanical design conference, fluid flow, fluid flow conference, fluid mechanics, fluid mechanics conference, fluid dynamics, fluid dynamics conference ---
Search Results


|
Argo
1.0
A C++ library for handling JSON.
|
A derived class of reader that reads from POSIX file descriptors. More...
#include <fd_reader.hpp>
Public Member Functions | |
| fd_reader (int fd, int max_message_length, bool block_read) | |
| Public Member Functions inherited from argo::reader | |
| reader (size_t max_message_length, bool block_read) | |
| virtual int | next () |
| Get the next character from the reader. More... | |
| virtual void | put_back (int c) |
| Put back a character so that it is returned by the next call to next(). | |
| size_t | get_byte_index () const |
| Get the current byte index in the input. | |
| void | reset_byte_index () |
| Reset the byte index at the start of parsing a messege. | |
Protected Member Functions | |
| virtual int | read_next_char () |
| virtual bool | read_next_block () |
| Protected Member Functions inherited from argo::reader | |
| int | read_next_char_from_block () |
| When in block read mode, get the next available character. | |
Protected Attributes | |
| int | m_fd |
| Underlying POSIX file descriptor. | |
| Protected Attributes inherited from argo::reader | |
| int | m_put_back |
| Character last put back. If equal to no_put_back then none was. | |
| size_t | m_byte_index |
| Total number of characters read. | |
| size_t | m_max_message_length |
| Maximum length of a message. | |
| bool | m_block_read |
| Whether to read in blocks or one byte at a time. | |
| unsigned char | m_block [block_size] |
| If we're reading blocks, the block data. | |
| int | m_block_num_bytes |
| If we're reading blocks, the number of bytes in the current block. | |
| int | m_block_index |
| If we're reading blocks, the index into the current block. | |
Additional Inherited Members | |
| Static Public Attributes inherited from argo::reader | |
| static const int | block_size = 8192 |
| Amount of data to read at once when in block read mode. | |
| Static Protected Attributes inherited from argo::reader | |
| static const int | no_put_back = 1000 |
| Special character value indicating that no character has been put back. | |
A derived class of reader that reads from POSIX file descriptors.
Definition at line 33 of file fd_reader.hpp.
| fd_reader::fd_reader | ( | int | fd, |
| int | max_message_length, | ||
| bool | block_read | ||
| ) |
Constructor.
| fd | POSIX stream file descriptor. The instance does not take ownership of the open file and it is up to the calling code to close it when done. |
| max_message_length | Longest message that can be read. |
| block_read | Whether to read in blocks or one byte at a time. |
Definition at line 35 of file fd_reader.cpp.
|
protectedvirtual |
Read the next block of data up to block_size bytes.
| json_io_error | if the read failed for some reason other than EOF. |
Implements argo::reader.
Definition at line 63 of file fd_reader.cpp.
|
protectedvirtual |
Read a character from the file descriptor using the read() system call.
| json_io_exception | Thrown in the event the read() call fails. |
Implements argo::reader.
Definition at line 41 of file fd_reader.cpp.


{% extends "grid_designer/base.html" %}
{% block content %}
This software is a joint effort between Raphael Santana and Braulio Chuco to design AC substation grounding systems. It was developed as a part of Raphael's undergraduate thesis using Python, a language loved by engineers, statisticians and scientists all over the world. The main goal of this project is to inspire other fellow engineers and engineering students to delve into the world of software development, and use this skillset as a innovative advantage and make the world a better place. In the author's point of view, one of the worse wastes of human time and work is doing something that can be automated, which is the case of doing the procedural math for the grounding systems design.


--- layout: post title: Store and forward date: 2013-02-24 10:27:55.000000000 +01:00 categories: [] tags: [] status: draft type: post published: false meta: _edit_last: '1' author: login: andreas.ohlund email<EMAIL_ADDRESS>display_name: Andreas Öhlund first_name: Andreas last_name: "Öhlund" ---
Store and forward is defined in the bible as:
when the sending application sends the message to the message channel, the messaging system stores the message on the sender’s computer, either in memory or on disk
http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/
http://en.wikipedia.org/wiki/Store_and_forward
Defines store and forward as
This definition rules out many of the broker centric queueing systems out there. Since we all (hopefully) knows that store and forward is a good thing this seems to imply that all broker based queuing systems is bad?
There store part of store and forward means that we store the message somewhere so that the receiver doesn't have to be online at the moment. The less stuff that needs to happen before the message is stored the better since the risk of failure is lower.
lets call this server level store and forward - msmq (and the brokers that support federation)
application level store and forward - the brokers
different levels: msmq vs the rest
local store and forward == if we have disk we're good
msmq installs in federation by default but you can connect remotely to a queue and essentially make it behave like a broker
remote store and forward => more trick
* fallacy of distributed computing
if queing == needs HA
http://www.rabbitmq.com/ha.html
http://activemq.apache.org/ha.html
or Federation
http://www.rabbitmq.com/federation.html
http://activemq.apache.org/how-do-distributed-queues-work.html
the azure issue


Trader Joe’s exec says the chain’s new Chocolate Lava Gnocchi are so good they can be eaten for dinner
by Erin McDowell, Business Insider US- Trader Joe’s just released one of their newest products, Chocolate Lava Gnocchi.
- Described as “sweet chocolate gnocchi with a molten chocolate core,” the new product is causing quite the stir online.
- While many fans of the popular grocery brand are anxious to try out the sweet take on the otherwise savory pasta alternative, others were shocked and horrified by the thought of combining potato and chocolate.
- “This was originally designed to be dessert, but I think that there are some people who might make a dinner out of it,” Trader Joe’s VP of product innovation, Lori Latta, said on the store’s podcast.
- Visit Business Insider’s homepage for more stories.
Move over cauliflower gnocchi – there’s new gnocchi on the Trader Joe’s shelf.
Trader Joe’s just released a new product that’s already making waves: Chocolate Lava Gnocchi. Described as “sweet chocolate gnocchi with a molten chocolate core,” the small balls of chocolate do indeed contain potato puree, creating a divide among fans of the grocery store chain.
While it may seem strange to combine the savory flavors of potato with sweet, molten chocolate and hazelnut, many of TJ’s most devoted followers are already anxious to get their hands on the divisive new item.
“If you’re a texture type of person, you may find them a little strange. However, I thought they tasted just like moist, soft chocolate cake balls with gooey goodness inside,” said one online commenter on Reddit.
Other commenters found the hybrid food disgusting and wished they could “un-know” the fact that the item even exists.
Inspiration for the unique dessert dish struck while Trader Joe’s VP of product innovation, Lori Latta, was shopping at Harrod’s department store in London, she said on Trader Joe’s podcast, Inside Trader Joe’s. Upon spying the store’s chocolate gnocchi, she asked Trader Joe’s own gnocchi supplier if they could make something similar.
“This was originally designed to be dessert, but I think that there are some people who might make a dinner out of it,” she said. “They’re really easy to prepare because you just put them in a sauté pan with a little bit of ghee or butter and brown them. I think it takes no more than the cauliflower gnocchi, so six to seven minutes.”
While the verdict may be out on whether potato gnocchi filled with melted chocolate qualifies as a dinner, rather than a dessert, we can’t say we aren’t intrigued.
Trader Joe’s Chocolate Lava Gnocchi cost $2.99 per bag and have 300 calories in every one-cup serving.


|
BTK Python wrapper
0.3dev.0
Python bindings for the Biomechanical ToolKit library (BTK)
|
Downsample a collection of wrenches. More...
Public Member Functions | |
| def | GetInput |
| def | GetInputNumber |
| def | GetOutput |
| def | GetOutputNumber |
| def | GetTimestamp |
| def | GetUpDownRatio |
| def | GetValidInputNumber |
| def | ResetState |
| def | SetInput |
| def | SetUpDownRatio |
| def | Update |
Downsample a collection of wrenches.
Downsample data stored in a collection of wrenches. To downsample data, you need to set the up/down sample ratio using the method SetUpDownRatio(). The given value is an integer corresponding to the ratio used to extract only the value of interest. For example, if you have 200 frames and a ratio of 10, then 20 frames will be extracted (one frame each 10 frames).
| def btk.btkWrenchCollectionDownsampleFilter.GetInput | ( | self | ) |
GetInput(self) -> btkWrenchCollection Gets the input registered with this process.
| def btk.btkWrenchCollectionDownsampleFilter.GetInputNumber | ( | self | ) |
GetInputNumber(self) -> int Returns the number of inputs.
| def btk.btkWrenchCollectionDownsampleFilter.GetOutput | ( | self | ) |
GetOutput(self) -> btkWrenchCollection Returns the output created with this process.
| def btk.btkWrenchCollectionDownsampleFilter.GetOutputNumber | ( | self | ) |
GetOutputNumber(self) -> int Returns the number of outputs.
| def btk.btkWrenchCollectionDownsampleFilter.GetTimestamp | ( | self | ) |
GetTimestamp(self) -> unsigned long Returns the timestamp of the object.
| def btk.btkWrenchCollectionDownsampleFilter.GetUpDownRatio | ( | self | ) |
GetUpDownRatio(self) -> int Gets the ratio used to downsample the data.
| def btk.btkWrenchCollectionDownsampleFilter.GetValidInputNumber | ( | self | ) |
GetValidInputNumber(self) -> int Returns the number of inputs which are valid (i.e. not null).
| def btk.btkWrenchCollectionDownsampleFilter.ResetState | ( | self | ) |
ResetState(self) Reset the state of the process. Usefull when an exception was thrown during the generation of the data.
| def btk.btkWrenchCollectionDownsampleFilter.SetInput | ( | self, | args | ) |
SetInput(self, btkWrenchCollection) Sets the input required with this process.
| def btk.btkWrenchCollectionDownsampleFilter.SetUpDownRatio | ( | self, | args | ) |
SetUpDownRatio(self, int) Sets the ratio used to downsample the data.
| def btk.btkWrenchCollectionDownsampleFilter.Update | ( | self | ) |
Update(self) Update the pipeline and then all the data inside. Recursive method which 1) determines the processes to update 2) generate the data by using the GenerateData() method.


Welcome to the macroMS Web Tool. We hope this serves as a convenient portal for job
submission.
# images submitted:
Note: recent (2017~) versions of FireFox or Chrome browsers are recommended
Note: Please reference instruction manual and video walkthrough


- Offline Use
- Read Messages
- Read Files
- Post Files
Connect
- Allow Pyaments
- Confirm Pagement
- Read Virtual Account
- Create Virtual Account
- Access to Email
- Allow Write Files
- Allow Meta
- Allow Create Folders
Abstract
- Figure out how to obtain a token
- Figure out how to send a request with a token
- Figure out how to refresh a token
- Figure out to get a new token on login
Chatwork OAuth Calls


1 IN THE HIGH COURT OF KARNATAKA, DHARWAD BENCH DATED THIS THE 24th DAY OF OCTOBER 2013 BEFORE THE HON'BLE MR. JUSTICE L. NARAYANA SWAMY WRIT PETITION NO.82859/2013(GM-KEB) BETWEEN: Sri. SAI SAPTAGIRI SPONGE PVT LTD,. HAVING REGISTERED OFFICE AT SY.NO,83/A, TUMTI ROAD, BELAGAL VILLAGE BELLARY DISTRICT 583 115 REPLL BY ITS DIRECTOR SMT. SAILEELA ... PETITIONER (BY SRI. SHIVARAJ C. BELLAKKI, ADVOCATE) AND: 1. THE ASSISTANT EXECUTIVE ENGINEER(ELE) RURAL SUB DIVISION, GESCOM, BELLARY. 2. THE ENVIRONMENTAL REGIONAL OFFICER KARNATAKA STATE POLLUTIONCONTROL BOARD, BELLARY, PARISARA BHAVAN NO.7, WARD I KHB COLONY NEAR SP CIRCLE, PARVATHI NAGAR, BELLARY 3. THE DEPUTY COMMISSIONER, BELLARY DISTRICT, BELLARY. ... RESPONDENTS (BY SRI. B.S. KAMATE, Advocate. FOR R1 SRI. G.I. GACHCHINAMATH, Advocate. FOR R2. SRI. K.S. PATIL, HCGP FOR R3 ) 2 THIS WRIT PETITION IS FILED UNDER ARTICLES 226 AND 227 OF THE CONSTITUTION OF INDIA PRAYING TO DIRECT TO THE FIRST RESPONDENT TO RECONNECT AND RESTORE THE POWER SUPPLY TO THE PETITIONER'S INDUSTRY WITH IMMEDIATE EFFECT AND ETC. THIS WRIT PETITION COMING ON FOR ORDERS, THIS DAY, THE COURT MADE THE FOLLOWING: ORDER
The petitioner is a medical scale industry located at Sy.No.83A and 79 of Belgal village, Bellary taluk and district in an area measuring 11 acres, which forms part of 3599 hectares of land declared by the Government of Karnataka as Industrial land. The petitioner established his industry since 01/12/2010 and he has obtained necessary permission from the concerned department. The petitioner made an application for certificate from the Pollution Control Board under Section 25 of the Water Act and he has got deemed permission under sub section 7 of Section 25 of the Water Act 1974. Despite the same, second respondent-Pollution Control Board passed an order which was challenged before the Appellate Authority in 3 appeal No.16-17/2012. The same was disposed of 31/01/2013 and remanded to the second respondent for reconsideration. The said order was subject matter in Writ petition No.8106/2013 and 8272-74/2013 which was disposed of on 23/07/2013 wherein permission sought by the petitioner to make an application for clearance from the Pollution Control Board was accepted and respondent was directed to dispose of the same.
2. In view of the directions issued by this Court in the above referred writ petition, though an application was made under Section 25 of the Act and necessary documents were produced, the respondent has not disposed of the same till today. In the meanwhile first respondent Gulburga Electricity Supply Company by its instruction dated 10.09.2013 has disconnected power supply given to the petitioner on 08.09.2013 at 5.00 p.m. and the same was communicated to the petitioner on 10th September 2013. Being aggrieved by the same, petitioner has filed this petition.
4
3. The action of the first respondent in disconnecting power supply to the petitioner industry and the action of the second respondent in directing the first respondent to disconnect power supply is subject matter in this writ petition.
4. The ground urged by the petitioner is that since 2010 he has started carrying on business in the factory and he had made an application within the stipulated time i.e. before commencement of the factory and since it was not disposed of within the time stipulated, he has got deemed permission under sub section (7) of Section 25 of the Water Act. He has challenged the direction issued by the second respondent to the first respondent dated 10/09/2013 as ultra vires. It is under Rule 34 sub clause 4 member Secretary to the Board has power to issue such direction contrary to the same Annexure "J" is issued by the Assistant Executive who is not a member Secretary or any person appointed by the 5 Board in that behalf. Secondly, direction issued by the second respondent to the first respondent also not applicable to the occupier of the nature i.e. the petitioner herein. Learned counsel refers to the judgment reported in 2006 SC 2038. The said judgment is referred in order to substantiate his submission that clearance from the Pollution Control Board or various department is dispensed since the land was allotted for industrial purpose by the KSIIDC -Annexure B. Notification issued by the Government of Karnataka dated 01/12/2010 for acquiring land for industrial establishment in which the petitioner commissioned his industry.
5. Learned counsel for the first respondent GESCOM submitted that it is not required to issue notice to the occupier since such opportunities were given by the second respondent. Any direction issued by the concerned authority under the Water Act 1974, first respondent has to comply with the same as per Section 33 A of the Water Act, which is mandatory one, and the first respondent is 6 bound by such direction. The counsel for the second respondent submitted to dismiss this petition as the mandatory requirement under Section 25 of the Water Act has not been complied. Prior permission has to be obtained before establishing any industry. Applications made by the petitioner for clearance have been dismissed on earlier occasions. One such refusal has been produced and marked as Annexure "R2" dated 31/12/2008, "R7" dated 09/10/2012 and "R8" dated 13/09/2013. This refusal order initially has not been challenged. The direction issued by this Court in Writ Petition No.8106/2013 and other connected matters vide Annexure "G" has not been complied since required materials are not produced by the petitioner. Second respondent had addressed several complaints by the public and that the pollution emitted by the petitioner-industry is causing health hazards and agricultural lands have become barren. Hence, it has directed first respondent to disconnect the power supply. Second respondent has also passed an order dated 02/07/2012 for closure as per Annexure "R-6". 7 It is further submitted that it is not only the petitioner industry has been closed down but other 5 industries have also been closed down for want of clearance from the Pollution Control Board.
6. Learned Government Pleader adopted the submission made by respondents 1 and 2.
7. It is undisputed fact that the land on which the petitioner is carrying out business is allotted by the Government for industrial purposes. The purpose of allotment is for establishing industries. Any industry before establishing or commencing its business, has to take prior permission under Section 25 of the Water Act 1974 which reads thus:
"25. Restrictions on new outlets and new discharges: subject to the provisions of this section, no person shall, without the previous consent on the State Board-
(a) establish or take any steps to establish any industry, operation or process, or any treatment and 8 disposal system or any extension or addition thereto, which is likely to discharge sewage or trade effluent into a stream or well or sewer or on land (such discharge being hereafter in this section referred to as discharge of sewage) and an application for consent of State Board under sub-section(1) shall be made in such form, contain such particulars and shall be accompanied by such fees as may be prescribed.
Sub Section (7) of Section 25 states that the consent referred to in sub-section(1) shall, unless, given or refused earlier, be deemed to have been given unconditionally on the expiry of a period of four months of the making of an application in this behalf complete in all respects to the State Board."
8. In the instant case, application made by the petitioner for permission under Section 25 of the Act was not disposed of within the time stipulated. Hence, the petitioner is said to have the benefit of deemed provision. 9
9. The said submission has been examined in the light of the communications made as referred in Annexures R2, R7 and R9. By these endorsement the case of the petitioner for grant of permission was refused. Notwithstanding the same, when closure order was passed, the same was challenged before the Karnataka State Appellate Authority, Bangalore, constituted under the Water Act 1981. Writ Appeal NO.18 and connected appeal no.19/2011 was disposed of on 9th November 2011 in which, order passed by the second respondent was set aside and remanded for fresh consideration. Second respondent has not placed any reliance as to the order passed pursuant to the remand order dated 09/11/2011. Hence, it is taken for recording purpose that the second respondent has not disposed of the matter after the appeals are remanded on 09/11/2011.
10. The case of the first respondent is that he is duty bound to comply with the directions issued by the second respondent is being examined.
10
11. Section 33 A of the Act reads as follows:
33A. Power to give directions:-
Notwithstanding anything contained in any other law, but subject to the provisions of this Act, and to any directions that the Central Government may give in this behalf, a Board may, in the exercise of its powers and performance of this functions under this Act, issue any directions in writing to any person, officer or authority and such person, officer or authority shall be bound to comply with such directions.
As per Section 33A it is the Board who is the competent authority to issue directions to any persons or authority and such directions issued by the competent authority is binding on all other authorities. Rule 34 of the Water Rules 1975 further mandates that the proposed directions issued by the board either for stoppage or regulation of electricity or water or any other services affecting the carrying of any industry, operation or process and is sought to be issued to an officer or an authority, a copy of 11 the proposed direction shall also be endorsed to the occupier of the industry, operation or process, as the case may be, and objections, if any, filed by the occupier with an officer designated in this behalf shall be dealt with in accordance with the procedures under sub-rules(3) and (5) of this rule. From this it is clear that direction can be issued either by the Board or by the Member Secretary of the Board or any person authorised by the Board.
12. Now it is relevant to examine whether the impugned direction issued by the first respondent is by the Environment Officer of the Board at Bellary.
13. In the communication dated 06/09/2013, it is not referred whether the same has been authorised by the Board or whether he is the competent authority or whether he is a Member Secretary. Unless the persons who issue directions to the first respondent is competent, such direction is ultra vires under Section 33A and sub-rule(4) of Rule 34 of the Water Act and Rules. The direction issued to the first respondent is not by the competent 12 authority. In this regard, submission of the second respondent that what has been forwarded to the first respondent is only the communication of the decision taken by the Board and the Member Secretary who are competent. In this regard it is relevant to mention that when a statute directs a statutory authority to function in a particular manner he should carry out the same in the manner prescribed under the Act. The Act says it is the Member Secretary or an authorised person by the Board shall issue direction to the first respondent then he alone can act in accordance with the said provisions. He cannot delegate such power to environment authority since he has no power of delegation. Further the environment officer is not a competent authority to issue direction to the first respondent. The learned counsel for the appellant relies on sub para 2 of para 97 of the judgment in the case of Karnataka Industrial Areas Development Board Vs. C. Kenchappa and Ors. reported AIR 2006 SC 2308 97 para(2) which is as follows:
13
"(2) We also direct the appellant to incorporate the condition of allotment to obtain clearance from the Karnataka State Pollution Control Board before the land is allotted for development. The said directory condition of allotment of lands be converted into a mandatory condition for all the projects to be sanctioned in future."
This Court in (1987) 7 Kar. Law Journal 410 held that " as a matter of fact no industry shall be commenced unless the unit secures clearance from the agency under the relevant provisions of the law as aforementioned". The legal provisions thus take care of the possible situation in which the industry, unit established in any one of those industrial area may be found to be violating the law, the units can even be permitted to be closed if they do not comply with the statutory requirement relating to control and elimination of pollution.
14. Industries are very much important for the growth of a nation. Industries provide employment and 14 improve the standard of living and as well as social and economic condition. They are the backbone of the nation and at the same time, health of a man is of paramount importance. Industries shall not be permitted to carry on at the cost of human existence. Closure of industries creates epidemic in the society and creates unemployment. Closure of an industry is not a solution, in effect, it is the Pollution Control Board to get the industry established and take measures to reduce pollution which shall not mar the human growth. In view of the above, case on hand is required to be decided.
15. The application filed by the petitioner as per the direction of this court is still pending consideration. If the materials furnished by the petitioner are not sufficient, the Board has to call for required documents from the petitioner. Unless such directions are issued to the petitioner, it is not proper for the Board to dismiss the case. In the circumstance, the action of the first respondent in disconnecting power on the basis of the 15 direction/communication issued by the incompetent authority is illegal and ultra vires. Hence, I pass the following order:
Writ Petition is allowed. Annexure "J" is hereby quashed. The first respondent forthwith connect the power supply to the petitioner industry. Second respondent is directed to dispose of the applications pending before it afresh within 3 months in accordance with law. If the documents furnished by the petitioner are not sufficient, second respondent shall call for further documents and pass appropriate order in accordance with law within three months from the date of receipt of a certified copy of this order.
Sd/-
JUDGE .
Kmv


You can now visit strog.com any time and play! Good Luck!
Sorry, but your purchase did not go through.
How to Purchase