This page shows automated results of the kappa-Cygnids 2013, based on visual observations reported by citizen scientists through the report form of the International Meteor Organization (IMO). The information on this page is generated automatically; for scientific use please refer to manual analyses published in scientific journals (such as WGN). Send your feedback regarding this page to Geert Barentsen.
Page contents:
Note that the data will finally go into the Visual Meteor Database (VMDB) with manual inspection and rectifications. We are curretly completing the files of 2008-2011. The VMDB is an enormous project - any help will be greatly appreciated.
Page generated: 2015 November 3 at 15:40 UTC.
The graph below shows the ZHR (Zenithal Hourly Rate), which is the number of meteors an observer would see under a very dark sky with the radiant of the shower in zenith.
ZHRmax = 2.8 based on 627 kappa-Cygnids reported in 1199 intervals, assuming population index r = 2.5
| Time (UTC) | Solarlon | nINT | nKCG | ZHR | Particle density | |
|---|---|---|---|---|---|---|
| 2013-08-12 07:21 | 139.568 | 264 | 100 | 2.0 | ±0.2 | 11 / 109·km3 |
| 2013-08-12 22:35 | 140.178 | 425 | 251 | 2.8 | ±0.2 | 16 / 109·km3 |
| 2013-08-13 07:26 | 140.532 | 281 | 100 | 1.9 | ±0.2 | 11 / 109·km3 |
| 2013-08-14 08:19 | 141.528 | 118 | 82 | 2.8 | ±0.3 | 16 / 109·km3 |
| 2013-08-15 06:40 | 142.423 | 71 | 49 | 2.1 | ±0.3 | 12 / 109·km3 |
| 2013-08-16 09:16 | 143.488 | 16 | 23 | 2.5 | ±0.5 | 14 / 109·km3 |
| 2013-08-17 04:07 | 144.242 | 24 | 22 | 2.0 | ±0.4 | 11 / 109·km3 |
The reported intervals are automatically added together into the bins shown above, based on the number of meteors and the distribution of the intervals. For each bin, the following parameters are computed:
Data has been received from 103 observers in 26 countries. Thank you for your efforts!
Note: click on the map for an interactive version.
| Observer | Country | Teff | nKCG |
|---|---|---|---|
| Tomasz Adam | Poland | 5.42h | 7 |
| Pouya Ahmadifard | Iran | 0.73h | 5 |
| Marina Arnaut | Serbia | 1.80h | 1 |
| Manca Avsec | Slovenia | 4.50h | 1 |
| Janos Bakos | Hungary | 4.64h | 8 |
| Tamás Baráth | Hungary | 4.61h | 17 |
| Hamed Beheshti | Iran | 1.25h | 0 |
| Orlando Benítez Sánchez | Spain | 7.43h | 3 |
| Martina Birosikova | Slovakia | 2.48h | 5 |
| Orlando B | Spain | 0.93h | 3 |
| Andreas Buchmann | Switzerland | 0.80h | 1 |
| Jakub Cerny | Czech Republic | 2.53h | 5 |
| Sara Charmchi | Iran | 1.25h | 3 |
| Farzad Chegini | Iran | 0.40h | 1 |
| Andrej Ciganj | Croatia | 0.70h | 0 |
| Matej Ciganj | Croatia | 1.17h | 0 |
| Nicolae Adrian Corlaci | Romania | 1.34h | 3 |
| Tom Corstjens | Belgium | 2.47h | 2 |
| Daniel Cosovanu | Romania | 3.73h | 21 |
| Ilie Cosovanu | Romania | 5.8h | 18 |
| Lucian-mihai Cosovanu | Romania | 4.68h | 11 |
| Angheluta Cristian Paul | Romania | 2.17h | 5 |
| Martin Dana | Slovakia | 2.53h | 3 |
| Goedele Deconinck | Belgium | 0.93h | 0 |
| Sietse Dijkstra | Netherlands | 6.7h | 7 |
| Marusa Dolinar | Slovenia | 2.12h | 4 |
| Jozef Drga | Slovakia | 2.48h | 3 |
| Audrius Dubietis | Lithuania | 5.85h | 12 |
| Frank Enzlein | Germany | 2.50h | 3 |
| Reyhaneh Fallah | Iran | 2.16h | 1 |
| Bratislav Filipovic | Serbia | 1.00h | 0 |
| Ivan Ganev | Bulgaria | 0.72h | 3 |
| Ivanka Getsova | Bulgaria | 11.36h | 3 |
| Jona Gladines | Belgium | 1.65h | 2 |
| Mitja Govedic | Slovenia | 5.62h | 11 |
| Ljubica Grasic | Serbia | 2.97h | 2 |
| Oliver Hanke | Germany | 0.60h | 1 |
| Amir Hasanzadeh | Iran | 1.05h | 0 |
| Roberto Haver | Italy | 3.21h | 1 |
| Meisam Honari Jafarpour | Iran | 0.40h | 0 |
| Kamil Hornoch | Czech Republic | 5.05h | 0 |
| Marzie Hoseyni | Iran | 0.80h | 3 |
| Adam Ioan | Romania | 2.17h | 5 |
| Lars Jacobs | Belgium | 3.2h | 7 |
| Marziye Jafari Yazani | Iran | 0.90h | 4 |
| Csilla Kalup | Hungary | 7.47h | 22 |
| Desislava Kalaidjieva | Bulgaria | 7.22h | 14 |
| Somaye Khakpash | Iran | 0.88h | 4 |
| Katya Koleva | Bulgaria | 5.65h | 15 |
| Anamrija Komesarovic | Croatia | 1.40h | 0 |
| Gyongyver Kudor | Hungary | 5.95h | 4 |
| Martin Labudik | Slovakia | 2.53h | 4 |
| Greet Lembregts | Belgium | 4.99h | 2 |
| Aleksei Makarow | Russia | 2.48h | 7 |
| Bruce Mccurdy | Canada | 3.5h | 4 |
| Saeed Mehdizad | Iran | 1.90h | 5 |
| Fereshteh Memarian | Iran | 1.20h | 1 |
| Frederic Merlin | France | 4.03h | 3 |
| Nikolina Milanovic | Serbia | 2.82h | 2 |
| Adrienn Nagy | Hungary | 5.65h | 34 |
| Andreea Neagu | Romania | 5.60h | 4 |
| Rafael Neumann | Germany | 1.14h | 1 |
| Vladimir Nikolov | Bulgaria | 5.22h | 22 |
| Mohammad Nilforoushan | Iran | 3.00h | 6 |
| Dimitrie Olenici | Romania | 1.68h | 3 |
| Kai Schultze | Germany | 0.50h | 1 |
| Ahmad Sohani | Iran | 1.25h | 0 |
| Michaela Spanikova | Slovakia | 0.50h | 5 |
| Stefani Stefanova | Bulgaria | 8.25h | 8 |
| Wesley Stone | United States | 2.71h | 2 |
| Adam Szabo | Hungary | 7.37h | 3 |
| Kitti Szabo | Hungary | 4.30h | 11 |
| Ghazaleh Tahmasebi | Iran | 1.05h | 1 |
| Richard Taibi | United States | 1.68h | 1 |
| Istvan Tepliczky | Hungary | 3.23h | 2 |
| Salvador Aguire | Mexico | 1.50h | 2 |
| Terrence Ross | United States | 19.61h | 9 |
| Peter Van Leuteren | Netherlands | 15.95h | 21 |
| Jurgen Rendtel | Germany | 10.53h | 13 |
| Koen Miskotte | Netherlands | 18.42h | 21 |
| Michel Vandeputte | Belgium | 13.5h | 14 |
| Branislav Savic | Serbia | 4.89h | 2 |
| Pierre Bader | Germany | 10.93h | 23 |
| Alexsandr Morozov | Russia | 0.56h | 1 |
| Thomas Weiland | Austria | 0.94h | 0 |
| Javor Kac | Slovenia | 10.94h | 8 |
| Pierre Martin | Canada | 7.52h | 9 |
| Karoly Jonas | Hungary | 9.99h | 6 |
| Alexandr Maidik | Ukraine | 0.30h | 2 |
| Vilem Heblik | Czech Republic | 10.7h | 16 |
| William Watson | United States | 14.97h | 12 |
| Aniko Morvai | Hungary | 4.49h | 3 |
| Konstantin Morozov | Belarus | 3.58h | 13 |
| Maciek Myszkiewicz | Poland | 4.00h | 1 |
| Branislav Savic | Serbia | 3.88h | 2 |
| Csilla Tepliczky | Hungary | 4.71h | 1 |
| Anatoliy Vasylenko | Ukraine | 4.22h | 4 |
| Blanca Troughton Luque | Spain | 2.39h | 3 |
| Mikhail Turchenko | Russia | 1.25h | 3 |
| Shigeo Uchiyama | Japan | 6.5h | 6 |
| Vanesa Ujcic Ozbolt | Croatia | 3.18h | 0 |
| Kristina Veljkovic | Serbia | 3.79h | 4 |
| Valentin Velkov | Bulgaria | 5.00h | 11 |
| Jan Verbert | Belgium | 0.93h | 0 |
| Frank Waechter | Germany | 1.26h | 3 |
| Sabine Waechter | Germany | 1.24h | 6 |
| Sabine Waechter | Germany | 0.23h | 0 |
| Lukasz Wozniak | Poland | 1.52h | 1 |
| Oliver Wusk | Germany | 6.25h | 3 |
| Gergana Zaharieva | Bulgaria | 9.96h | 18 |
| Reziyeh Zahedi | Iran | 1.68h | 1 |
| Ana Zegarac | Serbia | 4.88h | 1 |
Create your own analysis. The files below can be opened using Excel:
kcg2013_rate.csv (number of meteors per interval per observer)
kcg2013_magn.csv (number of meteors per magnitude bin per observer)
The information on this page may be distributed freely provided credit is given to the International Meteor Organization (IMO) and, when possible, to the individual observers. The computer facilities to generate this page are provided by ESA/RSSD and Armagh Observatory.
References:


About
The winning army realizes the conditions for victory first, then fights. The losing army fights first, then seeks victory.
Profile
Name: {{site.title}}
Location: {{site.data.location.dfw}}
Citizenship: United States
Language: English
Summary
Forward-thinking technologist who blends strategic vision with practical execution to deliver high-tech products and solutions. Distinct ability to translate insights into compelling strategies that drive growth and ensure client success.
Recognized for identifying emerging trends, implementing new market initiatives, and driving go-to-market tactics. Functional experience spanning all disciplines, from ideation and development to marketing and optimization. Skilled at delivering product and marketing capabilities including:
- Strategic Planning
- Roadmap and Vision Creation
- Competitive Intelligence
- Market Research
- Product Design and Implementation
- Content Creation
- Value Propositions
- Messaging
- Launch Plans
- Pricing and Packaging


 You also know that there is no chance at all for Kyan to be able to live freely in this part of the world. It doesn't matter where you live, there will always be people who are against homosexuality, but there are countries that are more progressive than others. However, moving to those countries which are predominately inhabited by Caucasians, you know that you might face racism towards you and your family because of your African origin. It is a risk you're willing to take.
You walk up to Kyan's room, and stop outside of his door. You take a deep breath and then knock on the door, no answer. You knock again, and call out to him.
"Son, open the door."
The door slowly, tentatively, opens and Kyan is looking at you. You can tell he's been crying.
"Will you let me in?"
Kyan nods, and walks into his room, you follow him and close the door behind you. Kyan sits down on his bed, and you sit down next to him. He is twisting his hands in his lap.
"I love you, and I accept you." you can feel Kyan relaxing, "Thank you for telling me."

"Thank you!" he cries against your chest.
"But..." you say.
Kyan dries his eyes and look up at you.
"We can't stay here."
"What do you mean?"
"You know that the penalty for homosexuality is a lifetime in prison."
Kyan freezes, and you aren't sure if he knew or not.
"We have to move."
"Where?"
"Europe or North America."
Kyan nods slowly. You get up to your feet.
"I am going to talk to your mother."

You leave Kyan's room to go find your wife. You sigh heavily, you know that this won't be easy.
You and Neela had a huge fight about moving, you ended up telling her that this was for your family's best. That you had to do this, you gave her an option of staying or coming with. Although, you knew that it wasn't really an option. Neela could never stay while the rest of the family left. Her family would never take her back, and she would have no security or anywhere to live. It was with a heavy heart you made all the arrangements to move your family.


NAstro is an Angular Application which display data acquired using NASA's API in a Minimilist Fashion.


public class ContextManager
extends java.lang.Object
game
: the game this context manager must handlepayloadReplayQueue
: a queue of JsonValue which memorize all the responses taken by contextspendingMessage
: the recived messagewaitingContextResponse
: the type of context that ContextManager his waitingGame, GameMessage, ContextType, Player, Action, ServerMessageFactory
| Modifier and Type | Field and Description |
|---|---|
private Game |
game |
private java.util.LinkedList<com.eclipsesource.json.JsonValue> |
payloadReplayQueue |
private GameMessage |
pendingMessage |
private java.lang.String |
waitingContextResponse |
| Constructor and Description |
|---|
ContextManager(Game game)
initialize the manager to handle contexts for the spcified game
|
| Modifier and Type | Method and Description |
|---|---|
java.lang.String |
getWaitContextResponse()
allows to retrive the content of the waitingContextResponse string
|
boolean |
isThereAnyOpenContext()
tells if the ContextManager is waiting for a response
|
void |
openContext(ContextType context,
Player player,
Action action,
com.eclipsesource.json.JsonValue extraInfo)
open a context.
|
void |
setContextAck(boolean accepted,
Player player)
send the CONTEXTACK response to the client
|
com.eclipsesource.json.JsonValue |
waitForContextReply()
blocking method which await for a CONTEXTREPLY message, if the CONTEXT_TYPE field is equals to the value of waitingContextResponse string the response is accepted
and the response is returned to the caller. null is returned if ContextManager is no context are opened.
|
private java.lang.String waitingContextResponse
private java.util.LinkedList<com.eclipsesource.json.JsonValue> payloadReplayQueue
private GameMessage pendingMessage
private Game game
public ContextManager(Game game)
game
- the game the context manager must handlepublic void openContext(ContextType context, Player player, Action action, com.eclipsesource.json.JsonValue extraInfo)
context
- the type of context to openplayer
- the recipient of the messageaction
- the action which has triggered the opening of the contextextraInfo
- the info needed to customize the contextpublic boolean isThereAnyOpenContext()
public java.lang.String getWaitContextResponse()
public com.eclipsesource.json.JsonValue waitForContextReply()
public void setContextAck(boolean accepted, Player player)
accepted
- flag that tells the client if the context response has been assessed as valid or notplayer
- the recipient of the message


Installation¶
Using pip¶
FULMAR can be installed conveniently using pip
:
pip install fulmar-astro
If you have multiple versions of Python and pip on your machine, make sure to use pip3
. Try:
pip3 install fulmar-astro
Requirements¶
FULMAR has the following requirements:
Astropy >4.1, <5
Lightkurve >= 2
TransitLeastSquares >= 1.0.31
These should be installed automatically if you use pip
to install FULMAR.
From Source¶
The source code from FULMAR can be pulled from github <https://github.com/astrojose9/fulmar> :
git clone https://github.com/astrojose9/Fulmar.git
cd fulmar
python setup.py install
If the command python
does not point to Python 3 on your machine, you can try to replace the last line with python3 setup.py install
. If you don’t have git
on your machine, you can find installation instructions here.


Exercise 21.
Using your results from Exercise 6.10.8, Exercise 6.10.20, and your own research, prepare a class letter to submit to your local government (city, county, or state) about payday lending. You should discuss how the calculations can help government officials to regulate payday lenders and understand the effect of these predatory lenders on communities.


Virtex Wholesale Coins
(work in progress)
More coming soon.
Check out the progress
Click Here
Back To
Portfolio


Governance
Further information on external reviews of governance, national leaders of governance and leadership development opportunities for governors.
Guidance
Find out about becoming a national leader of governance (NLG), what's involved and how to apply.
If you’re an experienced chair of governors who is interested in supporting chairs of governors in other schools, you can apply to be a National Leader of Governance ( NLG ).
This is part of the government’s plan to give schools a central role in developing a self-improving and sustainable school-led system.
The application round opens on Monday 27 March 2017 at 9am and closes on Monday 1 May 2017 at 11.59pm.
Register your interest in becoming an NLG .
Cohort 10 is a targeted application round, focusing on areas of greatest need to increase the geographical coverage of NLGs . Please take a look at our target areas .
We will also consider applications from high-quality governors across the country with:
Chairs that are not based within the target areas will still be able to apply. If you are able to provide support to schools in these areas, even if situated outside of a target area, please specify how you would deliver this support within your application and this will be considered on an individual basis by the designation panel.
You must be an experienced chair of governors with:
To be successful in your application, you must:
Read the NLG eligibility criteria ( PDF , 53.8KB , 4 pages ) for further information.
Independent schools must have been judged good by the Independent Schools Inspectorate ( ISI ) or the School Inspection Service ( SIS ).
For further information please read the NLG eligibility criteria ( PDF , 53.8KB , 4 pages ) .
NLGs concentrate on developing school governance capacity and expertise. In some cases, they work in partnership with a national leader of education or a teaching school alliance.
If selected, you’ll provide support to a chair of governors in a school meeting one or more of the following criteria:
NLGs provide support:
Some NLGs will provide short-term support to governing bodies, for example by joining an interim executive board or chairing a governing body in severe difficulties.
NLGs may also do external reviews of governance .
NLGs need to work proactively with at least one teaching school alliance, local authority or diocese who will help identify schools that need NLG support.
In addition to your existing role as chair, you’ll be expected to provide effective support to at least 1 school per year. You’ll be expected to provide the equivalent of 10 days of free support for schools each year, after which you may charge for your time. You will need to negotiate any cost with the school receiving support.
A grant (up to £2,000 in the financial year 2017 to 2018) will be paid to your school to cover the costs of reasonable expenses incurred when you’re undertaking or preparing for deployments (expenses may include travel, subsistence, stationery or telephone costs).
NLG grant funding can also be used to fund training and development for your governing body.
Your school will be required to complete an annual grant funding evaluation return to account for the spending of the grant.
We maintain a school-to-school support directory for people looking to commission the services of NLGs and other system leaders. Details of all designated system leaders, including NLGs will be placed on to the directory.
If successful, you’ll attend a training induction event that provides:
All NLG deployments should:
| Area |
|---|
| Lincolnshire (eastern and northern areas) |
| Derby |
| Derbyshire |
| Northamptonshire |
| Area |
|---|
| Cambridgeshire |
| Norfolk |
| Peterborough |
| Suffolk |
| Area |
|---|
| Redcar |
| Northumberland |
| Middlesborough |
| Area |
|---|
| Blackpool |
| Oldham |
| Area |
|---|
| East Sussex |
| Brighton and Hove |
| Bracknell Forest |
| Hampshire |
| Isle of Wight |
| Oxfordshire |
| Area |
|---|
| Cornwall |
| Somerset |
| Area |
|---|
| Herefordshire |
| Birmingham |
| Coventry |
| Sandwell |
| Shropshire |
| Staffordshire |
| Stoke-on-Trent |
| Walsall |
| Worcestershire |
| Area |
|---|
| Doncaster |
| North Lincolnshire |
| Kirklees |
| North Yorkshire |
| Bradford |
Chairs that are not based within the target areas will still be able to apply if you are able to provide support to schools in these areas. If you are situated outside a target area, please specify how you would deliver this support within your application and this will be considered on an individual basis by the designation panel.
Further information on external reviews of governance, national leaders of governance and leadership development opportunities for governors.
Published: 21 March 2014
Updated: 9 March 2017


interface Storable
A wrapper class for UBObject with helper functions for getting and setting data
class UBJ


Table of Contents
A variety of compile-time analyses require reasoning about types that are not yet known. Principal among these are generic method applicability testing (§18.5.1) and generic method invocation type inference (§18.5.2). In general, we refer to the process of reasoning about unknown types as type inference.
At a high level, type inference can be decomposed into three processes:
Reduction takes a compatibility assertion about an expression or type, called a constraint formula, and reduces it to a set of bounds on inference variables. Often, a constraint formula reduces to other constraint formulas, which must be recursively reduced. A procedure is followed to identify these additional constraint formulas and, ultimately, to express via a bound set the conditions under which the choices for inferred types would render each constraint formula true.
Incorporation maintains a set of inference variable bounds, ensuring that these are consistent as new bounds are added. Because the bounds on one variable can sometimes impact the possible choices for another variable, this process propagates bounds between such interdependent variables.
Resolution examines the bounds on an inference variable and determines an instantiation that is compatible with those bounds. It also decides the order in which interdependent inference variables are to be resolved.
These processes interact closely: reduction can trigger incorporation; incorporation may lead to further reduction; and resolution may cause further incorporation.
§18.1 more precisely defines the concepts used as intermediate results and the notation used to express them.
§18.2 describes reduction in detail.
§18.3 describes incorporation in detail.
§18.4 describes resolution in detail.
§18.5 defines how these inference tools are used to solve certain compile-time analysis problems.
In comparison to the Java SE 7 Edition of The Java® Language Specification, important changes to inference include:
Adding support for lambda expressions and method references as method invocation arguments.
Generalizing to define inference in terms of poly expressions, which may not have well-defined types until after inference is complete. This has the notable effect of improving inference for nested generic method and diamond constructor invocations.
Describing how inference is used to handle wildcard-parameterized functional interface target types and most specific method analysis.
Clarifying the distinction between invocation applicability testing (which involves only the invocation arguments) and invocation type inference (which incorporates a target type).
Delaying resolution of all inference variables, even those with lower bounds, until invocation type inference, in order to get better results.
Improving inference behavior for interdependent (or self-dependent) variables.
Eliminating bugs and potential sources of confusion. This revision more carefully and precisely handles the distinction between specific conversion contexts and subtyping, and describes reduction by paralleling the corresponding non-inference relations. Where there are intentional departures from the non-inference relations, these are explicitly identified as such.
Laying a foundation for future evolution: enhancements to or new applications of inference will be easier to integrate into the specification.
This section defines inference variables, constraint formulas, and bounds, as the terms will be used throughout this chapter. It also presents notation.
Inference variables are meta-variables for types - that is, they are special names that allow abstract reasoning about types. To distinguish them from type variables, inference variables are represented with Greek letters, principally α.
The term "type" is used loosely in this chapter to include type-like syntax that contains inference variables. The term proper type excludes such "types" that mention inference variables. Assertions that involve inference variables are assertions about every proper type that can be produced by replacing each inference variable with a proper type.
Constraint formulas are assertions of compatibility or subtyping that may involve inference variables. The formulas may take one of the following forms:
‹Expression → T›: An expression is compatible in a loose invocation context with type T (§5.3).
‹S → T›: A type S is compatible in a loose invocation context with type T (§5.3).
‹S <:
T›: A reference type S is a
subtype of a reference type T
(§4.10).
‹S <=
T›: A type argument S is
contained by a type argument T
(§4.5.1).
‹S = T›: A type S is the same as a type T (§4.3.4), or a type argument S is the same as type argument T.
‹LambdaExpression →throws T›:
The checked
exceptions thrown by the body of the LambdaExpression
are
declared by the throws
clause of the function type derived
from T.
‹MethodReference →throws T›:
The checked
exceptions thrown by the referenced method are declared by the
throws
clause of the function type derived from T.
Examples of constraint formulas:
From Collections.singleton("hi")
,
we have the constraint formula ‹"hi"
→ α›. Through
reduction, this will become the
constraint formula: ‹String
<:
α›.
From Arrays.asList(1, 2.0)
,
we have the constraint formulas ‹1
→
α› and ‹2.0
→
α›. Through reduction, these will become the
constraint formulas ‹int
→ α› and
‹double
→ α›, and then ‹Integer
<:
α› and ‹Double
<:
α›.
From the target type of the constructor
invocation List<Thread> lt = new
ArrayList
, we have the constraint
formula
‹<>
()ArrayList
<
α>
→ List
<
Thread
>
›. Through
reduction, this will become the constraint formula
‹α <=
Thread
›, and then
‹α = Thread
›.
During the inference process, a set of bounds on inference variables is maintained. A bound has one of the following forms:
S = T, where at least one of S or T is an inference variable: S is the same as T.
S <:
T,
where at least one of S or T is an
inference variable: S is a subtype of T.
G<
α1, ..., αn>
=
capture(G<
A1, ..., An>
): The variables
α1, ..., αn represent the
result of capture
conversion (§5.1.10) applied to
G<
A1,
..., An>
(where A1, ..., An may
be
types or wildcards and may mention inference variables).
throws
α: The inference
variable α appears in a
throws
clause.
A bound is satisfied by an inference variable substitution if, after applying the substitution, the assertion is true. The bound false can never be satisfied.
Some
bounds relate an inference variable to a proper type. Let T be a
proper type. Given a bound of the form α = T
or T = α,
we say T is an instantiation of α.
Similarly, given a bound of the form α <:
T, we say T
is a proper upper bound of α,
and given a
bound of the form T <:
α,
we say T is
a proper lower bound of α.
Other
bounds relate two inference variables, or an inference variable to a
type that contains inference variables. Such bounds, of the form S =
T or S <:
T, are called
dependencies.
A bound
of the form G<
α1, ..., αn>
=
capture(G<
A1, ..., An>
) indicates that α1,
..., αn are placeholders for the
results of capture
conversion. This is necessary because capture conversion can only be
performed on a proper type, and the inference variables in A1, ...,
An may not yet be resolved.
A bound
of the form throws
α is purely
informational: it directs
resolution to optimize the instantiation of α so that, if
possible, it is not a checked exception type.
An important intermediate result of inference is a bound set. It is sometimes convenient to refer to an empty bound set with the symbol true; this is merely out of convenience, and the two are interchangeable.
Examples of bound sets:
{ α = String
}
contains a single bound,
instantiating α as String
.
{ Integer
<:
α, Double
<:
α, α <:
Object
} describes two
proper lower bounds and one proper upper bound for
α.
{ α
<:
Iterable<?>
, β <:
Object
, α
<:
List
<
β>
}
describes a proper upper bound for each of α and β,
along with a dependency between them.
{ } contains no bounds nor dependencies, and can be referred to as true.
{ false } expresses the fact that no satisfactory instantiation exists.
When inference begins, a bound set is typically generated from a list of type parameter declarations P1, ..., Pp and associated inference variables α1, ..., αp. Such a bound set is constructed as follows. For each l (1 ≤ l ≤ p):
If
Pl has no TypeBound, the
bound αl <:
Object
appears
in the set.
Otherwise, for each type T delimited by &
in
the TypeBound, the bound αl <:
T[
P1:=α1, ..., Pp:=αp]
appears
in the set; if this results in no proper upper bounds for
αl (only
dependencies), then the bound αl <:
Object
also appears in the set.
Reduction is the process by which a set of constraint formulas (§18.1.2) is simplified to produce a bound set (§18.1.3).
Each constraint formula is considered in turn. The rules in this section specify how the formula is reduced to one or both of:
Reduction completes when no further constraint formulas remain to be reduced.
The results of a reduction step are always soundness-preserving: if an inference variable instantiation satisfies the reduced constraints and bounds, it will also satisfy the original constraint. On the other hand, reduction is not completeness-preserving: there may exist inference variable instantiations that satisfy the original constraint but do not satisfy a reduced constraint or bound. This is due to inherent limitations of the algorithm, along with a desire to avoid undue complexity. One effect is that there are expressions for which type argument inference fails to find a solution, but that can be well-typed if the programmer explicitly inserts appropriate types.
A constraint formula of the form ‹Expression → T› is reduced as follows:
If T is a proper type, the constraint reduces to true if the expression is compatible in a loose invocation context with T (§5.3), and false otherwise.
Otherwise, if the expression is a standalone expression (§15.2) of type S, the constraint reduces to ‹S → T›.
Otherwise, the expression is a poly expression (§15.2). The result depends on the form of the expression:
If the expression is a parenthesized expression of the form
(
Expression'
)
, the constraint reduces to
‹Expression' →
T›.
If the expression is a class instance creation expression or a method invocation expression, the constraint reduces to the bound set B3 which would be used to determine the expression's invocation type when targeting T, as defined in §18.5.2. (For a class instance creation expression, the corresponding "method" used for inference is defined in §15.9.3).
This bound set may contain new inference variables, as well as dependencies between these new variables and the inference variables in T.
If the expression is a conditional expression of the form
e1
?
e2
:
e3
, the constraint reduces to two
constraint formulas, ‹e2
→ T› and
‹e3
→ T›.
If the expression is a lambda expression or a method reference expression, the result is specified below.
By treating nested generic method invocations as poly expressions, we improve the behavior of inference for nested invocations. For example, the following is illegal in Java SE 7 but legal in Java SE 8:
ProcessBuilder b = new ProcessBuilder(Collections.emptyList()); // ProcessBuilder's constructor expects a List<String>
When both the outer and the nested invocation require inference, the problem is more difficult. For example:
List<String> ls = new ArrayList<>(Collections.emptyList());
Our approach is to "lift" the bounds inferred for
the nested invocation (simply { α <:
Object
} in the
case of emptyList
) into the outer inference process
(in this case, trying to infer β where the constructor is for
type ArrayList
<
β>
). We also
infer dependencies between the nested inference variables and the
outer inference variables (the constraint
‹List
<
α>
→ Collection
<
β>
›
would reduce to the dependency α = β).
In this way,
resolution of the inference variables in the nested invocation can
wait until additional information can be inferred from the outer
invocation (based on the assignment target, β = String
).
A constraint formula of the form ‹LambdaExpression → T›, where T mentions at least one inference variable, is reduced as follows:
If T is not a functional interface type (§9.8), the constraint reduces to false.
Otherwise, let T' be the ground target type derived from
T, as specified in §15.27.3.
If
§18.5.3 is
used to derive a functional
interface type which is parameterized, then the test that
F<
A'1, ..., A'm>
is a subtype of
F<
A1,
..., Am>
is not
performed (instead, it
is asserted with a constraint formula below). Let the target
function type for the lambda expression be the function type of
T'. Then:
If no valid function type can be found, the constraint reduces to false.
Otherwise, the congruence of LambdaExpression with the target function type is asserted as follows:
If the number of lambda parameters differs from the number of parameter types of the function type, the constraint reduces to false.
If the lambda expression is implicitly typed and one or more of the function type's parameter types is not a proper type, the constraint reduces to false.
This condition never arises in practice, due to the handling of implicitly typed lambda expressions in §18.5.1 and the substitution applied to the target type in §18.5.2.
If the function type's result is void
and the lambda
body is neither a statement expression nor a
void-compatible block, the constraint reduces to
false.
If the function type's result is not void
and the
lambda body is a block that is not value-compatible, the
constraint reduces to false.
Otherwise, the constraint reduces to all of the following constraint formulas:
If the lambda parameters have explicitly declared types
F1, ..., Fn and the
function type has parameter types
G1, ..., Gn, then i) for
all i (1 ≤ i
≤ n),
‹Fi = Gi›, and
ii)
‹T' <:
T›.
If the function type's return type is a (non-void
) type
R, assume the lambda's
parameter types are the same as the
function type's parameter types. Then:
If R is a proper type, and if the lambda body or some result expression in the lambda body is not compatible in an assignment context with R, then false.
Otherwise, if R is
not a proper type, then where the
lambda body has the form Expression,
the constraint
‹Expression
→ R›; or
where the
lambda body is a block with result
expressions e1
,
..., em
,
for all i
(1 ≤ i
≤ m),
‹ei
→ R›.
The key piece of information to derive from a compatibility constraint involving a lambda expression is the set of bounds on inference variables appearing in the target function type's return type. This is crucial, because functional interfaces are often generic, and many methods operating on these types are generic, too.
In the simplest case, a lambda expression may simply provide a lower bound for an inference variable:
<T> List<T> makeThree(Factory<T> factory) { ... }
String s = makeThree(() ->
"abc").get(2);
In more complex cases, a result expression may be a poly expression - perhaps even another lambda expression - and so the inference variable might be passed through multiple constraint formulas with different target types before a bound is produced.
Most of the work described in this section precedes assertions about the result expressions; its purpose is to derive the lambda expression's function type, and to check for expressions that are clearly disqualified from compatibility.
We do not attempt to produce
bounds on inference variables that appear in the target function
type's throws
clause. This is because exception containment is not
part of compatibility (§15.27.3) - in
particular,
it must not influence method applicability
(§18.5.1).
However, we do
get bounds on these variables later, because invocation type inference
(§18.5.2)
produces exception containment
constraint formulas (§18.2.5).
Note that if the target type is an inference variable, or if the target type's parameter types contain inference variables, we produce false. During invocation type inference (§18.5.2), extra substitutions are performed in order to instantiate these inference variables, thus avoiding this scenario. (In other words, reduction will, in practice, never be "invoked" with a target type of one of these forms.)
Finally, note that the result expressions of a
lambda expression are required by §15.27.3
to be
compatible in an assignment context with the target type's return
type, R. If R is a proper type, such as Byte
derived
from Function
,
then
assignability is easy enough to test, and reduction does so above. If
R is not a proper type, such as α derived
from
<
α,Byte
>
Function
, then we
make the simplifying assumption above that loose invocation
compatibility will be sufficient. The difference between assignment
compatibility and loose invocation compatibility is that only
assignment allows narrowing of constant expressions, such
as <
String,α>
Byte b = 100;
. Consequently, our simplifying
assumption is not completeness-preserving: given target return type
α and an integer literal result expression
100
, it is conceivable that α could be
instantiated to Byte
, but reduction will not in fact produce such a
bound.
A constraint formula of the form ‹MethodReference → T›, where T mentions at least one inference variable, is reduced as follows:
If T is not a functional interface type, or if T is a functional interface type that does not have a function type (§9.9), the constraint reduces to false.
Otherwise, if there does not exist a potentially applicable method for the method reference when targeting T, the constraint reduces to false.
Otherwise, if the method reference is exact (§15.13.1), then let P1, ..., Pn be the parameter types of the function type of T, and let F1, ..., Fk be the parameter types of the potentially applicable method. The constraint reduces to a new set of constraints, as follows:
In the special case where n = k+1, the parameter
of type P1 is to act as the target
reference of the
invocation. The method reference expression necessarily has
the form ReferenceType ::
[TypeArguments] Identifier. The constraint
reduces to ‹P1 <:
ReferenceType› and,
for all i (2 ≤ i
≤ n),
‹Pi
→ Fi-1›.
In all other cases, n = k, and the constraint reduces to, for all i (1 ≤ i ≤ n), ‹Pi → Fi›.
If the function type's result is not void
, let
R be its
return type. Then, if the result of the potentially
applicable compile-time declaration is void
, the
constraint reduces to false. Otherwise,
the constraint
reduces to ‹R' → R›, where
R' is the
result of applying capture conversion
(§5.1.10) to the return type
of the
potentially applicable compile-time declaration.
Otherwise, the method reference is inexact, and:
If one or more of the function type's parameter types is not a proper type, the constraint reduces to false.
This condition never arises in practice, due to the handling of inexact method references in §18.5.1 and the substitution applied to the target type in §18.5.2.
Otherwise, a search for a compile-time declaration is performed, as specified in §15.13.1. If there is no compile-time declaration for the method reference, the constraint reduces to false. Otherwise, there is a compile-time declaration, and:
If the result of the function type is void
, the
constraint reduces to true.
Otherwise, if the method reference expression elides TypeArguments, and the compile-time declaration is a generic method, and the return type of the compile-time declaration mentions at least one of the method's type parameters, then the constraint reduces to the bound set B3 which would be used to determine the method reference's invocation type when targeting the return type of the function type, as defined in §18.5.2. B3 may contain new inference variables, as well as dependencies between these new variables and the inference variables in T.
Otherwise, let R be the return type of the
function type,
and let R' be the result of applying
capture conversion
(§5.1.10) to the
return type of the
invocation type (§<IP_ADDRESS>)
of the
compile-time declaration. If R' is void
, the constraint
reduces to false; otherwise,
the constraint reduces to
‹R' → R›.
The strategy used to determine a return type for a generic referenced method follows the same pattern as for generic method invocations (§18.2.1). This may involve "lifting" bounds into the outer context and inferring dependencies between the two sets of inference variables.
A constraint formula of the form ‹S → T› is reduced as follows:
If S and T are proper types, the constraint reduces to true if S is compatible in a loose invocation context with T (§5.3), and false otherwise.
Otherwise, if S is a primitive type, let S' be the result of applying boxing conversion (§5.1.7) to S. Then the constraint reduces to ‹S' → T›.
Otherwise, if T is a primitive type, let T' be the result of applying boxing conversion (§5.1.7) to T. Then the constraint reduces to ‹S = T'›.
Otherwise, if T is a parameterized type of the form
G<
T1,
..., Tn>
, and there
exists no type of
the form G<
...>
that is a supertype of S, but
the raw type G is a supertype of S, then
the constraint
reduces to true.
Otherwise, if T is an array type of the form G<
T1,
..., Tn>
[]
k, and
there exists no type of the form
G<
...>
[]
k
that is a supertype of S, but the raw type
G[]
k is a supertype of
S,
then the constraint reduces to true. (The notation
[]
k indicates an array type
of k dimensions.)
The fourth and fifth cases are implicit uses of unchecked conversion (§5.1.9). These, along with any use of unchecked conversion in the first case, may result in compile-time unchecked warnings, and may influence a method's invocation type (§<IP_ADDRESS>).
Boxing T to T' is not
completeness-preserving; for example, if T were long
, S might be
instantiated to Integer
, which is not a subtype of Long
but could
be unboxed and then widened to long
. We avoid this problem in most
cases by giving special treatment to inference-variable return types
that we know are already constrained to be certain boxed primitive
types. See §18.5.2.
Similarly, the treatment of unchecked conversion sacrifices completeness in cases in which T is not a parameterized type (for example, if T is an inference variable). It is not usually clear in such situations whether the unchecked conversion is necessary or not. Since unchecked conversions introduce unchecked warnings, inference prefers to avoid them unless it is clearly necessary.
A
constraint formula of the form ‹S <:
T› is
reduced as follows:
If S and T are proper types, the constraint reduces to true if S is a subtype of T (§4.10), and false otherwise.
Otherwise, if S is the null type, the constraint reduces to true.
Otherwise, if T is the null type, the constraint reduces to false.
Otherwise, if S is an inference variable, α,
the
constraint reduces to the bound α <:
T.
Otherwise, if T is an inference variable, α,
the
constraint reduces to the bound S <:
α.
Otherwise, the constraint is reduced according to the form of T:
If T is a parameterized class or interface type, or an
inner class type of a parameterized class or interface type
(directly or indirectly), let A1, ...,
An be the type
arguments of T. Among the supertypes of S, a
corresponding class or interface type is identified, with
type arguments B1, ..., Bn.
If no such type exists, the
constraint reduces to false. Otherwise,
the constraint
reduces to the following new constraints: for all i (1
≤ i
≤ n),
‹Bi <=
Ai›.
If T is any other class or interface type, then the constraint reduces to true if T is among the supertypes of S, and false otherwise.
If T is an array type, T'[]
, then among the
supertypes of S that are array types, a most specific
type
is identified, S'[]
(this
may be S
itself). If no such array type exists, the constraint
reduces to false. Otherwise:
If T is an intersection type, I1 &
...
&
In,
the constraint reduces to the following new constraints: for
all i (1 ≤ i
≤ n),
‹S
<:
Ii›.
A
constraint formula of the form ‹S <=
T›, where
S and T are type arguments (§4.5.1),
is
reduced as follows:
A constraint formula of the form ‹S = T›, where S and T are types, is reduced as follows:
If S and T are proper types, the constraint reduces to true if S is the same as T (§4.3.4), and false otherwise.
Otherwise, if S or T is the null type, the constraint reduces to false.
Otherwise, if S is an inference variable, α, and T is not a primitive type, the constraint reduces to the bound α = T.
Otherwise, if T is an inference variable, α, and S is not a primitive type, the constraint reduces to the bound S = α.
Otherwise, if S and T are class or interface types with the same erasure, where S has type arguments B1, ..., Bn and T has type arguments A1, ..., An, the constraint reduces to the following new constraints: for all i (1 ≤ i ≤ n), ‹Bi = Ai›.
Otherwise, if S and T are array types,
S'[]
and T'[]
, the constraint reduces to
‹S' = T'›.
Note that we do not address intersection types above, because it is impossible for reduction to encounter an intersection type that is not a proper type.
A constraint formula of the form ‹S = T›, where S and T are type arguments (§4.5.1), is reduced as follows:
If S and T are types, the constraint is reduced as described above.
If S has the form ?
and T has the form ?
, the
constraint reduces to true.
If S has the form ?
and T has the form ?
extends
T', the constraint reduces to ‹Object
=
T'›.
If S has the form ?
extends
S' and T has the
form ?
, the constraint reduces to ‹S' =
Object
›.
If S has the form ?
extends
S' and T has the
form ?
extends
T',
the constraint reduces to
‹S' = T'›.
If S has the form ?
super
S' and T has the form
?
super
T', the constraint reduces to
‹S' = T'›.
A constraint formula of the form ‹LambdaExpression →throws T› is reduced as follows:
If T is not a functional interface type (§9.8), the constraint reduces to false.
Otherwise, let the target function type for the lambda expression be determined as specified in §15.27.3. If no valid function type can be found, the constraint reduces to false.
Otherwise, if the lambda expression is implicitly typed, and one or more of the function type's parameter types is not a proper type, the constraint reduces to false.
This condition never arises in practice, due to the substitution applied to the target type in §18.5.2.
Otherwise, if the function type's return type is neither void
nor a proper type, the constraint reduces to false.
This condition never arises in practice, due to the substitution applied to the target type in §18.5.2.
Otherwise, let E1, ..., En be the types in the function
type's throws
clause that are not proper
types. If the lambda expression is implicitly typed, let its
parameter types be the function type's parameter types. If the
lambda body is a poly expression or a block containing a poly
result expression, let the targeted return type be the function
type's return type. Let X1, ..., Xm be the checked exception
types that the lambda body can throw
(§11.2). Then there are
two cases:
If n = 0
(the function type's throws
clause
consists only of proper types), then if there exists some
i (1 ≤
i ≤
m) such that Xi is not a
subtype of any proper type in the throws
clause,
the
constraint reduces to false; otherwise,
the constraint
reduces to true.
If n > 0
,
the constraint reduces to a set of
subtyping constraints: for all i (1 ≤ i
≤
m), if Xi is not a subtype of any proper type in
the
throws
clause, then the constraints include, for
all
j (1 ≤
j ≤
n), ‹Xi <:
Ej›. In addition, for all j (1 ≤ j
≤ n),
the constraint reduces to the bound throws
Ej.
A constraint formula of the form ‹MethodReference →throws T› is reduced as follows:
If T is not a functional interface type, or if T is a functional interface type but does not have a function type (§9.9), the constraint reduces to false.
Otherwise, let the target function type for the method reference expression be the function type of T. If the method reference is inexact (§15.13.1) and one or more of the function type's parameter types is not a proper type, the constraint reduces to false.
Otherwise, if the method reference is inexact and the function
type's result is neither void
nor a proper type, the
constraint reduces to false.
Otherwise, let E1, ..., En be the types in the function
type's throws
clause that are not proper
types. Let X1, ..., Xm be the checked exceptions in the
throws
clause of the invocation type of the method reference's
compile-time declaration (§15.13.2)
(as
derived from the function type's parameter types and return
type). Then there are two cases:
If n = 0
(the function type's throws
clause
consists only of proper types), then if there exists some
i (1 ≤
i ≤
m) such that Xi is not a
subtype of any proper type in the throws
clause,
the
constraint reduces to false; otherwise,
the constraint
reduces to true.
If n > 0
,
the constraint reduces to a set of
subtyping constraints: for all i (1 ≤ i
≤
m), if Xi is not a subtype of any proper type in
the
throws
clause, then the constraints include, for
all
j (1 ≤
j ≤
n), ‹Xi <:
Ej›. In addition, for all j (1 ≤ j
≤ n),
the constraint reduces to the bound throws
Ej.
Constraints on checked exceptions are handled separately from constraints on return types, because return type compatibility influences applicability of methods (§18.5.1), while exceptions only influence the invocation type after overload resolution is complete (§18.5.2). This could be simplified by including exception compatibility in the definition of lambda expression compatibility (§15.27.3), but this would lead to possibly surprising cases in which exceptions that can be thrown by an explicitly typed lambda body change overload resolution.
The exceptions thrown by a lambda body cannot be
determined until i) the parameter types of the lambda are known, and
ii) the target type of result expressions in the body is known. (The
second requirement is to account for generic method invocations in
which, for example, the same type parameter appears in the return type
and the throws
clause.) Hence, we require both of these, as derived
from the target type T, to be proper types.
One consequence is that lambda expressions returned from other lambda expressions cannot generate constraints from their thrown exceptions. These constraints can only be generated from top-level lambda expressions.
Note that the handling of the case in which more
than one inference variable appears in a function type's throws
clause is not completeness-preserving. Either variable may, on its
own, satisfy the constraint that each checked exception be declared,
but we cannot be sure which one is intended. So, for predictability,
we constrain them both.
As bound sets are constructed and grown during inference, it is possible that new bounds can be inferred based on the assertions of the original bounds. The process of incorporation identifies these new bounds and adds them to the bound set.
Incorporation can happen in two scenarios. One scenario is that the bound set contains complementary pairs of bounds; this implies new constraint formulas, as specified in §18.3.1. The other scenario is that the bound set contains a bound involving capture conversion; this implies new bounds and may imply new constraint formulas, as specified in §18.3.2. In both scenarios, any new constraint formulas are reduced, and any new bounds are added to the bound set. This may trigger further incorporation; ultimately, the set will reach a fixed point and no further bounds can be inferred.
If incorporation of a bound set has reached a fixed point, and the set does not contain the bound false, then the bound set has the following properties:
For each combination of a proper lower bound L
and a proper
upper bound U of an inference variable, L
<:
U.
If every inference variable mentioned by a bound has an instantiation, the bound is satisfied by the corresponding substitution.
Given a dependency α = β, every bound of α matches a bound of β, and vice versa.
Given a dependency α <:
β, every lower bound
of α is a lower bound of β,
and every upper bound of
β is an upper bound of α.
The assertion that incorporation reaches a fixed point oversimplifies the matter slightly. Building on the work of Kennedy and Pierce, On Decidability of Nominal Subtyping with Variance, this property can be proven by making the argument that the set of types that may appear in the bound set is finite. The argument relies on two assumptions:
New capture variables are not generated when reducing subtyping constraints (§18.2.3).
Expansive inheritance paths are not pursued.
This specification does not currently guarantee these properties (it is imprecise about the handling of wildcards when reducing subtyping constraints, and does not detect expansive inheritance paths), but may do so in a future version. (This is not a new problem: the Java subtyping algorithm is also at risk of non-termination.)
(In this section, S and T are inference variables or types, and U is a proper type. For conciseness, a bound of the form α = T may also match a bound of the form T = α.)
When a bound set contains a pair of bounds that match one of the following rules, a new constraint formula is implied:
When a bound set contains a pair of bounds α <:
S and
α <:
T, and
there exists a supertype of S of the form
G<
S1,
..., Sn>
and a supertype of T of the form
G<
T1,
..., Tn>
(for some generic class or
interface, G), then for all i (1 ≤ i ≤
n), if
Si and Ti are types (not
wildcards), the constraint formula
‹Si = Ti› is
implied.
When a
bound set contains a bound of the form G<
α1, ...,
αn>
= capture(G<
A1, ..., An>
), new
bounds are implied and new constraint formulas may be implied, as
follows.
Let P1,
..., Pn represent the type parameters of G and let B1, ..., Bn
represent the bounds of these type parameters. Let θ represent
the substitution [
P1:=α1, ..., Pn:=αn]
.
Let R be a type that is not an
inference
variable (but is not necessarily a proper type).
A set of bounds on α1, ..., αn is implied, constructed from the declared bounds of P1, ..., Pn as specified in §18.1.3.
In addition, for all i (1 ≤ i ≤ n):
Given a bound set that does not contain the bound false, a subset of the inference variables mentioned by the bound set may be resolved. This means that a satisfactory instantiation may be added to the set for each inference variable, until all the requested variables have instantiations.
Dependencies in the bound set may require that the variables be resolved in a particular order, or that additional variables be resolved. Dependencies are specified as follows:
Given a bound of one of the following forms, where T is either an inference variable β or a type that mentions β:
If α appears on the left-hand side of another bound of the
form G<
..., α,
...>
=
capture(G<
...>
),
then β depends on the
resolution of α. Otherwise, α
depends on the
resolution of β.
An inference variable α appearing on the left-hand side of
a bound of the form G<
..., α, ...>
=
capture(G<
...>
)
depends on the resolution of
every other inference variable mentioned in this bound (on both
sides of the = sign).
An inference variable α depends on the resolution of an inference variable β if there exists an inference variable γ such that α depends on the resolution of γ and γ depends on the resolution of β.
An inference variable α depends on the resolution of itself.
Given a set of inference variables to resolve, let V be the union of this set and all variables upon which the resolution of at least one variable in this set depends.
If every variable in V has an instantiation, then resolution succeeds and this procedure terminates.
Otherwise, let { α1, ..., αn } be a non-empty subset of uninstantiated variables in V such that i) for all i (1 ≤ i ≤ n), if αi depends on the resolution of a variable β, then either β has an instantiation or there is some j such that β = αj; and ii) there exists no non-empty proper subset of { α1, ..., αn } with this property. Resolution proceeds by generating an instantiation for each of α1, ..., αn based on the bounds in the bound set:
If the bound set does not contain a bound of the form
G<
..., αi, ...>
=
capture(G<
...>
)
for all i (1 ≤ i
≤ n), then a candidate
instantiation Ti is defined
for each αi:
If αi has one
or more proper
lower bounds, L1
, ..., Lk
, then Ti
= lub(L1
, ...,
Lk
) (§4.10.4).
Otherwise, if the bound set contains throws
αi, and
the proper upper bounds of αi are, at most,
Exception
, Throwable
, and
Object
, then Ti =
RuntimeException
.
Otherwise, where αi has proper upper bounds U1, ..., Uk, Ti = glb(U1, ..., Uk) (§5.1.10).
The bounds α1 = T1, ..., αn = Tn are incorporated with the current bound set.
If the result does not contain the bound false, then the result becomes the new bound set, and resolution proceeds by selecting a new set of variables to instantiate (if necessary), as described above.
Otherwise, the result contains the bound false, so a second attempt is made to instantiate { α1, ..., αn } by performing the step below.
If the bound set contains a bound of the form G<
...,
αi, ...>
= capture(G<
...>
) for some
i (1 ≤ i ≤ n), or;
If the bound set produced in the step above contains the bound false;
then let Y1, ..., Yn be fresh type variables whose bounds are as follows:
For all i (1 ≤ i ≤ n), if
αi
has one or more proper lower bounds
L1
, ..., Lk
,
then let the lower bound of Yi be
lub(L1
, ..., Lk
); if not, then Yi has no lower
bound.
For all i (1 ≤ i ≤ n),
where αi
has upper bounds U1, ..., Uk, let the upper bound of
Yi be glb(U1 θ, ...,
Uk θ), where
θ is
the substitution [
α1:=Y1, ..., αn:=Yn]
.
If the type variables Y1, ..., Yn do not have well-formed bounds (that is, a lower bound is not a subtype of an upper bound, or an intersection type is inconsistent), then resolution fails.
Otherwise, for all i (1 ≤ i ≤ n), all
bounds of the form G<
..., αi, ...>
=
capture(G<
...>
)
are removed from the current
bound set, and the bounds α1 = Y1, ..., αn = Yn
are incorporated.
If the result does not contain the bound false, then the result becomes the new bound set, and resolution proceeds by selecting a new set of variables to instantiate (if necessary), as described above.
Otherwise, the result contains the bound false, and resolution fails.
The first method of instantiating an inference variable derives the instantiation from that variable's bounds. Sometimes, however, complex dependencies mean that the result is not within the variable's bounds. In that case, a different method of instantiation is performed, analogous to capture conversion (§5.1.10): fresh type variables are introduced, with bounds derived from the bounds of the inference variables. Note that the lower bounds of these "capture" variables are computed using only proper types: this is important in order to avoid attempts to perform typing computations on uninstantiated type variables.
Using the inference processes defined above, the following analyses are performed at compile time.
Given a
method invocation that provides no explicit type arguments, the
process to determine whether a potentially applicable generic method
m
is applicable is as follows:
Where P1, ..., Pp
(p ≥ 1) are the
type parameters
of m
, let α1,
..., αp be inference
variables, and
let θ be the substitution [
P1:=α1, ...,
Pp:=αp]
.
An initial bound set, B0, is constructed from the declared bounds of P1, ..., Pp, as described in §18.1.3.
For all i (1 ≤
i ≤ p), if Pi
appears in
the throws
clause of m
, then the
bound throws
αi is
implied. These bounds, if any, are incorporated with B0
to
produce a new bound set, B1.
A set of constraint formulas, C, is constructed as follows.
Let F1, ..., Fn be
the formal parameter types of m
, and
let e1
, ..., ek
be the actual argument expressions of the
invocation. Then:
To test for applicability by strict invocation:
If k ≠
n, or if there exists an i (1
≤ i
≤ n)
such that ei
is pertinent to
applicability (§<IP_ADDRESS>)
and either
i) ei
is a standalone expression of a
primitive type but
Fi is a reference type, or ii) Fi is a primitive type
but ei
is not a standalone expression of
a primitive type;
then the method is not applicable and there is no need to
proceed with inference.
Otherwise, C includes, for all i
(1 ≤ i
≤ k)
where ei
is pertinent to applicability,
‹ei
→ Fi
θ›.
To test for applicability by loose invocation:
If k ≠ n, the method is not applicable and there is no need to proceed with inference.
Otherwise, C includes, for all i
(1 ≤ i
≤ k)
where ei
is pertinent to applicability,
‹ei
→ Fi
θ›.
To test for applicability by variable arity invocation:
Let F'1, ..., F'k be the first k variable
arity parameter types of m
(§<IP_ADDRESS>).
C includes, for all
i (1 ≤
i ≤
k) where ei
is pertinent
to applicability, ‹ei
→ F'i
θ›.
C is reduced (§18.2) and the resulting bounds are incorporated with B1 to produce a new bound set, B2.
Finally, the method m
is applicable if B2 does not contain
the bound false and resolution of all the inference
variables in B2 succeeds (§18.4).
Consider the following method invocation and assignment:
List<Number> ln = Arrays.asList(1, 2.0);
A most specific applicable method for the invocation must be identified as described in §15.12. The only potentially applicable method (§<IP_ADDRESS>) is declared as follows:
public static <T> List<T> asList(T... a)
Trivially (because of its arity), this method is neither applicable by strict invocation (§<IP_ADDRESS>) nor applicable by loose invocation (§<IP_ADDRESS>). But since there are no other candidates, in a third phase the method is checked for applicability by variable arity invocation.
The initial bound set, B, is a trivial upper bound for a single inference variable, α:
{ α <:
Object
}
The initial constraint formula set is as follows:
{ ‹1
→ α›,
‹2.0
→ α›
}
These are reduced to a new bound set, B1:
{ α <:
Object
,
Integer
<:
α,
Double
<:
α }
Then, to test whether the method is applicable, we attempt to resolve these bounds. We succeed, producing the rather complex instantiation
α = Number & Comparable<?
extends Number & Comparable<?>>
We have thus demonstrated that the method is applicable; since no other candidates exist, it is the most specific applicable method. Still, the type of the method invocation, and its compatibility with the target type in the assignment, is not determined until further inference can occur, as described in the next section.
Given a
method invocation that provides no explicit type arguments, and a
corresponding most specific applicable generic method m
, the process
to infer the invocation type (§<IP_ADDRESS>) of
the
chosen method is as follows:
Let θ be the substitution [
P1:=α1, ...,
Pp:=αp]
defined in §18.5.1
to replace the type parameters of m
with inference
variables.
Let B2 be the bound set produced by reduction in order
to
demonstrate that m
is applicable in
§18.5.1. (While it was
necessary in
§18.5.1 to demonstrate
that the inference
variables in B2 could be resolved, in order to
establish
applicability, the instantiations produced by this resolution
step are not considered part of B2.)
If the invocation is not a poly expression, let the bound set B3 be the same as B2.
If the invocation is a poly expression, let the bound set B3
be derived from B2 as follows. Let R be the return type of
m
, let T be the invocation's target
type, and then:
If unchecked conversion was necessary for the method to be applicable during constraint set reduction in §18.5.1, the constraint formula ‹|R| → T› is reduced and incorporated with B2.
Otherwise, if R θ is
a parameterized type,
G<
A1,
..., An>
,
and one of A1, ...,
An is a wildcard, then, for fresh inference
variables
β1, ...,
βn, the
constraint formula
‹G<
β1, ...,
βn>
→
T› is reduced and incorporated, along with the
bound
G<
β1, ...,
βn>
=
capture(G<
A1, ..., An>
), with
B2.
Otherwise, if R θ is an inference variable α, and one of the following is true:
T is a reference type, but is not a
wildcard-parameterized type, and either i) B2
contains
a bound of one of the forms α =
S or S
<:
α, where S is a wildcard-parameterized
type, or ii) B2 contains two
bounds of the forms S1
<:
α and S2 <:
α, where S1
and S2 have supertypes that are
two different
parameterizations of the same generic class or
interface.
T is a parameterization of a generic class
or
interface, G, and B2 contains a bound of one of
the
forms α = S or S <:
α, where
there exists no type of the form G<
...>
that is a supertype of S, but the raw type
|G<
...>
| is a supertype of S.
T is a primitive type, and one of the primitive wrapper classes mentioned in §5.1.7 is an instantiation, upper bound, or lower bound for α in B2.
then α is resolved in B2, and where the capture of the resulting instantiation of α is U, the constraint formula ‹U → T› is reduced and incorporated with B2.
Otherwise, the constraint formula ‹R θ → T› is reduced and incorporated with B2.
A set of constraint formulas, C, is constructed as follows.
Let e1
, ..., ek
be the actual argument expressions of the
invocation. If m
is applicable by strict or loose invocation,
let F1, ..., Fk be
the formal parameter types of m
; if m
is applicable by variable arity invocation, let F1,
..., Fk
the first k variable arity parameter types of m
(§<IP_ADDRESS>).
Then:
For all i (1 ≤ i
≤ k),
if ei
is not
pertinent to applicability, C contains ‹ei
→
Fi θ›.
For all i (1 ≤ i
≤ k),
additional
constraints may be included, depending on the form of ei
:
If ei
is a LambdaExpression,
C contains ‹LambdaExpression →throws Fi θ›.
In addition, the lambda body is searched for additional constraints:
For a block lambda body, the search is applied recursively to each result expression.
For a poly class instance creation expression (§15.9) or a poly method invocation expression (§15.12), C contains all the constraint formulas that would appear in the set C generated by §18.5.2 when inferring the poly expression's invocation type.
For a parenthesized expression, the search is applied recursively to the contained expression.
For a conditional expression, the search is applied recursively to the second and third operands.
For a lambda expression, the search is applied recursively to the lambda body.
If ei
is a MethodReference,
C contains ‹MethodReference →throws Fi θ›.
If ei
is a poly class
instance creation expression
(§15.9)
or a poly method invocation
expression (§15.12),
C contains
all the constraint formulas that would appear in the set
C generated by §18.5.2
when
inferring the poly expression's invocation type.
If ei
is a parenthesized
expression,
these rules are applied recursively to the contained expression.
If ei
is a conditional
expression,
these rules are applied recursively to the second and third
operands.
While C is not empty, the following process is repeated, starting with the bound set B3 and accumulating new bounds into a "current" bound set, ultimately producing a new bound set, B4:
A subset of constraints is selected in C, satisfying the property that, for each constraint, no input variable can influence an output variable of another constraint in C. The terms input variable and output variable are defined below. An inference variable α can influence an inference variable β if α depends on the resolution of β (§18.4), or vice versa; or if there exists a third inference variable γ such that α can influence γ and γ can influence β.
If this subset is empty, then there is a cycle (or cycles) in the graph of dependencies between constraints. In this case, all constraints are considered that participate in a dependency cycle (or cycles) and do not depend on any constraints outside of the cycle (or cycles). A single constraint is selected from the considered constraints, as follows:
If any of the considered constraints have the form ‹Expression → T›, then the selected constraint is the considered constraint of this form that contains the expression to the left (§3.5) of the expression of every other considered constraint of this form.
If no considered constraint has the form ‹Expression → T›, then the selected constraint is the considered constraint that contains the expression to the left of the expression of every other considered constraint.
The input variables α1, ..., αm of all the selected constraint(s) are resolved.
Where T1, ..., Tm are the instantiations of α1,
..., αm,
the substitution [
α1:=T1, ...,
αm:=Tm]
is
applied to every constraint.
The constraint(s) resulting from substitution are reduced and incorporated with the current bound set.
Finally, if B4 does not contain the bound false, the inference variables in B4 are resolved.
If resolution succeeds with instantiations T1, ...,
Tp for
inference variables α1,
..., αp, let θ' be
the substitution [
P1:=T1, ...,
Pp:=Tp]
. Then:
If unchecked conversion was necessary for the method to be
applicable during constraint set reduction in
§18.5.1,
then the parameter types of
the invocation type of m
are obtained by applying
θ' to the parameter types of m
's type, and the
return type and thrown types of the invocation type of m
are given by the erasure of the return type and thrown types
of m
's type.
If unchecked conversion was not necessary for the method to
be applicable, then the invocation type of m
is
obtained
by applying θ' to the type of m
.
If B4 contains the bound false, or if resolution fails, then a compile-time error occurs.
Invocation type inference may require carefully sequencing the reduction of constraint formulas of the forms ‹Expression → T›, ‹LambdaExpression →throws T›, and ‹MethodReference →throws T›. To facilitate this sequencing, the input variables of these constraints are defined as follows:
If T is an inference variable, it is the (only) input variable.
If T is a functional interface type, and a function
type
can be derived from T (§15.27.3),
then the input variables include i) if the lambda expression
is implicitly typed, the inference variables mentioned by
the function type's parameter types; and ii) if the function
type's return type, R, is not void
,
then for each result
expression e
in the lambda body (or for the body
itself if
it is an expression), the input variables of ‹e
→ R›.
For ‹LambdaExpression →throws T›:
If T is an inference variable, it is the (only) input variable.
If T is a functional interface type, and a function type can be derived, as described in §15.27.3, the input variables include i) if the lambda expression is implicitly typed, the inference variables mentioned by the function type's parameter types; and ii) the inference variables mentioned by the function type's return type.
If T is an inference variable, it is the (only) input variable.
If T is a functional interface type with a function type, and if the method reference is inexact (§15.13.1), the input variables are the inference variables mentioned by the function type's parameter types.
For ‹MethodReference →throws T›:
If T is an inference variable, it is the (only) input variable.
If T is a functional interface type with a function type, and if the method reference is inexact (§15.13.1), the input variables are the inference variables mentioned by the function type's parameter types and the function type's return type.
For ‹Expression → T›, if Expression is a parenthesized expression:
Where the contained expression of Expression is Expression', the input variables are the input variables of ‹Expression' → T›.
For ‹ConditionalExpression → T›:
Where the conditional expression has the form e1
?
e2
:
e3
, the input
variables are the input variables of
‹e2
→ T› and ‹e3
→
T›.
For all other constraint formulas, there are no input variables.
The output variables of these constraints are all inference variables mentioned by the type on the right-hand side of the constraint, T, that are not input variables.
It is important to note that two "rounds" of inference are involved in finding the type of a method invocation. This is necessary to allow a target type to influence the type of the invocation without allowing it to influence the choice of an applicable method. The first round produces a bound set and tests that a resolution exists, but does not commit to that resolution. The second round reduces additional constraints and then performs a second resolution, this time "for real".
Consider the example from the previous section:
List<
Number>
ln = Arrays.asList(1, 2.0);
The most specific applicable method was identified as:
public static<
T>
List<
T>
asList(T... a)
In order to complete type-checking of the method
invocation, we must determine whether it is compatible with its target
type, List
.
<
Number>
The bound set used to demonstrate applicability in the previous section, B2, was:
{ α <:
Object
,
Integer
<:
α,
Double
<:
α }
The new constraint formula set is as follows:
{ ‹List
→
<
α>
List
› }
<
Number>
This compatibility constraint produces an equality bound for α, which is included in the new bound set, B3:
{ α <:
Object
,
Integer
<:
α,
Double
<:
α,
α = Number
}
These bounds are trivially resolved:
α = Number
Finally, we perform a substitution on the declared
return type of asList
to determine that the method
invocation has type List
;
clearly, this is compatible with the target type.
<
Number>
This inference strategy is different than the Java
SE 7 Edition of The Java® Language
Specification, which would have instantiated α based
on its lower bounds (before even considering the invocation's target
type), as we did in the previous section. This would result in a type
error, since the resulting type is not a subtype
of List
.
<
Number>
Under various special circumstances, based on the bounds appearing in B2, we eagerly resolve an inference variable that appears as the return type of the invocation. This is to avoid unfortunate situations in which the usual constraint, ‹R θ → T›, is not completeness-preserving. It is, unfortunately, possible that by eagerly resolving the variable, we are unable to make use of bounds that would be inferred later. It is also possible that, in some cases, bounds that will later be inferred from the invocation arguments (such as implicitly typed lambda expressions) would have caused a different outcome if they had been present in B2. Despite these limitations, the strategy allows for reasonable outcomes in typical use cases, and is backwards compatible with the algorithm in the Java SE 7 Edition of The Java® Language Specification.
Where a lambda expression with explicit parameter types P1, ...,
Pn targets a functional interface type F<
A1,
...,
Am>
with at least one wildcard type
argument, then a
parameterization of F may be derived as the ground target type of
the lambda expression as follows.
Let Q1, ..., Qk be the
parameter types of the function type of the
type F<
α1, ..., αm>
, where α1, ...,
αm are fresh inference variables.
If n ≠ k, no valid parameterization exists. Otherwise, a set of constraint formulas is formed with, for all i (1 ≤ i ≤ n), ‹Pi = Qi›. This constraint formula set is reduced to form the bound set B.
If B contains the bound false, no valid
parameterization
exists. Otherwise, a new parameterization of the functional interface
type, F<
A'1, ..., A'm>
, is constructed as
follows, for 1 ≤ i ≤ m:
If B contains an instantiation (§18.1.3) for αi, T, then A'i = T.
If F<
A'1,
..., A'm>
is not a well-formed
type (that is, the type arguments are not within their bounds), or if
F<
A'1,
..., A'm>
is not a subtype of
F<
A1,
..., Am>
, no valid parameterization
exists. Otherwise, the inferred parameterization is either
F<
A'1,
..., A'm>
, if all the type
arguments are types, or the non-wildcard parameterization
(§9.9) of F<
A'1,
...,
A'm>
, if one or more type arguments
are still
wildcards.
In order to determine the function type of a wildcard-parameterized functional interface, we have to "instantiate" the wildcard type arguments with specific types. The "default" approach is to simply replace the wildcards with their bounds, as described in §9.8, but this produces spurious errors in cases where a lambda expression has explicit parameter types that do not correspond to the wildcard bounds. For example:
Predicate<? super Integer> p = (Number n) ->
n.equals(23);
The lambda expression is
a Predicate<Number>
, which is a subtype
of Predicate<? super Integer>
but
not Predicate<Integer>
. The analysis in this
section is used to infer that Number
is an
appropriate choice for the type argument
to Predicate
.
That said, the analysis here, while described in terms of general type inference, is intentionally quite simple. The only constraints are equality constraints, which means that reduction amounts to simple pattern matching. A more powerful strategy might also infer constraints from the body of the lambda expression. But, given possible interactions with inference for surrounding and/or nested generic method invocations, this would introduce a lot of extra complexity.
When testing that one applicable method is more specific than another (§<IP_ADDRESS>), where the second method is generic, it is necessary to test whether some instantiation of the second method's type parameters can be inferred to make the first method more specific than the second.
Let m1
be the first method and m2
be the second method. Where m2
has type
parameters P1, ..., Pp, let
α1, ..., αp be inference
variables, and let θ be the substitution [
P1:=α1,
..., Pp:=αp]
.
Let e1
,
..., ek
be the argument expressions of the corresponding
invocation. Then:
If m1
and m2
are applicable by strict or loose invocation
(§<IP_ADDRESS>,
§<IP_ADDRESS>),
then let S1, ..., Sk be
the formal parameter types of m1
, and let T1, ..., Tk be
the result of θ applied to the formal parameter types of
m2
.
If m1
and m2
are applicable by variable arity invocation
(§<IP_ADDRESS>),
then let S1, ..., Sk be
the first k variable arity parameter types of m1
, and let
T1, ..., Tk be the
result of θ applied to the first
k variable arity parameter types of m2
.
Note that no substitution is applied to S1, ...,
Sk; even if m1
is generic,
the type parameters of m1
are treated
as type variables, not inference variables.
The
process to determine if m1
is more specific than m2
is as
follows:
First, an initial bound set, B, is constructed from the declared bounds of P1, ..., Pp, as specified in §18.1.3.
Second, for all i (1 ≤ i ≤ k), a set of constraint formulas or bounds is generated.
If Ti is a proper type, the result is true if Si is
more specific than Ti for ei
(§<IP_ADDRESS>), and
false
otherwise. (Note that Si is always a proper type.)
Otherwise, if Ti is not a functional interface type,
the
constraint formula ‹Si <:
Ti› is
generated.
Otherwise, Ti is a parameterization of a functional interface, I. It must be determined whether Si satisfies the following five conditions:
Si is not a superinterface of I, nor a parameterization of a superinterface of I.
Si is not a subinterface of I, nor a parameterization of a subinterface of I.
If Si is an intersection type, at least one element of the intersection is not a superinterface of I, nor a parameterization of a superinterface of I.
If Si is an intersection type, no element of the intersection is a subinterface of I, nor a parameterization of a subinterface of I.
If all five conditions are true, then the following constraint formulas or bounds are generated (where U1 ... Uk and R1 are the parameter types and return type of the function type of the capture of Si, and V1 ... Vk and R2 are the parameter types and return type of the function type of Ti):
If ei
is an explicitly typed lambda
expression:
Otherwise, if R1 and R2 are functional interface
types, and neither interface is a subinterface of the
other, and ei
has at least
one result expression, then
these rules are applied recursively to R1 and R2,
for each result expression in ei
.
Otherwise, if R1 is a primitive
type and R2 is not,
and ei
has at least one
result expression,
and each result expression of ei
is a standalone
expression (§15.2)
of a primitive
type, true.
Otherwise, if R2 is a primitive
type and R1 is not,
and ei
has at least one
result expression,
and each result expression of ei
is either a
standalone expression of a reference type or a poly
expression, true.
If ei
is a parenthesized expression,
these rules are
applied recursively to the contained expression.
If ei
is a conditional expression, these
rules are applied
recursively to each of the second and third operands.
If the five constraints on Si are not satisfied, the
constraint formula ‹Si <:
Ti› is
generated instead.
Third, if m2
is applicable by variable arity
invocation and
has k+1 parameters, then where Sk+1 is the k+1'th
variable arity parameter type of m1
and Tk+1 is the
result of θ applied to the k+1'th variable arity
parameter type of m2
, the constraint ‹Sk+1
<:
Tk+1› is
generated.
Fourth, the generated bounds and constraint formulas are reduced and incorporated with B to produce a bound set B'.
If B' does not contain the bound false, and
resolution of all the inference variables in B' succeeds,
then m1
is more specific than m2
.


John R. Fetcher Jr
Democrat
Rancher
M S in Genetics from CSU
80487
Regional Representative for Senators Ken Salazar and Mark Udall.
Resume of JAY FETCHER Box 866 Clark, Co. 80428<PHONE_NUMBER> (h)<PHONE_NUMBER>(c<EMAIL_ADDRESS>EDUCATION Colorado State University, Ft. Collins, Co. Master of Science with Discipline in Genetics, 1980. University of Wyoming, Laramie, Wy. Bachelor of Science 1969. EXPERIENCE Managing partner of family partnership ranching operation including Bill Fetcher, my wife, Gael M. Fetcher, and daughter, Molly Lotz with her husband, Jonah Lotz from 1969 to present. Regional Representative, U S Senator Ken Salazar March 2005 to December 2008 Regional Representative, U S Senator Michael Bennet December 2008 to February 2009 Regional Director, U S Senator Mark Udall February 2009 to January 2015. COMMUNITY SERVICE AND ORGANIZATIONS HB1264 working group on Conservation easements April 2019 to Dec 2019 Governor Polis Transition Team for Ag, DNR, Energy Nov 2018 to Jan 2019 Steamboat School Advisory Committee Fall 2018 to 2019 Conservation Colorado Board Director 2016 to present Yampa Valley Community Foundation Director 2014 to 2019 Hickenlooper Transition Team Nov-Dec 2010 Agriculture Committee River Access Dispute Resolution Task Force Commission member 2010 Resources First Foundation 2008 to present. Advisory board member Ritter Transition Team Nov-Dec 2006 Agriculture Committee Yampa Valley Medical Center Director January 2005 to 2007 Colorado Environmental Coalition Director January 2005 Candidate for Colorado Senate District 8 2004 Statewide Water Supply Initiative Yampa/White/Green Basin Round Table 2004 Colorado Cattlemen’s Agricultural Land Trust Founder and Director 1995 to 2007, 2015 to present. Chairman 1996 to 2004 Mountain West Environment Board of Directors 1990 to present. Colorado 100 Co-chairman, Dec 4, 2003 Tax initiative meeting Community Agricultural Alliance Board Member 1999-2003 Colorado Water Trust Board Member 2000-2003 Colorado Reapportionment Commission Vice-chairman 2001-2002 Democratic Candidate House District 56 2000 Steamboat Springs School Board Secretary 1992 to 1993 Director 1991 to 1992 President 1987 to 1991 Director 1984 to 1987 Steamboat Springs Education Fund Growth commission Chairman 1996 to 1999. Commission member 1993 to 1994. Steamboat Springs High School Audit Team Audit team member 2001 to 2003 Routt County Cattlemen’s Assn. President 1990 to 1992 Vice president 1988 to 1990 Secretary 1986 to 1988 Director 1978 to 1986 Governor’s Smart Growth Task Force Agricultural Lands Conversion Task Force 1995 Yampa Valley Land Trust Director 1993 to 1995 The Nature Conservancy Advisory Board Chairman 1994 to present Director 1993 to1994 Colorado Agricultural Leadership Council Member of Class III 1988 to 1990 AWARDS George E. Cranmer award from Colorado Open Lands 2009. Colorado Nonprofit Assn. William Funk Award for 2008. American Land Conservation Award 1997 Governor’s Smart Growth Award 1996 Friend of Education Steamboat Springs School District 1995 National Assn. For Community Development Distinguished Leadership Award 1994 Environment 2000, 1993 Shining Star Award for excellence and commitment to environmental responsibility Colorado Reapportionment Commission Vice-chairman 2001-2002
Colorado Cattlemens Agricultural Land Trust Conservation Colorado
To represent western Colorado
Past work with constituents in Northwest Colorado
male


When I hear the buzz of the little world among the stalks, and grow familiar with the countless indescribable forms of the insects and flies, then I feel the presence of the Almighty, who formed us in his own image, and the breath of that universal love which bears and sustains us.
And then, my friend, when darkness overspreads my eyes, and heaven and earth seem to dwell in my soul and absorb its power, like the form of a beloved mistress, then I often think with longing, Oh, would I could describe these conceptions, could impress upon paper all that is living so full.
A wonderful serenity has taken possession of my entire soul, like these sweet mornings.
I am alone, and feel the charm of existence in this spot, which was created for the bliss.
So absorbed in the exquisite sense of mere tranquil existence.
At the present moment and yet I feel that I never was a greater artist than now.
And the meridian sun strikes the upper surface of the impenetrable foliage.
I throw myself down among the tall grass by the trickling stream.
And, as I lie close to the earth, a thousand unknown plants are noticed by me.
When I hear the buzz of the little world among the stalks, and grow familiar.
A wonderful serenity has taken possession of my entire soul, like these sweet mornings.
I am alone, and feel the charm of existence in this spot, which was created for the bliss.
So absorbed in the exquisite sense of mere tranquil existence.
At the present moment and yet I feel that I never was a greater artist than now.
And the meridian sun strikes the upper surface of the impenetrable foliage.
I throw myself down among the tall grass by the trickling stream.
And, as I lie close to the earth, a thousand unknown plants are noticed by me.
When I hear the buzz of the little world among the stalks, and grow familiar.
A wonderful serenity has taken possession of my entire soul, like these sweet mornings.


MAP RESEARCH
Found examples of interesting and sometimes successful uses of datasets + geography. Usually with a map, but not always.
Luminocity uses the 2011 Census data to create a fascinating interactive map tool. The hexagonal tiles/stacks are good, as are the heatmap palettes.
LEFT: Hex grid again, but note the joined up tiles to create regions.
RIGHT: Hex grid used to apply population density as a distortion to the natural map. Getting away from 100% geographic seems useful.
Three variations of the rail map as simplified and abstracted to provide maximum information on connectivity without being too bothered about absolute geographic accuracy.
Three variations mapping datapoints onto the map, highlight that it clearly has limitations with even a relatively low number of points.
Showing the abstraction of geography while making the data better understood - the linear plot does keep the geographic groupings of countries, which seems useful.


POWER8 enablement.
POWER8 Optimized scheduler.
Requires at least POWER7.
POWER8 Transactional Memory enablement.
POWER8 Crypto Operations enablement.
POWER8 Fusion enablement.
POWER8 optimized system libraries.
GCC creates binaries using --mcpu=power7 --mtune=power8 by default.
Support for Go Programming Language.
Support for split stack.
Support for lock elision on glibc.
New features in 9.0-7
Previous releases
New features in 9.0-6
- zlib provides:
- Fix deflate stored bug when pulling last block from window.
- Permit immediate deflateParams changes before any deflate input.
- Improve compress() and uncompress() to support large lengths.
- Fix bugs in creating a very large gzip header.
- Dramatically speed up deflation for level 0 (storing).
- MPFR provides C++11 compatibility.
- Python provides fixes for CVE-2015-1283, CVE-2016-0772, CVE-2016-5636 and CVE-2016-5699.
- OpenSSL provides fixes for CVE-2016-8610, CVE-2017-3731, CVE-2017-3732, CVE-2017-3733, CVE-2017-3736 and CVE-2017-3735.
New features in 9.0-5
- GCC provides a fix for the vector swap optimization.
- Oprofile provides support for the POWER 8 NV and NVL variants.
- Fixed Power 8 tuned libraries.
New features in 9.0-4
New features in 9.0-3
- GCC provides:
- The GNU C Library provides:
- Valgrind provides:
- Fix for 128-bit modulo and carry calculations.
- Itrace options added to dump address information for each DSO loaded into a file.
- Boost provides mem_cache_block lockfree.
- Support for lock elision on glibc.
- Script provided to help enable lock elision at runtime.
- OpenSSL provides fixes for CVE-2016-0701 and CVE-2015-3197.
- TCMalloc fixes an occasional deadlock on CEPH.
New features in 9.0-2
New features in 9.0-1
New features in 9.0-0
- 32-bit Go libraries are no longer supported.
- Lock elision support was removed due some performance issues.
- New tools available on the cross-compiler: boost, tbb, libauxv, libdfp, libhugetlbfs, libsphde, liburcu, libvecpf, openssl, paflib, tcmalloc, zlib
- MPC provides:
- Fix for mpc_pow output at low precision (see discussion).
- Debuginfo packages provided separately.
- Binutils provides:
- Split stack support included.
New features in 8.0-4


dubisthalle.de Comment Disabler
This plugin hides all comments from dubisthalle.de
Check the sourcecode
here.


How I Work: Coding
20 Jan 2014My primary development tool is none other than Sublime Text 2. It is my goto text editor for most everything. For programming, I use it exclusively. I have a PyCharm license my employer bought my team but I could never get into it. Aside from programming, I use Sublime Text for basically everything else as well, including taking notes, drafting letters, making on-the-spot todo lists, etc. I'm even writing this post in Sublime Text right now using the Markdown format.
Plugins I Use
I use several plugins for Sublime Text to work better. A few of my favorites are:
- Package Control. Of course I have this. This allows for easily adding/removing plugins to Sublime Text. It's the first thing you should add to a fresh Sublime installation.
- Backbone.js. I've installed the Backbone.js plugin which has a lot of handy completions and snippets for writing
Backbone.js
code faster. Includes both JavaScript and CoffeeScript! - CoffeeScript. I really love CoffeeScript and so adding Coffee support to Sublime Text is a must-have item. Primarily I use it for the syntax highlighting and a small portion of the completions that I actually use.
- CoffeeLint. For linting the aforementioned Coffee.
- CSScomb. This handy gadget will "comb" your CSS (and also at least LESS, but probably SASS, too) files, reordering your style properties into a consistent ordering. I like to run this occasionally to keep things neat.
- Djaneiro. This is a must-have for Django developers using Sublime. It adds a TON of completions, snippets, and syntaxes to Sublime. These make it really easy to rapidly write boilerplate Django things like model fields, form fields, and Django template tags/filters.
- DocBlockr. DocBlockr makes it really easy to write JavaDoc-style documentation as comments for various languages. I've lately been fond of the lightweight Docco for generating JavaScript documentation (my primary language these days), but on occasion at work on legacy code I'll use JSDoc format. DocBlockr is handy for that.
- Emmet. Your HTML markup writing shotgun. Lets you rapidly generate HTML markup with minimal keystrokes. If you're not using it you're not productive.
- Jasmine. I like writing tests for my JavaScript using Jasmine and this plugin just adds common completions to expedite the process of writing all the nested functions that Jasmine is known for.
- LESS. I'm not particularly against SASS, but I've just always used LESS and so that's what I prefer to write in since I'm familiar.
- SublimeLinter. Probably the most important plugin I have. This helps identify bad/questionable code throughout a whole bunch of languages. You should never professionally develop software these days without a linter.
My Sublime workspace
I'm currently using the Spacegray theme for Sublime, which I really like quite a bit. I'm going through this minimalism phase lately and it's quite pleasing to that end.
When I'm really in the zone and familiar with the codebase, I'll hide the sidebar altogether and work with just the currently open file. Using Sublime's awesome Goto Anything...
feature you can easily hop between files in the codebase if you're familiar enough. I like doing this as it's faster than searching through the sidebar manually.


Umbrella User Interfaces¶
We provide a short descritpion Umbrella user interfaces as follows:
Umbrella Command Line Interface¶
We equipped Umbrella to a command line interface that can be executed as follows:
$ java -cp target/umbrella-1.0-SNAPSHOT-jar-with-dependencies.jar cli.CliMain
We illustrate Umbrella command line interface as follows:
Umbrella command line interface provides a set of commands that can be used for retrieving topology information such as list of hosts, links, and network devices, set logger options, etc. Current version of Umbrella supports the following commands:
- Hosts
- DESCRIPTION
- Displays list of the current hosts in the network topology.
- SYNTAX
- hosts
- ARGUMENTS
- NONE
- OPTIONS
- NONE
- Links
- DESCRIPTION
- Displays list of the current links in the network topology.
- SYNTAX
- links
- ARGUMENTS
- NONE
- OPTIONS
- NONE
- Devices
- DESCRIPTION
- Displays list of the current network devices in the network topology.
- SYNTAX
- devices
- ARGUMENTS
- NONE
- OPTIONS
- NONE
- Topo
- DESCRIPTION
- Displays all topology information such as list of hosts, links, and network devices.
- SYNTAX
- topo
- ARGUMENTS
- NONE
- OPTIONS
- NONE
- Setlog
- DESCRIPTION
- Sets java log4j logger level (e.g. DEBUG, INFO, WARN, …)
- SYNTAX
- setlog
- ARGUMENTS
- NONE
- OPTIONS
- -l –level
- set log level
How to add new commands?¶
To add a new command, we need to define a java class under cli package which implements a Runnable as follows:
@CommandLine.Command(name = "commandName", header = "%n@|color Command Description|@")
class newCommand implements Runnable {
// Command Line options and arguments (For more information, please refer to http://picocli.info/)
public void run() {
// Logic behind the new command.
}
}


Requestable
public protocol Requestable
The Requestable
protocol declares an interface used for initializing network request object.
-
headerItems
Default implementationThe array of header items to apply to a
URLRequest
.Default Implementation
The default value is
nil
.Declaration
Swift
var headerItems: [HeaderItem]? { get }
-
method
Default implementationThe HTTP method to apply to a
URLRequest
.Default Implementation
The default value is
.get
.Declaration
Swift
var method: HTTPMethod { get }
-
queryItems
Default implementationThe array of query items to apply to a URL.
Default Implementation
The default valus is
nil
.Declaration
Swift
var queryItems: [QueryItem]? { get }
-
requiresAuthentication
Default implementationThe
Bool
indicating whether or not authorization header should be applied automatically by Atom to aURLRequest
instance created fromRequestable
.Default Implementation
The default valus is
false
.Declaration
Swift
var requiresAuthentication: Bool { get }
-
The base url to initialize
URLRequest
with.The URL host must begin and end with a word.
func baseURL() throws -> BaseURL { try BaseURL(host: "api.alaskaair.net") }
In the event that provided URL host fails validation, the client will be notified at the time of a network call by receiving
RequestableError.invalidBaseURL
error.Declaration
Swift
func baseURL() throws -> BaseURL
-
path()
Default implementationThe URL path to append to a base URL.
The path should begin with a forward slash
/
and end with a word.func path() throws -> URLPath { try URLPath("/path/to/resource") }
In the event when provided URL path fails validation, the client will be notified at the time of a network call by receiving
RequestableError.invalidURLPath
error.Default Implementation
The default valus is
URLPath.default
.Declaration
Swift
func path() throws -> URLPath


Your website has been successfully installed on the server! Please delete the file index2.html from the htdocs folder and then upload your website by using FTP or a File Manager.


| rversions-package {rversions} | R Documentation |
Query the main 'R' 'SVN' repository to find the versions 'r-release' and 'r-oldrel' refer to, and also all previous 'R' versions and their release dates.
The R version numbers and dates are extracted from the main R SVN repository at http://svn.r-project.org/R/.
Maintainer: Gábor Csárdi<EMAIL_ADDRESS>Other contributors:
Jeroen Ooms<EMAIL_ADDRESS>[contributor]
R Consortium [funder]
Useful links:
Report bugs at https://github.com/r-hub/rversions/issues


I purchased 200g of Blue lotus from an online vendor. I was quite excited to try this new substance. I had tried many substances that I believed would be similar to it, marijuana, salvia, wild dagga ect but all of these are quite different to lotus in actuality.
I had just finished my exams and I tried to stay clean while taking them (for obvious reasons) so on the day I finished I was determined to get really high and clear out some of the information that would not be necessary ever again.
At around 7.50 I took out some of the petals that I had grinded earlier that week, it totaled around 20-30g by my guess. This is considerably more than any report I have read before so I believed this would be good.
After 40 mins I came back to the percolator which held the 20-30gs of blue lotus and two mugs of water in it.  I added 5gs of sugar to this and it quickly became a pleasant drink, one which I could drink easily within three minutes.
Fifteen minutes past and although in the back of my mind there was the feeling that there were some effects starting it was incredibly subtle and I wasn´t sure whether the petals were even real or not.
I sat down on the sofa and watched some television. After another ten minutes I could really feel some effects, I was watching a cartoon and it seemed to be traveling at a strange speed, way too fast, pictures flashing in front of me becoming more vivid and drawing me into the set. This was a hypnotic and pleasant feeling, quite disorientating though.
I ran up to my room and grabbed a beer, I heard that drinking and lotus synergized well so I gave it a go. After the tea I found the beer easily downable, it tasted quite diluted and I finished within a minute.
I returned to the TV set and continued watching sitcoms and cartoons. A hypnotic and sedated feeling spread across my body and this lasted another 15 minutes or so. Then the synergy of the alcohol began to be noticeable, there was a lucidity and an amplification of the hypnotic feeling in my body.
The strange part of the experience was the fact that my mind was sedated yet strangely aware and capable of mental processes. My body however was still working perfectly, I could stand and walk straight though while walking any lights did seem to leave trails as I moved my head. I felt a bit off balance but not really dizzy.
I went to my room again and since I wanted to keep the feeling going I grabbed my bong, did about 8 hits getting through about four grams of lotus, I had tried smoking lotus on its own before but without drinking some lotus tea it does nothing.
After smoking the lotus the experience changed again. Now I did feel quite strong euphoric feelings and great feelings of wellbeing. I was sedated and calm, with slight euphoria. It wasn´t like MDMA euphoria, it was less naive and potent than that, it was the inner peaceful kind, a wise kind of fulfilled euphoria. Not a heavy drug that gets me stoned out of my mind inexplicably, a subtle yet complex, enlightening and fun trip.
It was a very cerebral high and any buzz in my head was definitely radiating from the top of my head. My eyelids felt heavy and I did begin to feel tired, very tired.
A great and ever changing, metamorphic high that is only held back by the fact that its effects do not last very long, by 11.00 I was baseline again.
P.S. I almost vomited when I tried to eat the pulp from the percolator after drinking the beer. It was extremely distasteful and had a nasty texture.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.