| Home | Libraries | People | FAQ | More |
Boost.Fiber provides a bounded and a unbounded channel suitable to synchonize fibers via message passing.
typedef boost::fibers::unbounded_channel< int > channel_t; void send( channel_t & channel) { for ( int i = 0; i < 5; ++i) { channel.push( i); } channel.close(); } void recv( channel_t & channel) { int i; while ( boost::fibers::channel_op_status::success == channel.pop(i) ) { std::cout << "received " << i << std::endl; } } channel_t channel; boost::fibers::fiber f1( std::bind( send, ref( channel) ) ); boost::fibers::fiber f2( std::bind( recv, ref( channel) ) ); f1.join(); f2.join();
channel_op_status
channel operations return the state of the channel.
enum class channel_op_status { success, empty, full, closed, timeout };
success
Operation was successful.
empty
channel is empty, operation failed.
full
channel is full, operation failed.
closed
channel is closed, operation failed.
timeout
The operation did not become ready before specified timeout elapsed.
unbounded_channel<>
#include <boost/fiber/unbounded_channel.hpp> namespace boost { namespace fibers { template< typename T, typenameAllocator
=std::allocator< T >
> class unbounded_channel { public: typedef T value_type; explicit unbounded_channel(Allocator
const& alloc = Allocator() ) noexcept; unbounded_channel( unbounded_channel const& other) = delete; unbounded_channel & operator=( unbounded_channel const& other) = delete; void close() noexcept; channel_op_status push( value_type const& va); channel_op_status push( value_type && va); channel_op_status pop( value_type & va); value_type value_pop(); channel_op_status try_pop( value_type & va); template< typename Rep, typename Period > channel_op_status pop_wait_for( value_type & va, std::chrono::duration< Rep, Period > const& timeout_duration); template< typename Clock, typename Duration > channel_op_status pop_wait_until( value_type & va, std::chrono::time_point< Clock, Duration > const& timeout_time); }; }}
explicit unbounded_channel( Allocator
const& alloc = Allocator() ) noexcept;
Constructs an object of class unbounded_channel
.
Internal nodes are allocated using alloc
- C++11-allocators are supported.
Nothing.
Allocator
concept, std::allocator<
T >
close
()
void close() noexcept;
Deactivates the channel. No values can be put after calling this->close()
.
Fibers blocked in this->pop()
, this->pop_wait_for()
or this->pop_wait_until()
will return closed
.
Fibers blocked in this->value_pop()
will receive an exception.
Nothing.
close()
is like closing a pipe. It informs waiting consumers that no more values
will arrive.
push
()
channel_op_status push( value_type const& va); channel_op_status push( value_type && va);
If channel is closed, returns closed
.
Otherwise enqueues the value in the channel, wakes up a fiber blocked
on this->pop()
,
this->value_pop()
,
this->pop_wait_for()
or this->pop_wait_until()
and returns success
.
Exceptions thrown by memory allocation and copying or moving va
.
pop
()
channel_op_status pop( value_type & va);
Dequeues a value from the channel. If the channel is empty, the fiber
gets suspended until at least one new item is push()
ed (return value success
and va
contains dequeued
value) or the channel gets close()
d (return value closed
).
Nothing
value_pop
()
value_type value_pop();
Dequeues a value from the channel. If the channel is empty, the fiber
gets suspended until at least one new item is push()
ed or the channel gets close()
d
(which throws an exception).
fiber_error
if *this
is closed
std::errc::operation_not_permitted
try_pop
()
channel_op_status try_pop( value_type & va);
If channel is empty, returns empty
.
If channel is closed, returns closed
.
Otherwise it returns success
and va
contains the
dequeued value.
Exceptions thrown by copy- or move-operations.
pop_wait_for
()
template< typename Rep, typename Period > channel_op_status pop_wait_for( value_type & va, std::chrono::duration< Rep, Period > const& timeout_duration)
Accepts std::chrono::duration
and internally computes
a timeout time as (system time + timeout_duration
).
If channel is not empty, immediately dequeues a value from the channel.
Otherwise the fiber gets suspended until at least one new item is
push()
ed
(return value success
and va
contains dequeued
value), or the channel gets close()
d (return value closed
),
or the system time reaches the computed timeout time (return value
timeout
).
timeout-related exceptions.
pop_wait_until
()
template< typename Clock, typename Duration > channel_op_status pop_wait_until( value_type & va, std::chrono::time_point< Clock, Duration > const& timeout_time)
Accepts a std::chrono::time_point<
Clock,
Duration >
.
If channel is not empty, immediately dequeues a value from the channel.
Otherwise the fiber gets suspended until at least one new item is
push()
ed
(return value success
and va
contains dequeued
value), or the channel gets close()
d (return value closed
),
or the system time reaches the passed time_point
(return value timeout
).
timeout-related exceptions.
bounded_channel<>
#include <boost/fiber/bounded_channel.hpp> namespace boost { namespace fibers { template< typename T, typenameAllocator
=std::allocator< T >
> class bounded_channel { public: typedef T value_type; bounded_channel( std::size_t wm,Allocator
const& alloc = Allocator() ); bounded_channel( std::size_t hwm, std::size_t lwm,Allocator
const& alloc = Allocator() ); bounded_channel( bounded_channel const& other) = delete; bounded_channel & operator=( bounded_channel const& other) = delete; std::size_t upper_bound() const noexcept; std::size_t lower_bound() const noexcept; void close() noexcept; channel_op_status push( value_type const& va); channel_op_status push( value_type && va); template< typename Rep, typename Period > channel_op_status push_wait_for( value_type const& va, std::chrono::duration< Rep, Period > const& timeout_duration); channel_op_status push_wait_for( value_type && va, std::chrono::duration< Rep, Period > const& timeout_duration); template< typename Clock, typename Duration > channel_op_status push_wait_until( value_type const& va, std::chrono::time_point< Clock, Duration > const& timeout_time); template< typename Clock, typename Duration > channel_op_status push_wait_until( value_type && va, std::chrono::time_point< Clock, Duration > const& timeout_time); channel_op_status try_push( value_type const& va); channel_op_status try_push( value_type && va); channel_op_status pop( value_type & va); value_type value_pop(); template< typename Rep, typename Period > channel_op_status pop_wait_for( value_type & va, std::chrono::duration< Rep, Period > const& timeout_duration); template< typename Clock, typename Duration > channel_op_status pop_wait_until( value_type & va, std::chrono::time_point< Clock, Duration > const& timeout_time); channel_op_status try_pop( value_type & va); }; }}
bounded_channel( std::size_t wm,Allocator
const& alloc = Allocator() ); bounded_channel( std::size_t hwm, std::size_t lwm,Allocator
const& alloc = Allocator() );
hwm >
lwm
Constructs an object of class bounded_channel
.
The constructor with two arguments constructs an object of class bounded_channel
with a high-watermark
of hwm
and a low-watermark
of lwm
items. The constructor
with one std::size_t
argument is effectively the
same as bounded_channel(wm, (wm-1), alloc)
.
Internal nodes are allocated using alloc
- C++11-allocators are supported.
fiber_error
invalid_argument: if lwm >=
hwm
.
Once the number of values in the channel reaches hwm
,
any call to push()
,
push_wait_for()
or push_wait_until()
will block until the number of values
in the channel is at most lwm
.
That is, if lwm <
(hwm-1)
,
the channel can be in a state in which push()
, push_wait_for()
or push_wait_until()
calls will block (channel is full)
even though the number of values in the channel is less than hwm
.
Allocator
concept, std::allocator<
T >
upper_bound
()
std::size_t upper_bound() const noexcept;
the high-watermark with which *this
was constructed.
Nothing.
lower_bound
()
std::size_t lower_bound() const noexcept;
the low-watermark with which *this
was constructed.
Nothing.
close
()
void close() noexcept;
Deactivates the channel. No values can be put after calling this->close()
.
Fibers blocked in this->pop()
, this->pop_wait_for()
or this->pop_wait_until()
will return closed
.
Fibers blocked in this->value_pop()
will receive an exception.
Nothing.
close()
is like closing a pipe. It informs waiting consumers that no more values
will arrive.
push
()
channel_op_status push( value_type const& va); channel_op_status push( value_type && va);
If channel is closed, returns closed
.
If channel is not full, enqueues the value in the channel, wakes up
a fiber blocked on this->pop()
, this->value_pop()
, this->pop_wait_for()
or this->pop_wait_until()
and returns success
.
Otherwise the calling fiber is suspended until the number of values
in the channel drops to lwm
(return value success
)or
the channel is close()
d (return value closed
).
exceptions thrown by memory allocation and copying or moving va
.
push_wait_for
()
template< typename Rep, typename Period > channel_op_status push_wait_for( value_type const& va, std::chrono::duration< Rep, Period > const& timeout_duration); template< typename Rep, typename Period > channel_op_status push_wait_for( value_type && va, std::chrono::duration< Rep, Period > const& timeout_duration);
Accepts std::chrono::duration
and internally computes
a time_point as (system time + timeout_duration
).
If channel is closed, returns closed
.
If channel is not full, enqueues the value in the channel, wakes up
a fiber blocked on this->pop()
, this->value_pop()
, this->pop_wait_for()
or this->pop_wait_until()
and returns success
.
Otherwise the calling fiber is suspended until the number of values
in the channel drops to lwm
(return value success
),
the channel is close()
d (return value closed
),
or the system time reaches the computed time_point (return value timeout
).
exceptions thrown by memory allocation and copying or moving va
or timeout-related exceptions.
push_wait_until
()
template< typename Clock, typename Duration > channel_op_status push_wait_until( value_type const& va, std::chrono::time_point< Clock, Duration > const& timeout_time); template< typename Clock, typename Duration > channel_op_status push_wait_until( value_type && va, std::chrono::time_point< Clock, Duration > const& timeout_time);
Accepts an absolute timeout_time
in any supported time_point type. If channel is closed, returns closed
. If channel is not full, enqueues
the value in the channel, wakes up a fiber blocked on this->pop()
,
this->value_pop()
,
this->pop_wait_for()
or this->pop_wait_until()
and returns success
.
Otherwise the calling fiber is suspended until the number of values
in the channel drops to lwm
(return value success
),
the channel is close()
d (return value closed
),
or the system time reaches the passed time_point (return value timeout
).
exceptions thrown by memory allocation and copying or moving va
or timeout-related exceptions.
try_push
()
channel_op_status try_push( value_type const& va); channel_op_status try_push( value_type && va);
If channel is full, returns full
.
If channel is closed, returns closed
.
Otherwise enqueues the value in the channel, wakes up a fiber blocked
on this->pop()
,
this->value_pop()
,
this->pop_wait_for()
or this->pop_wait_until()
and returns success
.
Exceptions thrown by memory allocation and copying or moving va
.
pop
()
channel_op_status pop( value_type & va);
Dequeues a value from the channel. If the channel is empty, the fiber
gets suspended until at least one new item is push()
ed (return value success
and va
contains dequeued
value) or the channel gets close()
d (return value closed
).
Once the number of items remaining in the channel drops to lwm
, any fibers blocked on push()
,
push_wait_for()
or push_wait_until()
may resume.
Nothing
value_pop
()
value_type value_pop();
Dequeues a value from the channel. If the channel is empty, the fiber
gets suspended until at least one new item is push()
ed or the channel gets close()
d
(which throws an exception). Once the number of items remaining in
the channel drops to lwm
,
any fibers blocked on push()
, push_wait_for()
or push_wait_until()
may resume.
fiber_error
if *this
is closed
std::errc::operation_not_permitted
try_pop
()
channel_op_status try_pop( value_type & va);
If channel is empty, returns empty
.
If channel is closed, returns closed
.
Otherwise it returns success
and va
contains the
dequeued value. Once the number of items remaining in the channel drops
to lwm
, any fibers
blocked on push()
,
push_wait_for()
or push_wait_until()
may resume.
Exceptions thrown by copy- or move-operations.
pop_wait_for
()
template< typename Rep, typename Period > channel_op_status pop_wait_for( value_type & va, std::chrono::duration< Rep, Period > const& timeout_duration)
Accepts std::chrono::duration
and internally computes
a timeout time as (system time + timeout_duration
).
If channel is not empty, immediately dequeues a value from the channel.
Otherwise the fiber gets suspended until at least one new item is
push()
ed
(return value success
and va
contains dequeued
value), or the channel gets close()
d (return value closed
),
or the system time reaches the computed timeout time (return value
timeout
). Once the
number of items remaining in the channel drops to lwm
,
any fibers blocked on push()
, push_wait_for()
or push_wait_until()
may resume.
timeout-related exceptions.
pop_wait_until
()
template< typename Clock, typename Duration > channel_op_status pop_wait_until( value_type & va, std::chrono::time_point< Clock, Duration > const& timeout_time)
Accepts a std::chrono::time_point<
Clock,
Duration >
.
If channel is not empty, immediately dequeues a value from the channel.
Otherwise the fiber gets suspended until at least one new item is
push()
ed
(return value success
and va
contains dequeued
value), or the channel gets close()
d (return value closed
),
or the system time reaches the passed time_point
(return value timeout
).
Once the number of items remaining in the channel drops to lwm
, any fibers blocked on push()
,
push_wait_for()
or push_wait_until()
may resume.
timeout-related exceptions.


next
prev
1
nike lunarepic fk
running
2
nike lunarepic low fk
running
3
nike lunarglide 8
running
4
nike air max 2017
running
5
nike free rn fk
running
6
nike shox r4
running
7
nike air max 90
nsw
8
nike air presto
nsw
9
nike free tr fk
training
10
air jordan trainer 1 low
jordan


Algorithmaths
Logout
Register
Home
Notation
Recurrence relation
Mathematical Induction
Test Yourself
Review
×
Close
Register
Firstname:
Lastname:
Username:
Password:
Welcome to Algorithmaths
//Welcome text
Enter values into the quadratic recurrence relation below. Attempt working out the sequence by yourself first before continuing as you will be asked to enter the sequence once you submit.
U(n) =
U(n) +
n +
U(1) =
Submit
Find Difference
Test yourself
Start the test
Test has started


Bootstrap Basics
Click Me
Click Me
Click Me
Search something in google
Jumbotron!
Hello this is a jumbotron
Hey There!


{% extends 'base.html' %} {% block title %}Thank you!{% endblock %} {% block content %}
Now we can keep the servers running with all the traffic. And, more exciting for you, we can make Clicking Bad more fun.
Because you rock so much you can now get a secret upgrade in your game
THANK YOU!
" exactly as it appears without the quotes


How to use this bad boy: Arrow keys can be used for moving around the image. [ and ] keys are used for zooming in and out, respectively. Load an image in the load section and press load. Write a label in the label section and draw a bunch of squares around things that are that label. When you're finished press submit and then load in another image or start selecting things with different labels.


WARNING
Content Under Development
See release page for latest official PDF version.
**Chapter 9: Dielectrics**
Clear materials such as water, glass, and diamonds are dielectrics. When a light ray hits them, it
splits into a reflected ray and a refracted (transmitted) ray. We’ll handle that by randomly
choosing between reflection or refraction and only generating one scattered ray per interaction.
The hardest part to debug is the refracted ray. I usually first just have all the light refract if
there is a refraction ray at all. For this project, I tried to put two glass balls in our scene, and
I got this (I have not told you how to do this right or wrong yet, but soon!):
![Image 9-1](../assets/img09-1.jpg)
Is that right?  But no, it isn’t right. The world should be
flipped upside down and no weird black stuff. I just printed out the ray straight through the middle
of the image and it was clearly wrong. That often does the job.
The refraction is described by Snell’s law:
$$ n \cdot sin(theta) = n' \cdot sin(theta') $$
Where $n$ and $n'$ are the refractive indices (typically air = 1, glass = 1.3–1.7, diamond = 2.4)
and the geometry is:
![Figure 9-1](../assets/fig09-1.jpg)
One troublesome practical issue is that when the ray is in the material with the higher refractive
index, there is no real solution to Snell’s law and thus there is no refraction possible. Here all
the light is reflected, and because in practice that is usually inside solid objects, it is called
“total internal reflection”. This is why sometimes the water-air boundary acts as a perfect mirror
when you are submerged. The code for refraction is thus a bit more complicated than for reflection:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
bool refract(const vec3& v, const vec3& n, float ni_over_nt, vec3& refracted) {
vec3 uv = unit_vector(v);
float dt = dot(uv, n);
float discriminant = 1.0 - ni_over_nt*ni_over_nt*(1-dt*dt);
if (discriminant > 0) {
refracted = ni_over_nt*(uv - n*dt) - n*sqrt(discriminant);
return true;
}
else
return false;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
And the dielectric material that always refracts when possible is:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
class dielectric : public material {
public:
dielectric(float ri) : ref_idx(ri) {}
virtual bool scatter(const ray& r_in, const hit_record& rec,
vec3& attenuation, ray& scattered) const
{
vec3 outward_normal;
vec3 reflected = reflect(r_in.direction(), rec.normal);
float ni_over_nt;
attenuation = vec3(1.0, 1.0, 0.0);
vec3 refracted;
if (dot(r_in.direction(), rec.normal) > 0) {
outward_normal = -rec.normal;
ni_over_nt = ref_idx;
}
else {
outward_normal = rec.normal;
ni_over_nt = 1.0 / ref_idx;
}
if (refract(r_in.direction(), outward_normal, ni_over_nt, refracted))
scattered = ray(rec.p, refracted);
else {
scattered = ray(rec.p, reflected);
return false;
}
return true;
}
float ref_idx;
};
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Attenuation is always 1 -- the glass surface absorbs nothing. The `attenuation = vec3(1.0, 1.0,
0.0)` above will also kill the blue channel which is the type of color bug that can be hard to find
-- it will give a color shift only. Try it the way it is and then change it to
`attenuation = vec3(1.0, 1.0, 1.0)` to see the difference.
If we try that out with these parameters:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
list[0] = new sphere(vec3(0,0,-1), 0.5, new lambertian(vec3(0.1, 0.2, 0.5)));
list[1] = new sphere(vec3(0,-100.5,-1), 100, new lambertian(vec3(0.8, 0.8, 0.0)));
list[2] = new sphere(vec3(1,0,-1), 0.5, new metal(vec3(0.8, 0.6, 0.2), 0.0));
list[3] = new sphere(vec3(-1,0,-1), 0.5, new dielectric(1.5));
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We get:
![Image 9-2](../assets/img09-2.jpg)
(The reader Becker has pointed out that when there is a reflection ray the function returns `false`
so there are no reflections. He is right, and that is why there are none in the image above. I
am leaving this in rather than correcting this because it is a very interesting example of a major
bug that still leaves a reasonably plausible image. These sleeper bugs are the hardest bugs to
find because we humans are not designed to find fault with what we see.)
Now real glass has reflectivity that varies with angle -- look at a window at a steep angle and it
becomes a mirror. There is a big ugly equation for that, but almost everybody uses a simple and
surprisingly simple polynomial approximation by Christophe Schlick:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
float schlick(float cosine, float ref_idx) {
float r0 = (1-ref_idx) / (1+ref_idx);
r0 = r0*r0;
return r0 + (1-r0)*pow((1 - cosine),5);
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This yields our full glass material:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
class dielectric : public material {
public:
dielectric(float ri) : ref_idx(ri) {}
virtual bool scatter(
const ray& r_in, const hit_record& rec, vec3& attenuation,
ray& scattered) const
{
vec3 outward_normal;
vec3 reflected = reflect(r_in.direction(), rec.normal);
float ni_over_nt;
attenuation = vec3(1.0, 1.0, 1.0);
vec3 refracted;
float reflect_prob;
float cosine;
if (dot(r_in.direction(), rec.normal) > 0) {
outward_normal = -rec.normal;
ni_over_nt = ref_idx;
cosine = ref_idx * dot(r_in.direction(), rec.normal)
/ r_in.direction().length();
}
else {
outward_normal = rec.normal;
ni_over_nt = 1.0 / ref_idx;
cosine = -dot(r_in.direction(), rec.normal)
/ r_in.direction().length();
}
if (refract(r_in.direction(), outward_normal, ni_over_nt, refracted)) {
reflect_prob = schlick(cosine, ref_idx);
}
else {
reflect_prob = 1.0;
}
if (random_double() < reflect_prob) {
scattered = ray(rec.p, reflected);
}
else {
scattered = ray(rec.p, refracted);
}
return true;
}
float ref_idx;
};
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An interesting and easy trick with dielectric spheres is to note that if you use a negative radius,
the geometry is unaffected but the surface normal points inward, so it can be used as a bubble
to make a hollow glass sphere:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
list[0] = new sphere(vec3(0,0,-1), 0.5, new lambertian(vec3(0.1, 0.2, 0.5)));
list[1] = new sphere(vec3(0,-100.5,-1), 100, new lambertian(vec3(0.8, 0.8, 0.0)));
list[2] = new sphere(vec3(1,0,-1), 0.5, new metal(vec3(0.8, 0.6, 0.2)));
list[3] = new sphere(vec3(-1,0,-1), 0.5, new dielectric(1.5));
list[4] = new sphere(vec3(-1,0,-1), -0.45, new dielectric(1.5));
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This gives:
![Image 9-3](../assets/img09-3.jpg)


JSFrame.js examples
Create a window inside a window
If you want to nest frames like window-in-window, call setFrameInFrame(true) on the parent frame
View source on GitHub


Introduction
By now, if you’re a science geek like me, you’ve probably heard the news that Venus shows possible signs of life . Yes, hellish Venus, of all places, might harbor life. This is due to the detection of significant amounts of PH3 (phosphine) in the atmosphere. While the original paper downplayed the possibility that possibility that this phosphine was generated by life, nonetheless, it’s worth understanding the excitement and what it could mean.
Astrobiology
For many, Venus doesn’t seem like a likely candidate for life to exist. The surface temperature is 450° Celsius (842°Fahrenheit—hotter than Mercury!). The atmospheric pressure at the surface is 90 to 95 times greater than on Earth. What’s more, on the surface the atmosphere is overwhelmingly carbon dioxide and nitrogen. But you wouldn’t suffocate. You’d burn and be crushed to death first.
Despite that, the upper atmosphere of Venus is the most Earthlike in the solar system, with even NASA discussing ideas for exploration or colonization .
So what was so interesting about the recent research paper?
In biology, there’s a subfield called astrobiology. I like to think of astrobiologists as science fiction writers with advanced degrees in biology. They consider the possibility of life elsewhere in the universe, what it might be like, and how we can detect it. One of the things they frequently discuss is biosignatures . These are chemical signatures which, if they exist, suggest some form of unusual chemical process that might indicate life. For example, large amounts of free O2 (oxygen) in the atmosphere would be a huge biosignature, as oxygen reacts with just about everything and is quickly removed from the atmosphere. While there are physical processes which can cause oxygen to remain free in the atmosphere, we have so much free oxygen in our atmosphere because life produces it. The detection of large amounts of it in an alient atmosphere would certainly be a great indicator that further investigation is warranted.
Methane is another biosignature gas because its existence is usually associated with life. We’ve been discovering lots of methane on Mars and we don’t know why. Given that the 1976 Viking landers possibly detected metabolism on Mars , the strange discovery of methane on Mars merits closer investigation. We don’t know what’s going on with Mars and life, despite it being very unlikely, could easily explain what we’re observing.
However, it cannot be stressed enough:
If the question is “aliens?”, the answer is almost certainly “no.”
Seriously, stop thinking it’s extraterrestrial life. Every time we’ve gotten our hopes up, they’ve been dashed. And that’s a good thing: it means science is working; we’re not searching for fun, we’re searching for truth.
Phosphine on Venus
The paper is fairly easy to follow, even if it’s aimed at a technical audience.
The authors of the paper were aware that phosphine is known as a powerful biosignature . While phosphine can be produced in energetic reducing atmospheres such as Jupiter and Saturn (and has been detected there), rocky planets such as Earth and Venus shouldn’t have significant phosphine in their atmosphere, though Earth does due to phosphine production by extremophiles. However, we can potentially detect phosphine on exoplanets, so the researchers decided to use Venus to create a benchmark for further studies, but they found ”unexpectedly, our initial observations suggested a detectable amount of Venusian PH3 was present.”
This was a surprise. So the paper focuses on two areas. First, they considered all the possible ways that whatever they detected was not phosphine. After eliminating all sources of confusion they could think of, they concluded that, yup, it was probably phosphine.
The next part of their paper asks the big question: what could cause this?
They considered many, many different ways in which PH3 could be created, but there simply isn’t enough free energy on Venus for that to happen in any significant quantities. For what little PH3 could exist, they considered the lifetime of the molecule and outgassing, again finding an unsustainable amount of PH3. So where does it come from?
Here’s an important section of their research.
Even if confirmed, we emphasize that the detection of PH3 is not robust evidence for life, only for anomalous and unexplained chemistry. There are substantial conceptual problems for the idea of life in Venus’s clouds—the environment is extremely dehydrating as well as hyperacidic. However, we have ruled out many chemical routes to PH3, with the most likely ones falling short by four to eight orders of magnitude To further discriminate between unknown photochemical and/or geological processes as the source of Venusian PH3, or to determine whether there is life in the clouds of Venus, substantial modelling and experimentation will be important. Ultimately, a solution could come from revisiting Venus for in situ measurements or aerosol return.
In other words:
- The PH3 (phosphine) is not strong evidence of life
- There could be previously unknown chemical processes producing it
- It would be difficult for life as we know it to survive in Venus’ upper atmosphere
- We know of no natural (non-living) processes which can produce this phosphine on Venus
There’s actually been plenty of prior discussion about the possibility of life in Venus’ clouds, with Carl Sagan writing about this in the 1960s. Serious research articles on the topic appear regularly and pop-sci articles love to describe scientists pointing out that dark patches in Venusian clouds could be micro-organisms .
Implications
While it’s very unlikely, what does it mean if life is found on Venus? That would depend on its origin. If we found that Venusian life had the same DNA or RNA as Earth life, that would strongly suggest a common origin. The panspermia hypothesis, long laughed at in science, is looking more and more credible all the time, particularly since we find Martian meteorites on Earth. Wouldn’t it be fascinating if life originated on Mars and made its way to both Earth and Venus?
While I love that thought, there’s the more exciting possibility that potential Venusian life shares little, if any, biological similarity to Earth life. If so, that would suggest a separate origin. The implications of that would be staggering.
Currently, we only know of one place in the entire universe where life was created: Earth. If we had two independent creation events in the same solar sytem, this would imply that it’s common enough that the universe should be teeming with life. Absolutely teeming. As our technology improves, it would be easier to detect those biosignatures on the thousands of alien planets we’ve discovered. It would be amazing.
As for intelligent life elsewhere, that’s a different story, but if the universe is teeming with life, that tremendously raises the chance for intelligent life elsewhere.
I can imagine few scientifics endeavors more important than sending new missions to Venus and Mars to investigate one of the most fundamental questions humanity faces: are we alone?
Update: new research indicates that the alleged phosphine detected in Venus’s atmospher is probably sulfur dioxide. Here’s the paper and here’s a news article about it .


13
1 So Abram left Egypt and went into the Negev, he, his wife, and all that he had. Lot also went with them.
2 Now Abram was very rich in animals, in silver, and in gold.
3 He continued on his journey from the Negev to Bethel, to the place where his tent had been before, between Bethel and Ai.
4 This is the place where the altar was that he had built previously, and here he called on the name of Yahweh.
5 Now Lot, who was traveling with Abram, also had flocks, herds, and tents.
6 The land was not able to support them both living close together, because their possessions were very many, so that they could not stay together.
7 Also, there was a dispute between the herdsmen of Abram's animals and the herdsmen of Lot's animals. The Canaanites and the Perizzites were living in the land at that time.
8 So Abram said to Lot, "Let there be no strife between you and me, and between your herdsmen and my herdsmen; after all, we are family.
9 Is not the whole land before you? Go ahead and separate yourself from me. If you go to the left, then I will go to the right. Or if you go to the right, then I will go to the left."
10 So Lot looked around, and saw that the whole plain of the Jordan was well watered everywhere all the way to Zoar, like the garden of Yahweh, like the land of Egypt. This was before Yahweh destroyed Sodom and Gomorrah.
11 So Lot chose for himself all the plain of the Jordan and traveled east, and the relatives separated from each other.
12 Abram lived in the land of Canaan, and Lot lived among the cities of the plain. He set up his tents as far away as Sodom.
13 Now the men of Sodom were very wicked sinners against Yahweh.
14 Yahweh said to Abram after Lot had departed from him, "Look from the place where you are standing to the north, south, east, and west.
15 All this land which you see, I will give to you and to your descendants forever.
16 And I will make your descendants as abundant as the dust of the earth, so that if a man could count the dust of the earth, then your descendants could also be counted.
17 Arise, walk through the length and breadth of the land, for I will give it to you."
18 So Abram picked up his tent, and came and lived by the oaks of Mamre, which are in Hebron, and there built an altar to Yahweh.


zac
ioannidis
Hey, I'm Zac, currently 20, located in the UK. I've always been interested in things that blended technical and creative aspects. For this reason, things that excite me and that I enjoy working on include big data, creative coding, and data visualization. I'm an avid movie and photography fan. I listen to, play and write about music. In my spare time I study Computer Science at the University of Bristol.


Information Adversity
Enter data from the experiment down there.
For more info on the format requirements and output spec, see the
README
.
Product Data:
Choice Data:
Interface Data:
Get Information Adversity


Land Registry
Search Land Using ID
ID of Land:
Land Information
Search Owner Using ID
ID of Owner:
Owner Information


A responsive scaffold project.
This scaffold uses the WURFL.js device detection script to only load certain elements and dependencies though yepnope.js as they are required.
For example, a social media widget is only loaded on larger screens. To cut down on loading additional elements that might normally be hidden, the social media widget is not loaded onto mobile devices.
This project is experimental and can be used as an alternative to static conditional include methods. However, use with caution and test properly for performance. Older methods of selective loading may be better for some projects.
This scaffold is built with the Yeoman Web App scaffold and includes the following:
If you have some feedback, please send me an email.


Some helpful links!
I was born in Decorah, Iowa and I lived their for 17 years before moving to Fort Myers, Florida. I currently attend the Unverisity of Central Florida in pursuit of a degree in Computer Science. I have 3 simblings, 2 brothers and 1 sister. My brother Jacob, who is just under 2 years younger than me, and I spent much of our childhood playing baseball, Nintendo games, Yu-Gi-OH cards, and much more. I have been dating the same girl, Skylar, for over 2 years. We met in high school and both attend UCF.
I have been doing crossfit everyday for almost 2 years. It is very hard, but I love the feeling of a great workout. Baseball is still my favorite sport though and my dad and I do a fantasy baseball draft together every year. It is by far the most fun and exciting day of the year. Another hobby that has been keeping me busy in my spare time is collecting for Nintendo. I have been playing Nintendo since I was little, but did't start collecting until about the summer of 2013. Recently, I decided to start collecting for Playstion 1 and 2 games as well. Currently, I have approx. 400 games. My favorite games are the two Zelda games for the Nintendo 64: Ocarina of Time and Majora's Mask.


http://www.susangranger.com/
Susan Granger's review of "THE SANDY BOTTOM ORCHESTRA" (SHOWTIME TV)
On Sunday night, August 27, at 8 PM, Showtime TV premieres this sugar-coated drama about an eccentric family struggling to belong in a small town in Northern Wisconsin. Based on the novel, "The Sandy Bottom Orchestra," by husband-and-wife Garrison Keillor and Jenny Lind Nilsson, it's constructed as a reminiscence, narrated by 14 year-old Rachel (Madeline Zima), a talented violinist, who lives in Sandy Bottom and studies at Amidore's Music School. Her mother Ingrid (Glenne Headley) gave up a promising career as a classical pianist to marry Norman (Tom Irwin), a local dairy farmer who dreams of conducting an orchestra. Determined to bring culture to their provincial, little town, Ingrid tackles community "causes," like introducing sophisticated hymns to the recalcitrant members of the Zion Methodist Church choir, along with its troubled minister (Richard McMillan), and fighting to preserve a magnificent historical building which the Mayor wants to demolish to make way for a pizza parlor. Her closest friend is an 80 year-old widow (Jane Powell), who not only understands Ingrid's frustration but seems to be her only ally. Two pivotal crises occur when Norman, playing the impresario, decides to forgo the traditional marching and oom-pah bands to present a classical concert at the annual Dairy Days celebration and when Rachel's parents decide she should apply to Interlochen Music School in Michigan - but neither is explored in enough depth to be emotionally effective. Under the direction of Bradley Wigor, the actors rise above the bland superficiality of Joseph Maurer's script and the cinematography is beautiful. On the Granger Made-for-Television Movie Gauge, "The Sandy Bottom Orchestra" is a slow-paced, syrupy, sentimental 6, as it answers Ingrid's question: "I wonder what it would be like to feel you were part of something important." Additional playdates are Aug.30 at 9:35 AM, Sept. 2 at 8:15 AM, Sept. 22 at 11:15 AM, and Sept. 25 at 6:15 PM.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


| Home | Libraries | People | FAQ | More |
Because some file system operations are synchronous on most platforms (creating
files, calling fsync()
etc.) Boost.AFIO internally needed an asynchronous, chainable, batch executable,
closure execution engine which it also makes available for public usage.
While this is a somewhat intimidating characterization, the core concept
of such an engine is fairly straight forward. The following sections will
attempt to clear up exactly what this title means, and to give the user a
reference for how it can be used when compared to some better known implementations.
If you are already familiar with what an asynchronous, chainable, batch executable,
closure execution engine is you may wish to skip this section.


--- layout: base title: Specification ---
This page is the authority on what Jsonnet programs should do. It defines Jsonnet lexing and syntax. It describes which programs should be rejected statically (i.e. before execution). Finally, it specifies the manner in which the program is executed, i.e. the JSON that is output, or the runtime error if there is one.
The specification is intended to be terse, precise, and illuminate all the subtleties and edge cases in order to allow fully-compatible language reimplementations and tools. The specification employs some standard theoretical computer science techniques, namely type systems and big step operational semantics. If you just want to write Jsonnet code (not build a Jsonnet interpreter or tool), you don't need to read this. You should read the tutorial and reference .
A Jsonnet program is UTF-8 encoded text. The file is a sequence of tokens, separated by
optional whitespace and comments. Whitespace consists of space, tab, newline and carriage
return. Tokens are lexed greedily. Comments are either single line comments, beginning
with a #
or a //
, or block comments beginning with /*
and terminating at the first */
encountered within the comment.
id: Matched by [_a-zA-Z][_a-zA-Z0-9]*.
Some identifiers are reserved as keywords, thus are not in the set id:
assert
else
error
false
for
function
if
import
importstr
importbin
in
local
null
tailstrict
then
self
super
true
.
number: As defined by JSON but without the leading minus.
string: Which can have five quoting forms:
"
and ending with the first subsequent
non-quoted "
'
and ending with the first subsequent
non-quoted '
@"
and ending with the first
subsequent non-quoted "
@'
and ending with the first
subsequent non-quoted '
|||
, followed by optional whitespace and a
new-line. The next non-empty line must be prefixed with some non-zero length
whitespace W. The block ends at the first subsequent line that is non-empty
and does not begin with W, and it is an error if this line does not contain
some optional whitespace followed by |||
. The content of the string is
the concatenation of all the lines between the two |||
, which either
begin with W (in which case that prefix is stripped) or they are empty lines
(in which case they remain as empty lines). The line ending style in the file is
preserved in the string. This form cannot be used in import
statements.
Double- and single-quoted strings are allowed to span multiple lines, in which case
whatever dos/unix end-of-line character your editor inserts will be put in the string.
They both understand the following escape characters: "'\/bfnrt
which have
their standard meanings, as well as \uXXXX
for hexadecimal unicode escapes.
Verbatim strings eschew all of the normal string escaping, including hexadecimal unicode
escapes. Every character in a verbatim string is processed literally, with the
exception of doubled end-quotes. Within a verbatim single-quoted string,
''
is processed as '
, and a verbatim double-quoted string,
""
is processed as "
.
In the rest of this specification, the string is assumed to be canonicalized into a sequence of unicode codepoints with no record of the original quoting form as well and any escape characters removed.
symbol: The following single-character symbols:
{}[],.();
operator: A sequence of at least one of the following single-character symbols:
!$:~+-&|^=<>*/%
.
Additionally it is subject to the following rules, which may cause the lexing to terminate with a shorter token:
//
is not allowed in an operator.
/*
is not allowed in an operator.
|||
is not allowed in an operator.
+
, -
, ~
, !
, $
.
The notation used here is as follows: { } denotes zero or more repetitions of a sequence of
tokens, and [ ] represents an optional sequence of tokens. This is not to be confused with
{ }
and [ ]
which represent tokens in Jsonnet itself.
Note that although the lexer will generate tokens for a wide range of operators, only a finite set are currently parseable, the rest being reserved for possible future use.
| expr ∈ Expr | ::= |
null |
true |
false |
self |
$ |
string |
number
|
| | |
{
objinside
}
|
|
| | |
[
[ expr { , expr } [ , ] ]
]
|
|
| | |
[
expr
[ , ]
forspec compspec
]
|
|
| | |
expr
.
id
|
|
| | |
expr
[
[ expr ]
[ : [ expr ]
[ : [ expr ] ] ]
]
|
|
| | |
super
.
id
|
|
| | |
super
[
expr
]
|
|
| | |
expr
(
[ args ]
)
|
|
| | | id | |
| | |
local
bind
{
,
bind
}
;
expr
|
|
| | |
if
expr
then
expr
[ else
expr ]
|
|
| | | expr binaryop expr | |
| | | unaryop expr | |
| | |
expr
{
objinside
}
|
|
| | |
function
(
[ params ]
)
expr
|
|
| | |
assert
;
expr
|
|
| | |
import
string
|
|
| | |
importstr
string
|
|
| | |
importbin
string
|
|
| | |
error
expr
|
|
| | |
expr in super
|
| objinside | ::= |
member { , member } [ , ]
|
| | |
{ objlocal , }
[
expr
]
:
expr
[ { , objlocal } ] [ , ]
forspec compspec
|
|
| member | ::= | objlocal | assert | field |
| field ∈ Field | ::= |
fieldname
[ + ] h
expr
|
| | |
fieldname
(
[ params ]
)
h
expr
|
|
| h ∈ Hidden | ::= |
: | :: | :::
|
| objlocal | ::= |
local bind
|
| compspec ∈ CompSpec | ::= | { forspec | ifspec } |
| forspec | ::= |
for
id
in
expr
|
| ifspec | ::= |
if
expr
|
| fieldname | ::= |
id |
string |
[
expr
]
|
| assert | ::= |
assert expr [ : expr ]
|
| bind ∈ Bind | ::= |
id
=
expr
|
| | |
id
(
[ params ]
)
=
expr
|
| args | ::= |
expr { , expr } { , id =
expr } [ , ]
|
| | |
id = expr { , id =
expr } [ , ]
|
| params | ::= |
param { , param } [ , ]
|
| param | ::= |
id [ = expr ]
|
| binaryop | ::= |
* |
/ |
% |
+ |
- |
<< |
>> |
< |
<= |
> |
>= |
== |
!= |
in |
& |
^ |
| |
&& |
||
|
| unaryop | ::= | - | + | ! | ~ |
The abstract syntax by itself cannot unambiguously parse a sequence of tokens. Ambiguities
are resolved according to the following rules, which can also be overridden by adding
parenthesis symbols ()
.
Everything is left associative. In the case of assert
, error
,
function
, if
, import
, importstr
, importbin
, and
local
, ambiguity is resolved by consuming as many tokens as possible on the
right hand side. For example the parentheses are redundant in local x = 1; (x +
x)
. All remaining ambiguities are resolved according to the following decreasing
order of precedence:
e(...)
e[...]
e.f
(application and indexing)+
-
!
~
(the unary operators)*
/
%
(these, and the remainder below, are binary operators)+
-
<<
>>
<
>
<=
>=
in
==
!=
&
^
|
&&
||
To make the specification of Jsonnet as simple as possible, many of the language features are represented as syntax sugar. Below is defined the core syntax and the desugaring function from the abstract syntax to the core syntax. Both the static checking rules and the operational semantics are defined at the level of the core language, so it is possible to desugar immediately after parsing.
The core language has the following simplifications:
$
, which is no-longer a special keyword.
!=
==
%
in
[::]
are removed.+:
, +::
, and +:::
sugars are removed.e[e]
.super
can exist on its own.Commas are no-longer part of this abstract syntax but we may still write them in our notation to make the presentation more clear.
Also removed in the core language are import
, importstr
, and importbin
. The
semantics of these constructs is that they are replaced with either the contents of the
file, or an error construct if importing failed (e.g. due to I/O errors). In the first
case, the file is parsed, desugared, and subject to static checking before it can be
substituted. In the case of importstr
, the file is substituted in the form of a string, so it
merely needs to contain valid UTF-8. For importbin
, the file is substituted as an array of integer numbers between 0 and 255 inclusive.
A given Jsonnet file can be recursively imported via import
. Thus, the
implementation loads files lazily (i.e. during execution) as opposed to via static
desugaring. The imported Jsonnet file is parsed and statically checked in isolation.
Therefore, the behavior of the import is not affected by the environment into which it is
imported. The files are cached by filename, so that even if the file changes on disk during
Jsonnet execution, referential transparency is maintained.
| e ∈ Core | ::= |
null |
true |
false |
self |
super |
string |
number
|
| | |
{
{
assert e
}
{
[ e ] h e
}
}
|
|
| | |
{
[ e ] : e
for id in e
}
|
|
| | |
[
{ e }
]
|
|
| | |
e
[
e
]
|
|
| | |
e
(
{ e }
{ id = e }
)
|
|
| | | id | |
| | |
local
id = e
{
id = e
}
;
e
|
|
| | |
if
e
then
e
else
e
|
|
| | | e binaryop e | |
| | | unaryop e | |
| | |
function
(
{ id = e }
)
e
|
|
| | |
error
e
|
Desugaring removes constructs that are not in the core language by replacing them with constructs that are. It is defined via the following functions, which proceed by syntax-directed recursion. If a function is not defined on a construct then it simply recurses into the sub-expressions of that construct. Note that we import the standard library at the top of every file, and some of the desugarings call functions defined in the standard library. Their behavior is specified by implementation. However not all standard library functions are written in Jsonnet. The ones that are built into the interpreter (e.g. reflection) will be given special operational semantics rules with the rest of the core language constructs.
desugar: Expr → Core. This desugars a Jsonnet file. Let \(e_{std}\) be the parsed content of std.jsonnet.
desugarexpr: (Expr × Boolean) → Core: This desugars an expression. The second parameter of the function tracks whether we are within an object.
desugarassert: (Field × [Bind]) → Field. This desugars object assertions.
desugarfield: (Field × [Bind] × Boolean) → Field. This desugars object fields.
Recall that h ranges over :
, ::
, :::
. The
boolean records whether the object containing this field is itself in another object. The
notation string(id) means converting the identifier token to a string literal.
desugarbind: (Bind × Boolean) → Field. This desugars local bindings.
desugarparam: (Param × Boolean) → Param. This desugars function parameters.
desugararrcomp: (Expr × CompSpec × Boolean) → Field. This desugars array comprehensions.
After the Jsonnet program is parsed and desugared, a syntax-directed algorithm is employed
to reject programs that contain certain classes of errors. This is presented like a static
type system, except that there are no static types. Programs are only rejected if they use
undefined variables, or if self
, super
or $
are used
outside the bounds of an object. In the core language, $
has been desugared to
a variable, so its checking is implicit in the checking of bound variables.
The static checking is described below as a judgement \(Γ ⊢ e\), where \(Γ\) is the set of
variables in scope of \(e\). The set \(Γ\) initially contains only std
, the
implicit standard library. In the case of imported files, each jsonnet file is checked
independently of the other files.
We present two sets of operational semantics rules. The first defines the judgement \(e ↓ v\) which represents the execution of Jsonnet expressions into Jsonnet values. The other defines the judgement \(v ⇓ j\) which represents manifestation, the process by which Jsonnet values are converted into JSON values.
We model both explicit runtime errors (raised by the error construct) and implicit runtime errors (e.g. array bounds errors) as stuck execution. Errors can occur both in the \(e ↓ v\) judgement and in the \(v ⇓ j\) judgement (because it is defined in terms of \(e ↓ v\)).
When executed, Jsonnet expressions yield Jsonnet values. These need to be manifested, an additional step, to get JSON values. The differences between Jsonnet values and JSON values are: 1) Jsonnet values contain functions (which are not representable in JSON). 2) Due to the lazy semantics, both object fields and array elements have yet to be executed to yield values. 3) Object assertions still need to be checked.
Execution of a statically-checked expression will never yield an object with duplicate field names. By abuse of notation, we consider two objects to be equivalent even if their fields and assertions are re-ordered. However this is not true of array elements or function parameters.
| v | ∈ | Value | = | Primitive ∪ Object ∪ Function ∪ Array |
| Primitive | ::= |
null | true | false | string
| double
|
||
| o | ∈ | Object | ::= |
{
{ assert e } { string h e }
}
|
| Function | ::= |
function ( { id=e } ) e
|
||
| a | ∈ | Array | ::= |
[ { e } ]
|
The hidden status of fields is preserved over inheritance if the right hand side uses the
:
form. This is codified with the following function:
The rules for capture-avoiding variable substitution [e/id] are an extension of those in the lambda calculus.
Let y ≠ x.
self [e/x] = self
|
|
super [e/x] = super
|
|
| x[e/x] = e | |
| y[e/x] = y | |
{
...
assert e'
...
[ e''] h e'''
...
} [e/x] =
{
...
assert e'[e/x]
...
[ e'[e/x]] h
e''[e/x]
...
}
|
|
{
[ e'] : e''
for x in e'''
} [e/x] =
{
[ e'] : e''
for x in e'''[e/x]
}
|
|
{
[ e'] : e''
for y in e'''
} [e/x] =
{
[ e'[e/x]]:
e''[e/x]
for y in e''' [e/x]
}
|
|
(local ... y= e' ... ; e'')
[e/x] =
local ... y= e' ... ; e''
|
(If any variable matches.) |
(local ... y= e' ... ; e'')
[e/x] =
local ... y= e'[e/x] ...
; e''[e/x]
|
(If no variable matches.) |
(function (
... y=e' ...
) e'')[e/x] =
function (
... y=e' ...
) e''
|
(If any param matches.) |
(function (
... y=e' ...
) e'')[e/x] =
function (
... y=e'[e/x] ...
) e''[e/x]
|
(If no param matches.) |
| Otherwise, e' [e/x] proceeds via syntax-directed recursion into subterms of e'. |
The rules for keyword substitution ⟦e/kw⟧ for kw ∈ { self
,
super
} avoid substituting keywords that are captured by nested objects:
self
⟦e/self ⟧ = e
|
super
⟦e/super ⟧ = e
|
self
⟦e/super ⟧ = self
|
super
⟦e/self ⟧ = super
|
{
...
assert e'
...
[ e''] h e'''
...
}
⟦e/kw⟧ =
{
...
assert e'
...
[ e''⟦e/kw⟧] h e'''
...
}
|
{
[ e'] : e''
for x in e'''
} ⟦e/kw⟧ =
{
[ e'⟦e'/kw⟧] : e''
for x in e'''⟦e/kw⟧
}
|
| Otherwise, e'⟦e'/kw⟧ proceeds via syntax-directed recursion into the subterms of e'. |
The following big step operational semantics rules define the execution of Jsonnet programs, i.e. the reduction of a Jsonnet program e into its Jsonnet value v via the judgement \(e ↓ v\).
Let f range over strings, as used in object field names.
String concatenation will implicitly convert one of the values to a string if necessary. This is similar to Java. The referred function \(tostring\) returns its argument unchanged if it is a string. Otherwise it will manifest its argument as a JSON value \(j\) and unparse it as a single line of text. The referred function \(strlen\) returns the number of unicode characters in the string.
The numeric semantics are as follows:
*
, /
, +
, -
,
<
, <=
, >
, >=
, and unary
+
and -
operate on numbers and have IEEE double precision
floating point semantics, except that the special states NaN, Infinity raise errors. Note
that +
is also overloaded on objects, arrays, and when either argument is a
string. Also, <
, <=
, >
, >=
are overloaded on strings and on arrays. In both cases the comparison is performed
lexicographically (in case of strings, by unicode codepoint).
<<
,
>>
,
&
,
^
,
|
and
~
first convert their operands to signed 64 bit integers, then perform the operations in a
standard way, then convert back to IEEE double precision floating point. In shift
operations <<
, >>
, the right hand value modulo 64 is
interpreted as the shift count. Shifting with a negative shift count raises an error.
std.pow(a, b)
,
std.floor(x)
,
std.ceil(x)
,
std.sqrt(x)
,
std.sin(x)
,
std.cos(x)
,
std.tan(x)
,
std.asin(x)
,
std.acos(x)
,
std.atan(x)
,
std.log(x)
,
std.exp(x)
,
std.mantissa(x)
,
std.exponent(x)
and
std.modulo(a, b)
.
Also, std.codepoint(x)
take a single character string,
returning the unicode codepoint as a number, and std.char(x)
is its inverse.
The error
operator has no rule because we model errors (both from the language
and user-defined) as stuck execution. The semantics of error
are that its
subterm is evaluated to a Jsonnet value. If this is a string, then that is the error that
is raised. Otherwise, it is converted to a string using \(tostring\) like during string
concatenation. The specification does not specify how the error is presented to the user,
and whether or not there is a stack trace. Error messages are meant for human inspection,
and there is therefore no need to standardize them.
Finally, the function std.native(x)
takes a string and returns a function
configured by the user in a custom execution environment, thus its semantics cannot be
formally described here. The function std.extVar(x)
also takes a string and
returns the value bound to that external variable at the time the Jsonnet
environment was created.
After execution, the resulting Jsonnet value is manifested into a JSON value whose serialized form is the ultimate output. The Manifestation process removes hidden fields, checks assertions, and forces array elements and non-hidden object fields. Attempting to manifest a function raises an error since they do not exist in JSON. JSON values are formalized below.
By abuse of notation, we consider two objects to be equivalent even if their fields are re-ordered. However this is not true of array elements whose ordering is strict.
| j | ∈ | JValue | = | Primitive ∪ JObject ∪ JArray |
| Primitive | ::= |
null | true | false | string |
double
|
||
| o | ∈ | JObject | ::= |
{ { string : j } }
|
| a | ∈ | Array | ::= |
[ { j } ]
|
Note that JValue ⊂ Value.
Manifestation is the conversion of a Jsonnet value into a JSON value. It is represented with the judgement \(v⇓j\). The process requires executing arbitrary Jsonnet code fragments, so the two semantic judgements represented by \(↓\) and \(⇓\) are mutually recursive. Hidden fields are ignored during manifestation. Functions cannot be manifested, so an error is raised in that case (formalized as stuck execution).


Lying at the mouth of the Hyeongsan River, Pohang sits at the head of a large bay. Rarely visited by non Russian or Japanese yachts.
Clear in with the friendly officials here.
There is no marina here. Moor to the wharf, which is free of charge.
Last updated March 2011.


Contexts and Dependency Injection for Java EE (CDI) is one of several Java EE features that help to knit together the web tier and the transactional tier of the Java EE platform. CDI is a set of services that, used together, make it easy for developers to use enterprise beans along with JavaServer Faces technology in web applications. Designed for use with stateful objects, CDI also has many broader uses, allowing developers a great deal of flexibility to integrate various kinds of components in a loosely coupled but typesafe way.
CDI 1.1 is specified by JSR 346. Related specifications that CDI uses include the following:
The following topics are addressed here:
Contexts and Dependency Injection (CDI) enables your objects to have their dependencies provided to them automatically, instead of creating them or receiving them as parameters. CDI also manages the lifecycle of those dependencies for you.
For example, consider the following servlet:
@WebServlet("/cdiservlet") public class NewServlet extends HttpServlet { private Message message; @Override public void init() { message = new MessageB(); } @Override public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException { response.getWriter().write(message.get()); } }
This servlet needs an instance of an object that implements the Message
interface:
public interface Message { public String get(); }
The servlet creates itself an instance of the following object:
public class MessageB implements Message { public MessageB() { } @Override public String get() { return "message B"; } }
Using CDI, this servlet can declare its dependency on a Message
instance and have it injected automatically by the CDI runtime. The new servlet code is the following:
@WebServlet("/cdiservlet") public class NewServlet extends HttpServlet { @Inject private Message message; @Override public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException { response.getWriter().write(message.get()); } }
The CDI runtime looks for classes that implement the Message
interface, finds the MessageB
class, creates a new instance of it, and injects it into the servlet at runtime. To manage the lifecycle of the new instance, the CDI runtime needs to know what the scope of the instance should be. In this example, the servlet only needs the instance to process an HTTP request; the instance can then be garbage collected. This is specified using the javax.enterprise.context.RequestScoped
annotation:
@RequestScoped public class MessageB implements Message { ... }
For more information on scopes, see Using Scopes.
The MessageB
class is a CDI bean. CDI beans are classes that CDI can instantiate, manage, and inject automatically to satisfy the dependencies of other objects. Almost any Java class can be managed and injected by CDI. For more information on beans, see About Beans. A JAR or WAR file that contains a CDI bean is a bean archive. For more information on packaging bean archives, see Configuring a CDI Application in this chapter and Packaging CDI Applications in Chapter 25, "Contexts and Dependency Injection for Java EE: Advanced Topics".
In this example, MessageB
is the only class that implements the Message
interface. If an application has more than one implementation of an interface, CDI provides mechanisms that you can use to select which implementation to inject. For more information, see Using Qualifiers in this chapter and Using Alternatives in CDI Applications in Chapter 25, "Contexts and Dependency Injection for Java EE: Advanced Topics".
The most fundamental services provided by CDI are as follows.
Contexts: This service enables you to bind the lifecycle and interactions of stateful components to well-defined but extensible lifecycle contexts.
Dependency injection: This service enables you to inject components into an application in a typesafe way and to choose at deployment time which implementation of a particular interface to inject.
In addition, CDI provides the following services:
Integration with the Expression Language (EL), which allows any component to be used directly within a JavaServer Faces page or a JavaServer Pages page
The ability to decorate injected components
The ability to associate interceptors with components using typesafe interceptor bindings
An event-notification model
A web conversation scope in addition to the three standard scopes (request, session, and application) defined by the Java Servlet specification
A complete Service Provider Interface (SPI) that allows third-party frameworks to integrate cleanly in the Java EE 7 environment
A major theme of CDI is loose coupling. CDI does the following:
Decouples the server and the client by means of well-defined types and qualifiers, so that the server implementation may vary
Decouples the lifecycles of collaborating components by
Making components contextual, with automatic lifecycle management
Allowing stateful components to interact like services, purely by message passing
Completely decouples message producers from consumers, by means of events
Decouples orthogonal concerns by means of Java EE interceptors
Along with loose coupling, CDI provides strong typing by
Eliminating lookup using string-based names for wiring and correlations so that the compiler will detect typing errors
Allowing the use of declarative Java annotations to specify everything, largely eliminating the need for XML deployment descriptors, and making it easy to provide tools that introspect the code and understand the dependency structure at development time
CDI redefines the concept of a bean beyond its use in other Java technologies, such as the JavaBeans and Enterprise JavaBeans (EJB) technologies. In CDI, a bean is a source of contextual objects that define application state and/or logic. A Java EE component is a bean if the lifecycle of its instances may be managed by the container according to the lifecycle context model defined in the CDI specification.
More specifically, a bean has the following attributes:
A (nonempty) set of bean types
A (nonempty) set of qualifiers (see Using Qualifiers)
A scope (see Using Scopes)
Optionally, a bean EL name (see Giving Beans EL Names)
A set of interceptor bindings
A bean implementation
A bean type defines a client-visible type of the bean. Almost any Java type may be a bean type of a bean.
A bean type may be an interface, a concrete class, or an abstract class and may be declared final or have final methods.
A bean type may be a parameterized type with type parameters and type variables.
A bean type may be an array type. Two array types are considered identical only if the element type is identical.
A bean type may be a primitive type. Primitive types are considered to be identical to their corresponding wrapper types in java.lang
.
A bean type may be a raw type.
A managed bean is implemented by a Java class, which is called its bean class. A top-level Java class is a managed bean if it is defined to be a managed bean by any other Java EE technology specification, such as the JavaServer Faces technology specification, or if it meets all the following conditions.
It is not a nonstatic inner class.
It is a concrete class or is annotated @Decorator
.
It is not annotated with an EJB component-defining annotation or declared as an EJB bean class in ejb-jar.xml
.
It has an appropriate constructor. That is, one of the following is the case.
The class has a constructor with no parameters.
The class declares a constructor annotated @Inject
.
No special declaration, such as an annotation, is required to define a managed bean.
The concept of injection has been part of Java technology for some time. Since the Java EE 5 platform was introduced, annotations have made it possible to inject resources and some other kinds of objects into container-managed objects. CDI makes it possible to inject more kinds of objects and to inject them into objects that are not container-managed.
The following kinds of objects can be injected:
(Almost) any Java class
Session beans
Java EE resources: data sources, Java Message Service topics, queues, connection factories, and the like
Persistence contexts (Java Persistence API EntityManager
objects)
Producer fields
Objects returned by producer methods
Web service references
Remote enterprise bean references
For example, suppose that you create a simple Java class with a method that returns a string:
package greetings; public class Greeting { public String greet(String name) { return "Hello, " + name + "."; } }
This class becomes a bean that you can then inject into another class. This bean is not exposed to the EL in this form. Giving Beans EL Names explains how you can make a bean accessible to the EL.
You can use qualifiers to provide various implementations of a particular bean type. A qualifier is an annotation that you apply to a bean. A qualifier type is a Java annotation defined as @Target({METHOD, FIELD, PARAMETER, TYPE})
and @Retention(RUNTIME)
.
For example, you could declare an @Informal
qualifier type and apply it to another class that extends the Greeting
class. To declare this qualifier type, you would use the following code:
package greetings; import static java.lang.annotation.ElementType.FIELD; import static java.lang.annotation.ElementType.METHOD; import static java.lang.annotation.ElementType.PARAMETER; import static java.lang.annotation.ElementType.TYPE; import static java.lang.annotation.RetentionPolicy.RUNTIME; import java.lang.annotation.Retention; import static java.lang.annotation.RetentionPolicy.RUNTIME; import java.lang.annotation.Target; import javax.inject.Qualifier; @Qualifier @Retention(RUNTIME) @Target({TYPE, METHOD, FIELD, PARAMETER}) public @interface Informal {}
You can then define a bean class that extends the Greeting
class and uses this qualifier:
package greetings; @Informal public class InformalGreeting extends Greeting { public String greet(String name) { return "Hi, " + name + "!"; } }
Both implementations of the bean can now be used in the application.
If you define a bean with no qualifier, the bean automatically has the qualifier @Default
. The unannotated Greeting
class could be declared as follows:
package greetings; import javax.enterprise.inject.Default; @Default public class Greeting { public String greet(String name) { return "Hello, " + name + "."; } }
In order to use the beans you create, you inject them into yet another bean that can then be used by an application, such as a JavaServer Faces application. For example, you might create a bean called Printer
into which you would inject one of the Greeting
beans:
import javax.inject.Inject; public class Printer { @Inject Greeting greeting; ... }
This code injects the @Default
Greeting
implementation into the bean. The following code injects the @Informal
implementation:
import javax.inject.Inject; public class Printer { @Inject @Informal Greeting greeting; ... }
More is needed for the complete picture of this bean. Its use of scope needs to be understood. In addition, for a JavaServer Faces application, the bean needs to be accessible through the EL.
For a web application to use a bean that injects another bean class, the bean needs to be able to hold state over the duration of the user's interaction with the application. The way to define this state is to give the bean a scope. You can give an object any of the scopes described in Table 23-1, depending on how you are using it.
Table 23-1 Scopes
| Scope | Annotation | Duration |
|---|---|---|
|
Request |
|
A user's interaction with a web application in a single HTTP request. |
|
Session |
|
A user's interaction with a web application across multiple HTTP requests. |
|
Application |
|
Shared state across all users' interactions with a web application. |
|
Dependent |
|
The default scope if none is specified; it means that an object exists to serve exactly one client (bean) and has the same lifecycle as that client (bean). |
|
Conversation |
|
A user's interaction with a servlet, including JavaServer Faces applications. The conversation scope exists within developer-controlled boundaries that extend it across multiple requests for long-running conversations. All long-running conversations are scoped to a particular HTTP servlet session and may not cross session boundaries. |
The first three scopes are defined by both JSR 346 and the JavaServer Faces specification. The last two are defined by JSR 346.
All predefined scopes except @Dependent
are contextual scopes. CDI places beans of contextual scope in the context whose lifecycle is defined by the Java EE specifications. For example, a session context and its beans exist during the lifetime of an HTTP session. Injected references to the beans are contextually aware. The references always apply to the bean that is associated with the context for the thread that is making the reference. The CDI container ensures that the objects are created and injected at the correct time as determined by the scope that is specified for these objects.
You can also define and implement custom scopes, but that is an advanced topic. Custom scopes are likely to be used by those who implement and extend the CDI specification.
A scope gives an object a well-defined lifecycle context. A scoped object can be automatically created when it is needed and automatically destroyed when the context in which it was created ends. Moreover, its state is automatically shared by any clients that execute in the same context.
Java EE components, such as servlets and enterprise beans, and JavaBeans components do not by definition have a well-defined scope. These components are one of the following:
Singletons, such as Enterprise JavaBeans singleton beans, whose state is shared among all clients
Stateless objects, such as servlets and stateless session beans, which do not contain client-visible state
Objects that must be explicitly created and destroyed by their client, such as JavaBeans components and stateful session beans, whose state is shared by explicit reference passing between clients
If, however, you create a Java EE component that is a managed bean, it becomes a scoped object, which exists in a well-defined lifecycle context.
The web application for the Printer
bean will use a simple request and response mechanism, so the managed bean can be annotated as follows:
import javax.enterprise.context.RequestScoped; import javax.inject.Inject; @RequestScoped public class Printer { @Inject @Informal Greeting greeting; ... }
Beans that use session, application, or conversation scope must be serializable, but beans that use request scope do not have to be serializable.
To make a bean accessible through the EL, use the @Named
built-in qualifier:
import javax.enterprise.context.RequestScoped; import javax.inject.Inject; import javax.inject.Named; @Named @RequestScoped public class Printer { @Inject @Informal Greeting greeting; ... }
The @Named
qualifier allows you to access the bean by using the bean name, with the first letter in lowercase. For example, a Facelets page would refer to the bean as printer
.
You can specify an argument to the @Named
qualifier to use a nondefault name:
@Named("MyPrinter")
With this annotation, the Facelets page would refer to the bean as MyPrinter
.
To make the state of the managed bean accessible, you need to add setter and getter methods for that state. The createSalutation
method calls the bean's greet
method, and the getSalutation
method retrieves the result.
Once the setter and getter methods have been added, the bean is complete. The final code looks like this:
package greetings; import javax.enterprise.context.RequestScoped; import javax.inject.Inject; import javax.inject.Named; @Named @RequestScoped public class Printer { @Inject @Informal Greeting greeting; private String name; private String salutation; public void createSalutation() { this.salutation = greeting.greet(name); } public String getSalutation() { return salutation; } public void setName(String name) { this.name = name; } public String getName() { return name; } }
To use the managed bean in a Facelets page, you typically create a form that uses user interface elements to call its methods and display their results. This example provides a button that asks the user to type a name, retrieves the salutation, and then displays the text in a paragraph below the button:
<h:form id="greetme">
<h:outputLabel value="Enter your name: " for="name"/> <h:inputText id="name" value="#{printer.name}"/>

<h:commandButton value="Say Hello" action="#{printer.createSalutation}"/>

<h:outputText value="#{printer.salutation}"/>
 </h:form>
Producer methods provide a way to inject objects that are not beans, objects whose values may vary at runtime, and objects that require custom initialization. For example, if you want to initialize a numeric value defined by a qualifier named @MaxNumber
, you can define the value in a managed bean and then define a producer method, getMaxNumber
, for it:
private int maxNumber = 100; ... @Produces @MaxNumber int getMaxNumber() { return maxNumber; }
When you inject the object in another managed bean, the container automatically invokes the producer method, initializing the value to 100:
@Inject @MaxNumber private int maxNumber;
If the value can vary at runtime, the process is slightly different. For example, the following code defines a producer method that generates a random number defined by a qualifier called @Random
:
private java.util.Random random = new java.util.Random( System.currentTimeMillis() ); java.util.Random getRandom() { return random; } @Produces @Random int next() { return getRandom().nextInt(maxNumber); }
When you inject this object in another managed bean, you declare a contextual instance of the object:
@Inject @Random Instance<Integer> randomInt;
You then call the get
method of the Instance
:
this.number = randomInt.get();
When your beans are annotated with a scope type, the server recognizes the application as a bean archive and no additional configuration is required. The possible scope types for CDI beans are listed in Using Scopes.
CDI uses an optional deployment descriptor named beans.xml
. Like other Java EE deployment descriptors, the configuration settings in beans.xml
are used in addition to annotation settings in CDI classes. The settings in beans.xml
override the annotation settings if there is a conflict. An archive must contain the beans.xml
deployment descriptor only in certain limited situations, described in Chapter 25, "Contexts and Dependency Injection for Java EE: Advanced Topics".
For a web application, the beans.xml
deployment descriptor, if present, must be in the WEB-INF
directory. For EJB modules or JAR files, the beans.xml
deployment descriptor, if present, must be in the META-INF
directory.
CDI managed bean classes and their superclasses support the annotations for initializing and for preparing for the destruction of a bean. These annotations are defined in JSR 250: Common Annotations for the Java platform (http://jcp.org/en/jsr/detail?id=250
).
Initializing a managed bean specifies the lifecycle callback method that the CDI framework should call after dependency injection but before the class is put into service.
In the managed bean class or any of its superclasses, define a method that performs the initialization that you require.
Annotate the declaration of the method with the javax.annotation.PostConstruct
annotation.
When the managed bean is injected into a component, CDI calls the method after all injection has occurred and after all initializers have been called.
|
Note: As mandated in JSR 250, if the annotated method is declared in a superclass, the method is called unless a subclass of the declaring class overrides the method. |
The UserNumberBean
managed bean in The guessnumber-cdi CDI Example uses @PostConstruct
to annotate a method that resets all bean fields:
@PostConstruct public void reset () { this.minimum = 0; this.userNumber = 0; this.remainingGuesses = 0; this.maximum = maxNumber; this.number = randomInt.get(); }
Preparing for the destruction of a managed bean specifies the lifecycle call back method that signals that an application component is about to be destroyed by the container.
In the managed bean class or any of its superclasses, prepare for the destruction of the managed bean.
In this method, perform any cleanup that is required before the bean is destroyed, such as releasing a resource that the bean has been holding.
Annotate the declaration of the method with the javax.annotation.PreDestroy
annotation.
CDI calls this method before starting to destroy the bean.
For more information about CDI, see
Contexts and Dependency Injection for Java EE specification:
An introduction to Contexts and Dependency Injection for Java EE:
Dependency Injection for Java specification:
Managed Beans specification, which is part of the Java Platform, Enterprise Edition 7 (Java EE 7) Specification: