Specialize to reuse
TL;DR: specialization supports clean, inheritance-like patterns out of the box. This post explains how, and discusses the interaction with the “virtual structs” saga.
I’ve been working for a while with Niko Matsakis and Nick Cameron on another round of design for handling type hierarchies like those found in the DOM, in GUI frameworks, and even the compiler’s AST. The Rust community has gone through many iterations of design in this space, having identified the following goals for a type hierarchy design:
- cheap field access from internal methods;
- cheap dynamic dispatch of methods;
- cheap downcasting;
- thin pointers;
- sharing of fields and methods between definitions;
- safe, i.e., doesn’t require a bunch of transmutes or other unsafe code to be usable;
- syntactically lightweight or implicit upcasting;
- calling functions through smart pointers, e.g.
fn foo(JSRef<T>, ...)
; - static dispatch of methods.
Two important constraints are missing from this prior list, one technical and one philosophical:
- reusable constructor code at every level of the hierarchy;
- fits well into the language, either by smoothly extending existing features, or by adding orthogonal concepts.
In the design I’ve been pursuing, impl
specialization plays a key
role. That’s appealing because specialization is something we’ve long wanted for
other reasons, and is a natural deepening of our trait system. But it’s not
quite enough, by itself, to meet all of the constraints above.
I’m going to start by recapping the specialization design. Then I’ll explore two competing avenues for building on specialization to meet the design constraints, choose-your-own-adventure style. At the end, I’ll give my current opinions on where we ought to go.
Specialization as proposed
Specialization allows overlapping trait (and inherent) impls, so long
as there is always a “most specific” impl that applies to a given concrete type.
The more general impl uses default
to signal which items can be specialized –
sort of the opposite of final
in Java, or a bit like virtual
in C++.
One of the major intended uses is to support true zero-cost abstraction, by allowing you to customize the impl for specific cases to match performance of non-abstract impls, while maintaining the abstraction for clients. To quote from the RFC:
Traits today can provide static dispatch in Rust, but they can still impose an abstraction tax. For example, consider the
Extend
trait:pub trait Extend<A> { fn extend<T>(&mut self, iterable: T) where T: IntoIterator<Item=A>; }
Collections that implement the trait are able to insert data from arbitrary iterators. Today, that means that the implementation can assume nothing about the argument
iterable
that it’s given except that it can be transformed into an iterator. That means the code must work by repeatedly callingnext
and inserting elements one at a time.But in specific cases, like extending a vector with a slice, a much more efficient implementation is possible – and the optimizer isn’t always capable of producing it automatically. In such cases, specialization can be used to get the best of both worlds: retaining the abstraction of
extend
while providing custom code for specific cases.The design in this RFC relies on multiple, overlapping trait impls, so to take advantage for
Extend
we need to refactor a bit:pub trait Extend<A, T: IntoIterator<Item=A>> { fn extend(&mut self, iterable: T); } // The generic implementation impl<A, T> Extend<A, T> for Vec<A> where T: IntoIterator<Item=A> { // the `default` qualifier allows this method to be specialized below default fn extend(&mut self, iterable: T) { ... // implementation using push (like today's extend) } } // A specialized implementation for slices impl<'a, A> Extend<A, &'a [A]> for Vec<A> { fn extend(&mut self, iterable: &'a [A]) { ... // implementation using ptr::write (like push_all) } }
Because the generic impl uses default
for its implementation of extend
, it’s
permitted to give a more specialized impl block that overrides it. (The block is
more specialized because it applies to a subset of the types the generic one
applies to.)
A specialized impl doesn’t have to provide all the items for a trait; whatever
it doesn’t provide is automatically inherited from the generic impl it’s
specializing. And conversely, it can only override items marked default
.
Going a bit farther, it’s possible to specialize not just impls for a trait, but
also defaults for a trait. This is done via partial impl
blocks, which are
impls that provide some, but not all, of the items required by a trait. Again
quoting the RFC:
For example, consider a design for overloading
+
and+=
, such that they are always overloaded together:trait Add<Rhs=Self> { type Output; fn add(self, rhs: Rhs) -> Self::Output; fn add_assign(&mut self, Rhs); }
In this case, there’s no natural way to provide a default implementation of
add_assign
, since we do not want to restrict theAdd
trait toClone
data.The specialization design in this RFC also allows for partial implementations, which can provide specialized defaults without actually providing a full trait implementation:
partial impl<T: Clone, Rhs> Add<Rhs> for T { // the `default` qualifier allows further specialization default fn add_assign(&mut self, rhs: R) { let tmp = self.clone() + rhs; *self = tmp; } }
This partial impl does not mean that
Add
is implemented for allClone
data, but jut that when you do implAdd
andSelf: Clone
, you can leave offadd_assign
:#[derive(Copy, Clone)] struct Complex { // ... } impl Add<Complex> for Complex { type Output = Complex; fn add(self, rhs: Complex) { // ... } // no fn add_assign necessary }
A small addendum
The specialization RFC touches on, but doesn’t actually specify, a way to
“access” the implementation you’re overriding (akin to super
in the OO world).
For the sake of this post, I’ll assume we’ve added such a mechanism by way of a
UFCS-like use of default
:
trait Foo {
fn foo(&self);
}
impl<T> Foo for T {
default fn foo(&self) {
// do some complicated stuff
}
}
impl<T: Debug> Foo {
fn foo(&self) {
println!("About to `foo` on {:?}", self);
default::foo(self);
}
}
The idea is that the default::
prefix accessing the generic impl that’s being
overridden, and works like UFCS (in that methods become functions taking self
explicitly).
The details here aren’t so important, as long as specialization supports some mechanism like this (which was always the intent).
Ending 1: the trait-based approach
It should already be clear that specialization has a connection to inheritance, because items left off of a specialized impl are inherited from the impl (partial or otherwise) it is specializing. As it turns out, that’s already enough to code up something like traditional type hierarchies in OO languages. You can get pretty far!
Here’s an example, using a lightly simplified extract from Servo’s DOM implementation.
// Node ////////////////////////////////////////////////////////////////////////
trait Node {
fn parse_plain_attribute(&self, name: &Atom, value: DomString) -> AttrValue {
AttrValue::String(value)
}
// additional virtual methods for Node
}
// non-virtual methods for Node
impl Node {
fn is_parent_of(&self, child: &Node) -> bool {
// ...
}
// additional methods here
}
// Element /////////////////////////////////////////////////////////////////////
trait Element: Node {
fn as_activatable(&self) -> Option<&Activatable> {
None
}
// additional Element methods
}
// non-virtual methods for Element
impl Element {
fn nearest_activable_element(&self) -> Option<&Element> {
// ...
}
}
partial impl<T: Element> Node for T {
default fn parse_plain_attribute(&self, name: &Atom, value: DomString) -> AttrValue {
match name {
&atom!("id") => AttrValue::from_atomic(value),
&atom!("class") => AttrValue::from_serialized_tokenlist(value),
_ => default::parse_plain_attribute(self, name, value),
}
}
}
// Activatable /////////////////////////////////////////////////////////////////
trait Activatable: Element {
// moar methods
}
partial impl<T: Activatable> Element for T {
fn as_activatable(&self) -> Option<&Activatable> {
Some(self)
}
}
// HtmlAnchorElement ///////////////////////////////////////////////////////////
struct HtmlAnchorElement {
rel_list: DomTokenList,
// moar fields
}
impl Node for HtmlAnchorElement {
fn parse_plain_attribute(&self, name: &Atom, value: DOMString) -> AttrValue {
match name {
&atom!("rel") => AttrValue::from_serialized_tokenlist(value),
_ => default::parse_plain_attribute(self, name, value),
}
}
}
impl Element for HtmlAnchorElement {
// ...
}
impl Activatable for HtmlAnchorElement {
// ...
}
// HtmlImageElement ////////////////////////////////////////////////////////////
struct HtmlImageElement {
url: Option<Url>,
image: Option<Arc<Image>>,
// moar fields
}
impl Node for HtmlImageElement {
fn parse_plain_attribute(&self, name: &Atom, value: DOMString) -> AttrValue {
match name {
&atom!("name") => AttrValue::from_atomic(value),
&atom!("width") | &atom!("height") |
&atom!("hspace") | &atom!("vspace") => AttrValue::from_u32(value, 0),
_ => default::parse_plain_attribute(self, name, value),
}
}
}
impl Element for HtmlImageElement {
// ...
}
This example is following a basic pattern:
“Abstract base classes” turn into traits.
Their virtual methods become methods in the traits (e.g.
parse_plain_attribute
).- They will be virtually dispatched when using trait objects, and statically
dispatched when used directly on a type implementing the trait (as usual).
In practice that means that after the first virtual call, additional calls
on
self
are statically-dispatched.
- They will be virtually dispatched when using trait objects, and statically
dispatched when used directly on a type implementing the trait (as usual).
In practice that means that after the first virtual call, additional calls
on
Their non-virtual methods become inherent methods for the trait, DST style (e.g.
is_parent_of
). These are always statically-dispatched.Default implementations of methods can be done via … defaulted methods!
“Concrete classes” turn into structs.
The structs implement all of the traits for the abstract base classes above them.
In this case, “overriding” generally just means supplying an impl when a default was available.
Methods can be overridden at any point in the hierarchy.
This is done via a blanket (partial) impl, like
partial impl<T: Element> Node for T
.When one abstract base class overrides its parent, it generally uses
partial impl
. This is because there are usually still some “abstract” aka “pure virtual” methods for the parent (which are just required methods on the trait).If further overriding should be allowed, these (partial) impls should use
default
.- For example, the
as_activatable
method is overridden forT: Activatable
with a “final” version that cannot be further overridden.
- For example, the
And that’s it. This entire vision of OO-ish programming rests on using the existing system of dynamic dispatch through traits, and gets reuse/inheritance via specialization.
Let’s take stock of the design constraints:
- cheap field access from internal methods;
- No: traits have no way to talk about fields directly, and accessors require virtual dispatch (much more expensive than a fixed offset).
- cheap dynamic dispatch of methods;
- Yes: covered via the trait system.
- cheap downcasting;
- Yes: see the
as_activatable
pattern.
- Yes: see the
- thin pointers;
- No: trait objects use fat pointers.
- sharing of fields and methods between definitions;
- Yes for methods (via specialization), No for fields.
- safe, i.e., doesn’t require a bunch of transmutes or other unsafe code to be usable;
- Yes.
- syntactically lightweight or implicit upcasting;
- Yes, once we have it for super-traits in general (an already-slated, highly desired, simple feature).
- calling functions through smart pointers, e.g.
fn foo(JSRef<T>, ...)
;- Yes, via existing coercion/Deref mechanisms.
- static dispatch of methods;
- Yes, as discussed avove.
- reusable constructor code at every level of the hierarchy;
- No, because fields are not addressed.
- fits well into the language, either by smoothly extending existing features,
or by adding orthogonal concepts.
- Yes: we didn’t have to add anything beyond specialization (which we’re taking for granted here).
So, we essentially met all but two requirements: thin pointers, and field access/inheritance. What’s the simplest way we could accommodate those?
Thin pointers: #[repr(thin)]
Recall that today, trait objects are “fat pointers”: a pointer to some data, and a pointer to a vtable containing methods for operating on that data.
This representation is not an arbitrary choice. It goes hand-in-hand with an
important aspect of traits: you can implement a new trait for an already-defined
type. This makes traits quite unlike interfaces in languages like Java, C#, or
Scala, which have to be applied when you define a type. Traits are flexible bits
of glue that can be applied after the fact. But the tradeoff is that the vtable
cannot be part of the Self
type, at least not if you want separate
compilation. After all, the crate defining a struct
simply does not know
what traits might eventually be applied.
On the other hand, these fat pointers have a drawback: space overhead. In particular, if you have a dense graph of trait objects that are pointing to each other, each pointer’s size is doubled, but the information being stored is often redundant (and the relevant traits are often implemented up front). For serious object graphs, this is a non-starter.
In Rust, when faced with representation tradeoffs, we have a simple tool: the
repr
attribute. So we can address the desire for thin pointers to traits by
introducing #[repr(thin)]
:
#[repr(thin)]
trait MyThinTrait {
fn doit(&self);
}
struct MyType {
// ...
}
impl MyThinTrait for MyType {
fn doit(&self) { /* ... */ }
}
fn take_thin(t: &MyThinTrait) {
t.doit()
}
Applying #[repr(thin)]
to a trait like MyThinTrait
has a few implications:
The representation of types like
&MyThinTrait
(used intake_thin
) is a single pointer, which points to a vtable followed by the data.You can only implement a thin trait for types you define in your crate.
If you implement multiple thin traits for a given type, they must form a hierarchy. That ensures consistent layout of the vtable.
Thin traits are a useful representation for Rust to offer regardless of any notion of “inheritance”.
Incorporating fields
Now all that’s left to handle is fields. To get maximal performance, we need
some way for a trait to require that Self
provides specific fields at
statically-known locations (which is true for genuine inheritance hierarchies
as one gets in languages like C++). In particular, accessing such fields through
a trait is no more expensive than accessing them directly through a known
struct: you just load the offset. But unlike a full struct definition, this only
requires the existence of a specific field at a specific location; it doesn’t
constrain other fields that might be available.
(Note: it may also be desirable to support fields in traits at dynamic offsets, which is still faster than a full dynamic dispatch, but that’s distinct from the requirements set out at the beginning of the post.)
In addition, it would be ideal if field definitions only have to be mentioned once, not repeated in every trait and struct definition that is talking about them.
There are likely a lot of ways we could accomplish these goals, but I’ll highlight a few promising ones, in order of increasing complexity: struct composition, struct inheritance, and trait fields.
Struct composition
There’s a very simple way, in today’s Rust, for one struct to contain all of the information of another struct: simply include the other struct as a field!
struct NodeFields {
event_target: EventTarget,
parent_node: Arc<Node>, // Note: this refers to the Node *trait*! see below.
first_child: Arc<Node>,
last_child: Arc<Node>,
next_sibling: Arc<Node>,
prev_sibling: Arc<Node>,
// ...
}
struct ElementFields {
node_fields: NodeFields,
local_name: Atom,
namespace: Namespace,
// ...
}
In this example, Element
“inherits” the fields of Node
simply by embedding
them. This approach also neatly solves the problem of reusing constructors
across the hierarchy: a Node
here is already a partly-constructed Element
.
So the remaining question is how to gain access to these fields in a trait. Here’s one possibility:
trait Node: NodeFields { /* ... */ }
trait Element: Node + ElementFields { /* ... */ }
The idea is that a trait can list any number of super-structs (including
indirectly through super-traits), so long as those structs form a composition
hierarchy: they must form a chain where each struct contains a leading field
whose type is the next struct (like with ElementFields
and NodeFields
above). The chain then ends in the Self
type implementing the trait.
So, to complete the DOM example, we’d have:
struct HtmlAnchorElement {
element_fields: ElementFields, // internally, contains a leading NodeFields
rel_list: DomTokenList,
// moar fields
}
impl Node for HtmlAnchorElement { /* ... */ }
impl Element for HtmlAnchorElement { /* ... */ }
When the trait is in scope, it allows direct access to the fields as if they had been flattened into the struct:
fn parent_node_via_element(e: &Element) -> Arc<node> {
e.parent_node.clone()
}
(A more verbose alternative might be some UFCS-style <self as
NodeFields>::parent_node.clone()
.)
Of course, this proposal assumes that structs beginning with the same leading field always lay that field out in the same way – in particular, this rules out reordering of the field. If we don’t want to make such a guarantee, we could limit use of struct bounds to thin traits. Since thin traits are implemented for structs in the same crate defining those structs, they can impose additional representation constraints.
Struct inheritance
The above struct composition approach is, in some ways, pretty simple. It builds directly on current patterns for building hierarchies of structs. But it is perhaps too targeted and narrow.
A more expansive alternative is explicit struct inheritance. The basic idea here is very simple:
struct NodeFields {
event_target: EventTarget,
parent_node: Arc<Node>,
// ...
}
// implicitly contains all of NodeFields fields
struct ElementFields: NodeFields {
local_name: Atom,
namespace: Namespace,
// ...
}
The initializer sytax for child structs would then permit either providing all field explicitly, or extending from an instance of the parent structure:
// Style 1: all fields
let e1: ElementFields = ElementFields {
event_target: /* ... */,
parent_node: /* ... */,
// more NodeFields fields
local_name: /* ... */,
namespace: /* ... */,
// more ElementFields fields
};
// Style 2: using parent struct
let n: NodeFields = NodeFields {
event_target: /* ... */,
parent_node: /* ... */,
// more NodeFields fields
};
let e2: ElementFields = ElementFields {
local_name: /* ... */,
namespace: /* ... */,
// more ElementFields fields
..n
};
This covers the need for constructors at each level of the hierarchy. But what about hooking into traits?
With struct inheritance, we can treat structs in general as something you can write in a bound, e.g.:
fn take_node_descendant<T: NodeFields>(t: &T) -> Arc<Node> {
t.parent_node.clone()
}
// same as writing `trait Node where Self: NodeFields`
trait Node: NodeFields { /* ... */ }
In all cases, using a struct as a bound like T: NodeFields
means that T
must inherit from NodeFields
. For traits, that would immediately give you
access to the fields, and would impose the fixed static offset requirement
(giving maximal performance when accessing those fields). That is, given the
definition of Node
above, if we have n: &Node
, we could write
n.parent_node
and that would compile as if we had n: NodeFields
instead.
Because inheritance is explicit at the point of struct definition, we don’t have
the layout worries we had with struct composition; we can lay out child structs
so that their parents are always consistent prefixes.
It’s plausible that struct inheritance is generally useful outside of OO-like
hierarchies; certainly it avoids long chains like
my_struct.parent1.parent2.actual_field
one gets when using struct composition
at scale, although the previous proposal does that as well.
While it’s not necessary to address our goals here, you could also imagine adding coercions from
&ElementFields
to&NodeFields
.
Trait fields
Finally, we could imagine instead adding fields directly to traits:
trait Node {
parent_node: Arc<Node>,
// ...
}
This raises a few questions:
- What do you have to say in an
impl
? - Can the fields be hooked up arbitrarily to
Self
, or must they form a prefix? - Can you avoid writing out copies of the field definitions in every struct in the hierarchy?
There are many ways we might answer these questions, and I won’t try to fully
explore the space here. But a simple option is to say that the fields must form
a prefix of the fields of Self
, and you don’t have to say anything in an
impl. Furthermore, if you write:
struct HtmlAnchorElement: Element {
rel_list: DomTokenList,
// moar fields
}
you automatically include the fields mentioned in the Element
trait (including
those from its super-trait Node
) as leading fields in the struct.
If we furthermore want to provide reusable constructors at every level of the hierarchy, we have to also include some way of naming these intermediate structs and using them in initaializers, e.g.:
let n: Node::struct = Node::struct {
event_target: /* ... */,
parent_node: /* ... */,
// more Node fields
};
let e: Element::struct = Element::struct {
local_name: /* ... */,
namespace: /* ... */,
// more Element fields
..n
};
let h: HtmlAnchorElement = HtmlAnchorElement {
rel_list: /* ... */,
// more HtmlAnchorElement fields
..e
}
The main advantage of this approach over the previous ones is that you avoid the
need to explicitly name structs corresponding to “abstract base classes” (like
NodeFields
and ElementFields
); instead, these are implicit via the
::struct
associated type. But there remain questions about using this syntax
more flexibly, for mapping trait fields in more arbitrary ways to struct fields,
without giving up performance in the fixed-offset case.
A downside is the question of visibility: currently all items in a trait are considered public, but this is not necessarily desirable for fields, so we’d likely need some way to express visibility choices. Fitting that into the existing syntax is not going to be easy. Whereas with struct composition or inheritance, it just “falls out” of the struct definitions.
Ending 2: the enum-based approach
Whew! So all of the proposals we just saw took traits as the sole source of dynamic dispatch and tried to close remaining gaps through slight enrichments of traits and structs.
A radically different approach takes the perspective that Rust already has two forms of dynamic dispatch today – traits and match expressions – corresponding to “open” (extensible) and closed sets of types respectively.
Niko Matsakis outlined a substantial expansion to enums in his recent post, which is part of the original design he, Nick Cameron, and I had been working on. The missing piece in that post is how to tie it together with specialization and thereby get something more like inheritance.
I won’t recap the whole proposal here (it’s worth a read in full!), but in short it makes enums into full-blown hierarchies, defining types at every level (and structs at the leaves):
unsized enum Node {
// where this node is positioned after layout
position: Rectangle,
...
}
enum Element: Node {
...
}
struct TextElement: Element {
...
}
struct ParagraphElement: Element {
...
}
...
Given such a hierarchy, you can write:
fn takes_any_node<T: Node>(n: &T) { ... }
That is, you can use an enum as a bound, which stands for “any variant of this enum”, but will be statically resolved via monomorphization.
This immediately opens the door to specialization for reuse:
trait ParsePlainAttribute {
fn parse_plain_attribute(&self, name: &Atom, value: DomString) -> AttrValue;
}
impl<T: Node> ParsePlainAttribute for T {
default fn parse_plain_attribute(&self, name: &Atom, value: DomString) -> AttrValue {
AttrValue::String(value)
}
}
impl<T: Element> ParsePlainAttribute for T {
default fn parse_plain_attribute(&self, name: &Atom, value: DomString) -> AttrValue {
match name {
&atom!("id") => AttrValue::from_atomic(value),
&atom!("class") => AttrValue::from_serialized_tokenlist(value),
_ => default::parse_plain_attribute(self, name, value),
}
}
}
impl ParsePlainAttribute for HtmlAnchorElement {
fn parse_plain_attribute(&self, name: &Atom, value: DOMString) -> AttrValue {
match name {
&atom!("rel") => AttrValue::from_serialized_tokenlist(value),
_ => default::parse_plain_attribute(self, name, value),
}
}
}
This pattern of specialization, trying to match the example at the beginning of
the post, almost works: if you call parse_plain_attribute
on an
HtmlAnchorElement
, you’ll get the correct behavior.
But if you’ve upcasted to an Element
or Node
, the behavior will revert to
the defaults for those types! That’s because you’re not getting dynamic
dispatch here, which for enums we said should go through match
.
The solution is to instead write the code as follows:
impl ParsePlainAttribute for Node {
default fn parse_plain_attribute(&self, name: &Atom, value: DomString) -> AttrValue {
AttrValue::String(value)
}
}
impl ParsePlainAttribute for Element {
default fn parse_plain_attribute(&self, name: &Atom, value: DomString) -> AttrValue {
match name {
&atom!("id") => AttrValue::from_atomic(value),
&atom!("class") => AttrValue::from_serialized_tokenlist(value),
_ => default::parse_plain_attribute(self, name, value),
}
}
}
impl ParsePlainAttribute for HtmlAnchorElement {
fn parse_plain_attribute(&self, name: &Atom, value: DOMString) -> AttrValue {
match name {
&atom!("rel") => AttrValue::from_serialized_tokenlist(value),
_ => default::parse_plain_attribute(self, name, value),
}
}
}
Note that we’re now using specialization without any explicit blanket
impls. In this proposal, when the Self
type is an enum, it’s as if you had
written a blanket impl like the ones above, except that when the function is
invoked on the enum type, it will use a match
to dispatch to most specialized
implementation. That is, it’s as if we’d written the following for Node
:
// Fully generic *default* impl
impl<T: Node> ParsePlainAttribute for T {
default fn parse_plain_attribute(&self, name: &Atom, value: DomString) -> AttrValue {
AttrValue::String(value)
}
}
// Specialized impl for the `Node` type itself
impl ParsePlainAttribute for Node {
fn parse_plain_attribute(&self, name: &Atom, value: DomString) -> AttrValue {
match *self {
// NOTE: `this` has a different type in each arm!
ref this@Node::HtmlAnchorElement => this.parse_plain_attribute(name, value),
ref this@Node::HtmlImageElement => this.parse_plain_attribute(name, value),
// ...
}
}
}
And of course:
- It’s nicer to write the impls directly against the enum type than using an explicit blanket;
- This is also almost certainly the behavior you wanted anyway: you always get the most specific impl, whether dynamically or statically dispatched.
But the desugaring only triggers when Self
is a direct enum type.
Getting opinionated
If you’ve stuck with me until this point, first of all: thanks! That was a long haul.
So, what should we do? To recap, we have two major routes, both of which start with specialization.
The first takes a minimalistic approach, adding a couple of minor (and independently motivated) features to traits and structs to get to our goal.
The second combines specialization with another major set of enhancements to enums, which are also independently motivated, but are much more complex. It then adds a bit of sugar on top to tie the two together.
Initially, I was very excited about the latter, enum-centric approach, because
the work on enum hierarchies seems like such a natural extension to Rust. But I
am worried about a few things. First of all, getting the proposal that Niko laid
out to work will require substantially reworking our type inference to account
for subtyping. Making this happen backwards-compatibly with our existing enums
is not going to be easy, and may not even be possible. It also makes subtyping
much more important in Rust, which is likely to be a complexity multiplier as
it interacts with every other aspect of the type system. There are also various
dark syntactic corners that come out of the partial unification of enums and
structs (e.g., how do you specify visibility of shared fields in an in-line
enum?) Finally, the key bit of sugar at the apex that ties enum hierarchies and
specialization together is a bit subtle, and only covers the most obvious cases
of Self
.
In short, I see a lot of known risks, and worry about unknown risks, with the enum hierarchy route.
In contrast, the struct/trait-centric proposals feel much less risky; they don’t introduce fundamental new complexity that interacts with the rest of the type system, and they have a smaller overall footprint. I also like the way that specialization is used very explicitly to get inheritance, rather than through a layer of sugar on top.
And of the struct proposals, I think that struct inheritance strikes the best balance between minimalism, flexibility, and “fit” with the existing language.
The main downside of my preferred struct/trait approach is that there’s some
amount of boilerplate: “abstract base classes” like Node
turn into a Node
trait and a NodeFields
struct. That detail could easily be hidden behind a
macro, but it might also argue in favor of the more complex traits-with-fields
variant.
If we do go with a struct/trait approach, I think we should carefully check
that the design is compatible with a future expansion of enums along the lines
Niko laid out in his post, since we may still want enum hierarchies in the long
run. I’ve given this a fair amount of thought, and likewise think that struct
inheritance is the best fit. In particular, it could replace the somewhat
magical proposal for “common fields” (which included an associated
MyEnum::struct
type).


The company I work for needed me to do an Heuristic Evaluation on a existing product. After some online research I came across some great usability testing ideas on Dribbble, but again these where just ideas and nothing available for download, nevermind resuable XD templates.
I decided to create an Adobe XD Heuristic Evaluation template. The Heruistics are based on Jakob Nielsen's 10 general principles for interaction design. This template could then be shared with the entire UX team, A resuable XD template that could be used to evaluate any website or application if needed within the company.
First I created the resuable XD wireframe components so they can be resused throughtout the project file.
Just a fancy cover for presentation.
These contain the resuable components:
Here you can see the wireframes in action, where I have used the files as a prototype to show existing issues linked back to the original pages


|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object org.newdawn.slick.util.InputAdapter
public class InputAdapter
An implement implementation of the InputListener interface
| Constructor Summary | |
|---|---|
InputAdapter()
|
| Method Summary | |
|---|---|
void |
controllerButtonPressed(int controller,
int button)
Notification that a button control has been pressed on the controller. |
void |
controllerButtonReleased(int controller,
int button)
Notification that a button control has been released on the controller. |
void |
controllerDownPressed(int controller)
Notification that the down control has been pressed on the controller. |
void |
controllerDownReleased(int controller)
Notification that the down control has been released on the controller. |
void |
controllerLeftPressed(int controller)
Notification that the left control has been pressed on the controller. |
void |
controllerLeftReleased(int controller)
Notification that the left control has been released on the controller. |
void |
controllerRightPressed(int controller)
Notification that the right control has been pressed on the controller. |
void |
controllerRightReleased(int controller)
Notification that the right control has been released on the controller. |
void |
controllerUpPressed(int controller)
Notification that the up control has been pressed on the controller. |
void |
controllerUpReleased(int controller)
Notification that the up control has been released on the controller. |
void |
inputEnded()
Notification that all input events have been sent for this frame |
void |
inputStarted()
Notification that input is about to be processed |
boolean |
isAcceptingInput()
Check if this input listener is accepting input |
void |
keyPressed(int key,
char c)
Notification that a key was pressed |
void |
keyReleased(int key,
char c)
Notification that a key was released |
void |
mouseClicked(int button,
int x,
int y,
int clickCount)
Notification that a mouse button was clicked. |
void |
mouseDragged(int oldx,
int oldy,
int newx,
int newy)
Notification that mouse cursor was dragged |
void |
mouseMoved(int oldx,
int oldy,
int newx,
int newy)
Notification that mouse cursor was moved |
void |
mousePressed(int button,
int x,
int y)
Notification that a mouse button was pressed |
void |
mouseReleased(int button,
int x,
int y)
Notification that a mouse button was released |
void |
mouseWheelMoved(int change)
Notification that the mouse wheel position was updated |
void |
setAcceptingInput(boolean acceptingInput)
Indicate if we should be accepting input of any sort |
void |
setInput(Input input)
Set the input that events are being sent from |
| Methods inherited from class java.lang.Object |
|---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Constructor Detail |
|---|
public InputAdapter()
| Method Detail |
|---|
public void controllerButtonPressed(int controller, int button)
ControllerListener
controllerButtonPressed
in interface ControllerListener
controller
- The index of the controller on which the control
was pressed.button
- The index of the button pressed (starting at 1)ControllerListener.controllerButtonPressed(int, int)
public void controllerButtonReleased(int controller, int button)
ControllerListener
controllerButtonReleased
in interface ControllerListener
controller
- The index of the controller on which the control
was released.button
- The index of the button released (starting at 1)ControllerListener.controllerButtonReleased(int, int)
public void controllerDownPressed(int controller)
ControllerListener
controllerDownPressed
in interface ControllerListener
controller
- The index of the controller on which the control
was pressed.ControllerListener.controllerDownPressed(int)
public void controllerDownReleased(int controller)
ControllerListener
controllerDownReleased
in interface ControllerListener
controller
- The index of the controller on which the control
was released.ControllerListener.controllerDownReleased(int)
public void controllerLeftPressed(int controller)
ControllerListener
controllerLeftPressed
in interface ControllerListener
controller
- The index of the controller on which the control
was pressed.ControllerListener.controllerLeftPressed(int)
public void controllerLeftReleased(int controller)
ControllerListener
controllerLeftReleased
in interface ControllerListener
controller
- The index of the controller on which the control
was released.ControllerListener.controllerLeftReleased(int)
public void controllerRightPressed(int controller)
ControllerListener
controllerRightPressed
in interface ControllerListener
controller
- The index of the controller on which the control
was pressed.ControllerListener.controllerRightPressed(int)
public void controllerRightReleased(int controller)
ControllerListener
controllerRightReleased
in interface ControllerListener
controller
- The index of the controller on which the control
was released.ControllerListener.controllerRightReleased(int)
public void controllerUpPressed(int controller)
ControllerListener
controllerUpPressed
in interface ControllerListener
controller
- The index of the controller on which the control
was pressed.ControllerListener.controllerUpPressed(int)
public void controllerUpReleased(int controller)
ControllerListener
controllerUpReleased
in interface ControllerListener
controller
- The index of the controller on which the control
was released.ControllerListener.controllerUpReleased(int)
public void inputEnded()
ControlledInputReciever
inputEnded
in interface ControlledInputReciever
ControlledInputReciever.inputEnded()
public boolean isAcceptingInput()
ControlledInputReciever
isAcceptingInput
in interface ControlledInputReciever
ControlledInputReciever.isAcceptingInput()
public void setAcceptingInput(boolean acceptingInput)
acceptingInput
- True if we should accept inputpublic void keyPressed(int key, char c)
KeyListener
keyPressed
in interface KeyListener
key
- The key code that was pressed (@see org.newdawn.slick.Input)c
- The character of the key that was pressedKeyListener.keyPressed(int, char)
public void keyReleased(int key, char c)
KeyListener
keyReleased
in interface KeyListener
key
- The key code that was released (@see org.newdawn.slick.Input)c
- The character of the key that was releasedKeyListener.keyReleased(int, char)
public void mouseMoved(int oldx, int oldy, int newx, int newy)
MouseListener
mouseMoved
in interface MouseListener
oldx
- The old x position of the mouseoldy
- The old y position of the mousenewx
- The new x position of the mousenewy
- The new y position of the mouseMouseListener.mouseMoved(int, int, int, int)
public void mousePressed(int button, int x, int y)
MouseListener
mousePressed
in interface MouseListener
button
- The index of the button (starting at 0)x
- The x position of the mouse when the button was pressedy
- The y position of the mouse when the button was pressedMouseListener.mousePressed(int, int, int)
public void mouseReleased(int button, int x, int y)
MouseListener
mouseReleased
in interface MouseListener
button
- The index of the button (starting at 0)x
- The x position of the mouse when the button was releasedy
- The y position of the mouse when the button was releasedMouseListener.mouseReleased(int, int, int)
public void mouseWheelMoved(int change)
MouseListener
mouseWheelMoved
in interface MouseListener
change
- The amount of the wheel has movedMouseListener.mouseWheelMoved(int)
public void setInput(Input input)
ControlledInputReciever
setInput
in interface ControlledInputReciever
input
- The input instance sending eventsControlledInputReciever.setInput(org.newdawn.slick.Input)
public void mouseClicked(int button, int x, int y, int clickCount)
MouseListener
mouseClicked
in interface MouseListener
button
- The index of the button (starting at 0)x
- The x position of the mouse when the button was pressedy
- The y position of the mouse when the button was pressedclickCount
- The number of times the button was clickedMouseListener.mouseClicked(int, int, int, int)
public void mouseDragged(int oldx, int oldy, int newx, int newy)
MouseListener
mouseDragged
in interface MouseListener
oldx
- The old x position of the mouseoldy
- The old y position of the mousenewx
- The new x position of the mousenewy
- The new y position of the mousepublic void inputStarted()
ControlledInputReciever
inputStarted
in interface ControlledInputReciever
ControlledInputReciever.inputStarted()
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


---
layout: default
title: PostgreSQL JDBC Driver
resource: media
nav:
---
{{ post.date | date_to_long_string }}
See full changelog for {{ post.version}}
The PostgreSQL JDBC group would like to thank YourKit
for graciously providing licenses to the project.


As of Java 1.6 a Java compiler API is exposed to end developers and included in any JDK, in a standard Java EE web environment the compiler is accessible because the JDK is needed to recompile on the fly for instance JSPs
This opens the opportunity to make a hot class reload based on pure Java source code in a similar way to other dynamic languages... fast and avoiding the tedious context reload
RelProxy is a Java and Groovy hot class reloader library, in spite of it is a general purpose tool it was conceived to provide hot class reload to ItsNat.
This page is rendered by (compiled) Java source code included in the standard WAR file, of course into the WEB-INF folder if you need privacy of your code, this Java code can be modified and will be compiled and reloaded on the fly, reload the page and the new code will be executed.
Note: try changing the source code in runtime (template and Java code) to modify the behavior of this example and reload this page
The class JProxy
is a Java class to provide a simple proxy for conventional Java objects,
When JProxy
is used, a java.lang.reflect.Proxy
is passed instead of the original Java object, the original Java object is retained
under the hood and method calls to the proxy are redirected to the real object
calling the corresponding method using reflection, when the source code of the Java(s) class(es) changes.
JProxy
automatically reloads the Java class and creates a new object to replace the old one, the fields of the original object are got and re-set to the new
object to keep the state (number of fields and types must be the same otherwise reloading is not possible and a redeploy is required).
JProxy
part of RelProxy is not so sophisticated like products like JRebel but it could dramatically reduce the number of redeploys in an ItsNat project.
With a simple boolean enabled
param set to false in initialization time, JProxy
does nothing and your original objects are returned instead of proxies
with 0 performance penalty in production. If you still want to make hot changes in production, automatic detection of source code changes can be stopped to reduce footprint in production and started again in any time when we want make
source code changes.
JProxy
can easily be applied to an ItsNat project to provide a proxy instead of the original Java object when registering an
ItsNatServletRequestListener
associated to a page template. When a document (page) is loaded calling processRequest
, JProxy
re-creates
this listener object if the source code of this object or any other dependent class has changed, and re-set all fields to restore the current state.
Field values injected to the class implementing ItsNatServletRequestListener
are not (and must not be) reloaded to the new possible source, but cascade dependent classes usually creating
new objects are automatically reloaded when executing processRequest
, any new object created by processRequest
is fresh with the last source and because registering in framework ItsNat classes
happens after reloading no JProxy
is needed.
This solution is not perfect because only affects to view-logic (not to classes of global objects provided to ItsNatServletRequestListener
page loaders), that is,
code for ItsNatDocument
processing, anyway this is very much code.
This is an example of using a JProxy
when registering a ItsNatServletRequestListener
associated to a template for document loading:
ItsNatServletRequestListener listener = JProxy.create(new JProxyExampleLoadListener(db), ItsNatServletRequestListener.class); docTemplate.addItsNatServletRequestListener(listener);
For instance change JProxyExampleDocument
and jproxyex.html
to change view logic, and reload this page, no redeploy is needed, no servlet context is reloaded, only Java classes are reloaded.
The class JProxyExampleDocument
contains an inner class, a member class (AuxMember
) and using an external class JProxyExampleAux
, change these classes with no problem.
You can change also JProxyExampleLoadListener
for instance to change the parameters provided to JProxyExampleDocument
but do not add/remove/change its fields because this is the root class and instance
managed by JProxy
in this example and classes of the fields cannot be reloaded, for instance changes to FalseDB
(a field of JProxyExampleDocument
)
are not automatically reloaded because FalseDB
is not in the folder for class reload and trying to reload this class implies a field of JProxyExampleLoadListener
has changed and reloading this class will fail.
In production time Java app servers usually extract deployed war files to internal folders, you can modify sources there.
No more explicit JProxy.create() sentences, just configure RelProxy and your ItsNatServletRequestListener
and EventListener
listeners will be
automatically reloadable if they are contained by reloadable classes! Read the ItsNat Manual for more info about RelProxy support.


Conference Presenter
Written and delivered presentations, speaking in front of groups of between ten and fifty people and fielding questions.
Written and delivered presentations, speaking in front of groups of between ten and fifty people and fielding questions.
Composed constitution, administered the election to ratify it, and served as its first chairperson


import com.sleepycat.db.*;public void set_mp_size(long mp_size);
Set the suggested size of the shared memory buffer pool, i.e., the cache, in bytes. This should be the size of the normal working data set of the application, with some small amount of additional memory for unusual situations. (Note, the working set is not the same as the number of simultaneously referenced pages, and should be quite a bit larger!) The value specified may not be less than 20K bytes. If no value is specified, the default is 128K bytes (16 8K byte pages).


Localhost Dev Mode
Everyone codes in an isolated way.
- Hard to develop large applications with limited local resources
- Difficult to setup and maintain the development environment
- Difficult to debug jointly
- Gap bewteen development environment and production envrionment
Nocalhost Dev Mode
With Nocalhost DevMode, all services can run on the Cloud. DevMode supports connecting local IDE and containers.
- Easy to handle large application development with flexible cloud resources
- Environment provisioning on demand
- Easy to share the same development environment and conduct joint debugging
- Close to production environment


/* Example 01 Programming in HCPL. In this example it is shown how to write programs in HCPL. This does not cover the whole language. In particular, macros are not covered. Proving theorems is covered in succeeding examples. */ /* The above and the present texts are multi-line comments. */ // This is a single-line comment /* A very simplified and not-fully-correct grammar of the language: <program> ::= <statement> [[;] <program>] <statement> ::= <let> | <directive> | <expr> | <empty> <let> ::= let <ident> = <expr> <expr> ::= <term> [<expr>] <term> ::= <lambda> | <if> | <match> | <number> | <placeholder> | ( <program> ) | { <program> } | $. <expr> | $.. <program> <lambda> ::= \<ident> <term> | \<ident> . <expr> | \<ident> .. <program> <if> ::= if <expr> then <expr> else <expr> <match> ::= match <expr> with [|] <match-branches> <match-branches> ::= <expr> -> <program> [| <match-branches>] <placeholder> ::= %<ident> <directive> is one of the interpreter directives for defining new operators or importing definitions from modules <empty> signifies lack of tokens. It denotes a `nil' value -- the same as `()'. So e.g. `p;' is the same as `p;()' and its value is `()', not `p'. */ /* The following defines a function `power'. `let' is recursive by default. The only way of defining functions is by lambda-abstraction (\x (...)). Functions are untyped. The logic introduced in further examples allows reasoning about function types. */ let power = \a \b { if (b != 0) then { let pom = \ta \tb \b { if b > 1 then pom (ta * ta) (if b mod 2 != 0 then tb * ta else tb) (b div 2) else ta * tb }; /* Notice the semicolon. A semicolon acts as a separator between statements. Without it `pom' would be defined recursively as an application: let pom = (\ta ...) pom a 1 b */ pom a 1 b } else { 1 } }; print (power 3 4); // prints 81 print (power 2 16); // prints 65536 print (power 5 7); // prints 78125 // Evaluation in HCPL is eager by default, but this should not be relied on. /* The brackets {} and () are used to embrace expressions so that they will be treated as single terms. Brackets introduce a new scope for identifiers. The body of a lambda-abstraction is a single term (see the grammar). E.g. `\x x a' is the same as `(\x x) a', not `\x (x a)', so brackets are often necessary. There is no difference between {} and () except visual. There is a second form of lambda-expression: \x . (dot after \x) which extends as far right as possible for an expression (see the grammar). */ { let o = \f \g \x . f (g x); let f = \x . x + 1; let g = \x . x * 2; syntax operator o is left, binary, after appl; // This defines `o' to be a binary, left-associative operator, // with priority just after application (so higher than the priority // of any operator defined thus far with priority lower than application) // See lib/core.ipl for more examples of operator definitions. print $. (f o g) 3; // prints 7 print << (f o g) $. 3; // prints 7 // << is the same as $. but is left-associative and has lower priority } // We had to put the above in {} to introduce a new scope, because `o' is actually predefined // and redefining it in the global scope would produce a name clash. /*****************************************************************************/ /* The following shows the use of lists and matching. */ let filter = \f \lst { match lst with | %h :: %t when f h -> h :: filter f t | %_ :: %t -> filter f t | [] -> [] } // Note we omitted `;' here. // The separator `;' is optional in situations where the ensuing token cannot be // interpreted as a start of a term (in the simplified grammar above `let' starts // a statement). let sum = \lst { let aux = \lst \acc { match lst with | %h :: %t -> aux t (acc + h) | [] -> acc }; aux lst 0 }; // Note we cannot omit `;' here, because `filter' may be interpreted as a term filter (\x . x > 0) [-1, 0, 10, 11, -5, -16, 12] >> sum >> print; // prints 33 // >> is left-associative and defined as: \x \y (y x) // In general, see lib/core.ipl for definitions of many standard operators. /* The patterns in `match' are not static like in e.g. ML. They are first evaluated before the matching takes place. The identifiers prefixed with `%' name placeholders in patterns -- special objects which are treated as constants by the evaluator. The effects are undefined if a placeholder gets duplicated by an evaluation of a pattern. Non-static patterns make e.g. the following valid. */ let data = \x (`data, x); let get-datum = \d { match d with | data %x -> x | %_ -> error "expected a data object" }; print << get-datum $. data 6; // prints 6 // `sym denotes a `symbol' named `sym -- a constant object which is equal (==) only to itself // Symbols may also be declared with the `symbol' directive. symbol mysym; print (mysym == `mysym); // prints false // Actually, (x, y), (x :: y) and (cons x y) are all equivalent. // [x, y, z] is a shorthand for (x, y, z, ()). // The comma is a right-associative operator creating a pair. /*****************************************************************************/ /* The following shows how quoting works. */ let factorial = \n . if n == 0 then 1 else n * factorial (n - 1); print << factorial 5; // prints 120 print << '(factorial 5); // prints '(factorial 5) print << eval '(factorial 5); // prints 120 // The quote operator ' quotes the term following it. // It indicates that this term is not to be evaluated, but treated as a data // structure. The quote operator actually changes the interpretation of // the following tokens as read by the parser. The identifiers inside // a quoted expression are resolved statically (lexically). At the evaluation // stage, when the data structure representing the expression being quoted is // being created, if an identifier denotes a quoted value then this value is pasted // in the place of the identifier, if it denotes a non-quoted value (i.e. one that // is not a data structure representing a term) then this value is first quoted -- // for this to make sense the value denoted by the identifier must be constant in // this second case. let qf = 'factorial; // `qf' is different from `factorial' -- it is a data structure representing this // function, not the function itself print ('(qf 5) == '(factorial 5)); // prints: true print << reduce $. '(factorial 5); // prints: '(5 * (factorial 4)) // Some basic data values (e.g. numbers and symbols) when quoted are represented by // themselves. This is OK because they are in normal form, i.e. they evaluate // to themselves. print '5; // prints 5 print '(`abba); // prints `abba print 'true; // prints true print ('true == true); // prints true


List of tasks scheduled and upcoming tasks
Schedule storage and retrieval tasks
Region list:
Bot Details:
Legend:
Balance
| Balance more than Minimum by more than 1 Fil | Balance more than Minimum by less than 1 Fil | Balance less than Minimum |
DataCap
| DataCap more than Minimum by more than 32 GB | DataCap more than Minimum by less than 32 GB | DataCap less than Minimum | DataCap & Minimum are both zero (unverfied dealbot) |
Create a new bot


My Home
1.
You don't have any Apps at the moment.
Press here to begin.
Manage Apps
2.
To add an App.
Press here.


Friends in Database:
{% for record in friendsList %}
{{record['first_name']}} {{record['last_name']}} {{record['occupation']}} {{record['first_name']}}
{% endfor%}
First Name:
Last Name:
Occupation:


| Overview | Module | Use | Devguide | Index |
| Services' Summary | Interfaces' Summary | Properties' Summary | Services' Details | Interfaces' Details | Properties' Details |
| service LineProperties |
|
| Properties' Summary | |
| LineStyle LineStyle |
This property contains the type of the line. |
| LineDash LineDash |
This property contains the dash of the line. |
| string LineDashName |
[ OPTIONAL ] This property contains the name of the dash of the line. |
| ::com::sun::star::util::Color LineColor |
This property contains the line color. |
| short LineTransparence |
This property contains the extent of transparency. |
| long LineWidth |
This property contains the width of the line in 1/100th mm. |
| LineJoint LineJoint |
This property defines the rendering of joints between thick lines |
| LineCap LineCap |
[ OPTIONAL ] This property defines the rendering of ends of thick lines |
| string LineStartName |
[ OPTIONAL ] This property contains the name of the line start poly polygon bezier. |
| string LineEndName |
[ OPTIONAL ] This property contains the name of the line end poly polygon bezier. |
| PolyPolygonBezierCoords LineStart |
[ OPTIONAL ] This property contains the line start in the form of a poly polygon bezier. |
| PolyPolygonBezierCoords LineEnd |
[ OPTIONAL ] This property contains the line end in the form of a poly polygon bezier. |
| boolean LineStartCenter |
[ OPTIONAL ] If this property is true, the line will start from the center of the polygon. |
| long LineStartWidth |
[ OPTIONAL ] This property contains the width of the line start polygon. |
| boolean LineEndCenter |
[ OPTIONAL ] If this property is true, the line will end in the center of the polygon. |
| long LineEndWidth |
[ OPTIONAL ] This property contains the width of the line end polygon. |
| Properties' Details | |
LineStyle
|
|
LineDash
|
|
LineDashName
|
|
LineColor
|
|
LineTransparence
|
|
LineWidth
|
|
LineJoint
|
|
LineCap
|
|
LineStartName
|
|
LineEndName
|
|
LineStart
|
|
LineEnd
|
|
LineStartCenter
|
|
LineStartWidth
|
|
LineEndCenter
|
|
LineEndWidth
|
Copyright © 2013, The Apache Software Foundation, Licensed under the Apache License, Version 2.0. Apache, the Apache feather logo, Apache OpenOffice and OpenOffice.org are trademarks of The Apache Software Foundation. Other names may be trademarks of their respective owners.


{% extends '_base.html' %} {% block content %} Go to players list + New player
Do you really want to delete "{{ sport.player_name }} from the list"?


This website is a collection of information on architectural styles, construction methods, buildings types and other information based on this Google Sheet.
This website was created by Eli Pousson for the Local Preservation School and is based on the Federal Government 2017 project by Jessica Lord.


John proposed on a hike to Tamawanas Falls at the base of Mt Hood on a road trip back from spending Christmas in the Bay Area. When we got to the falls, there was another proposal being set up, replete with twinkle lights, a wooden arch, and rose petals scattered on the ground. Not wanting to crash someone else's well-laid plans, John thought "soft pass" and waited until he and Kari were almost back at the car before he pulled her down on the banks of a creek near the trail head and popped the question. As they say, the rest is history.


These release notes cover new developer and user-facing incompatibilities, important issues, features, and major improvements.
This jira adds a new DataNode state called “stale” at the NameNode. DataNodes are marked as stale if it does not send heartbeat message to NameNode within the timeout configured using the configuration parameter “dfs.namenode.stale.datanode.interval” in seconds (default value is 30 seconds). NameNode picks a stale datanode as the last target to read from when returning block locations for reads.
This feature is by default turned * off *. To turn on the feature, set the HDFS configuration “dfs.namenode.check.stale.datanode” to true.
WARNING: No release note provided for this change.
A map-task’s syslogs now carries basic info on the InputSplit it processed.
This jira adds a new metric with name “StaleDataNodes” under metrics context “dfs” of type Gauge. This tracks the number of DataNodes marked as stale. A DataNode is marked stale when the heartbeat message from the DataNode is not received within the configured time "“dfs.namenode.stale.datanode.interval”.
Please see hdfs-default.xml documentation corresponding to "“dfs.namenode.stale.datanode.interval” for more details on how to configure this feature. When this feature is not configured, this metrics would return zero.
Add a JSONP alternative outpout for /jmx HTTP interface to provide a Javascript polling ability in browsers.
Speed up Crc32 by improving the cache hit-ratio of hadoop.util.PureJavaCrc32
Handle TaskAttempt diagnostic updates while in the NEW and UNASSIGNED states.
The change from this jira changes the content of some of the log messages. No log message are removed. Only the content of the log messages is changed to reduce the size. If you have a tool that depends on the exact content of the log, please look at the patch and make appropriate updates to the tool.
“test” will not print a warning for non-existent paths when testing for existence
Add a separate logger “BlockStateChange” for block state change logs.
The RPC SASL negotiation now always ends with final response. If the SASL mechanism does not have a final response (GSSAPI, PLAIN), then an empty success response is sent to the client. The client will now always expect a final response to definitively know if negotiation is complete/successful.
Allow ReduceTask loading a third party plugin for shuffle (and merge) instead of the default shuffle.
MAPREDUCE-4807 Allow external implementations of the sort phase in a Map task
Update FileStatus.toString to include missing fields
WARNING: No release note provided for this change.
Patches adds more tests to verify overwritten and more complex operations -write-delete-overwrite. By using differently sized datasets and different data inside, these tests verify that the overwrite really did take place. While HDFS meets all these requirements directly, eventually consistent object stores may not -hence these tests.
Resolved as part of HADOOP-9119 -it’s test data generator creates more bits in every test byte
Member dataEncryptionKey of the protobuf message GetDataEncryptionKeyResponseProto is made optional instead of required. This is incompatible change is not likely to affect the existing users (that are using HDFS FileSystem and other public APIs).
Protobuf message GetLinkTargetResponseProto member targetPath is made optional from required so that null values can be passed over the wire. This is an incompatible wire protocol change and does not affect the API backward compatibility.
Protobuf message GetBlockKeysResponseProto member keys is made optional from required so that null values can be passed over the wire. This is an incompatible wire protocol change and does not affect the API backward compatibility.
Protobuf message GetDelegationTokenRequestProto field renewer is made requried from optional. This change is not wire compatible with the older releases.
The default group mapping policy has been changed to JniBasedUnixGroupsNetgroupMappingWithFallback. This should maintain the same semantics as the prior default for most users.
This jira introduces a new configuration parameter “ipc.client.connect.timeout”. This configuration defines the Hadoop RPC connection timeout in milliseconds for a client to connect to a server. For details see the description associated with this configuration in core-default.xml.
The HDFS implementation of getFileChecksum() can now operate correctly against earlier-version datanodes which do not include the checksum type information in their checksum response. The checksum type is automatically inferred by issuing a read of the first byte of each block.
This is an incompatible change from release 2.0.2-alpha and prior releases. Balancer tool exited with exit code 1 on success. It is changed to exit with exit code 0 on success. Non 0 exit code indicates failure.
This patch makes an incompatible configuration change, as described below: In releases 1.1.0 and other point releases 1.1.x, the configuration parameter “dfs.namenode.check.stale.datanode” could be used to turn on checking for the stale nodes. This configuration is no longer supported in release 1.2.0 onwards and is renamed as “dfs.namenode.avoid.read.stale.datanode”.
How feature works and configuring this feature: As described in HDFS-3703 release notes, datanode stale period can be configured using parameter “dfs.namenode.stale.datanode.interval” in seconds (default value is 30 seconds). NameNode can be configured to use this staleness information for reads using configuration “dfs.namenode.avoid.read.stale.datanode”. When this parameter is set to true, namenode picks a stale datanode as the last target to read from when returning block locations for reads. Using staleness information for writes is as described in the releases notes of HDFS-3912.
WARNING: No release note provided for this change.


| drum-78 | |
| bass | snare |
| closed hh | open hh |
| OH |
| CH |
| SD |
| BD |
| blue planet | |
| osc mix | |
| attack | decay |
| sustain | release |
| cutoff | resonance |
| E |
| D# |
| D |
| C# |
| C |
| B |
| A# |
| A |
| G# |
| G |
| F# |
| F |
| E |
| baseline | |
| attack | decay |
| cutoff | resonance |
| SEQ-WWW | |
| PLAY | STOP |
| tempo | |
| Mix | EQ | Compressor |
| drums | highpass | ratio |
| poly | midrange | attack |
| bass | lowpass | release |
| threshold | ||
SEQ-WWW was made by @chriseberly


{% extends "base.html" %} {% block title %}
Medieval catalogues > AUGUSTINIAN CANONS > Lanthony > Catalogue, late 14th cent.
{% endif %}512 identified entries found.
All data was derived from the List of Identifications by Professor Richard Sharpe.
{% if not printing %}
A key to codes used in the List is available (opens in new tab).{% endif %}


Train the trainer day
Cool Cytoscape Workshop - Cologne
29 November 2017
Maria Sorokina
- Postdoctoral researcher at the CECAD, University of Cologne, Germany
- Computational systems biologist + chemoinformatician
- Structural bioinformatician wannabe
- I love enzymes
- Active Cytoscape user


There are eleven growth stages for Spring Wheat and they are identical to those for Winter Wheat but without the overwintering period and the 'Jan 1 to Single Ridge ' stage. A description of the growth stages follows:
Seeding to Emergence (E) - germination occurs and the coleoptile pushes through to the soil surface. The first true leaf pushes and then emerges from the tip resulting in emergence.
E to First Tiller - the first tiller emerges.
E to Single Ridge (SR ) - Single Ridge occurs when the shoot apex first elongates. Subsequent leaf primordia cease further development and they form a single ridge around the apex.
SR to Double Ridge (DR ) - the tissue between the single ridges develop into spikelet primordia which is the double ridge stage.
DR to Terminal Spikelet (TS) - spikelet primordia continue to be initiated with the terminal spikelet primordium formed just before Jointing .
TS to Jointing (J) - the head is fully formed and can be seen inside the stem if the stem is cut open. The stem then begins elongating and jointing occurs when the first node is visible just above the soil line or at the base of the shoot.
J to Flag Leaf Complete (FLC ) - the flag leaf is the last leaf to emerge from the whorl and is completely emerged when the leaf's ligule is visible. It encloses the head and this is referred to as booting or Flag Leaf Complete.
FLC to Heading (H) - the head is pushed out of the flag leaf sheath resulting in heading.
H to Anthesis Starts (AS ) - the head is beginning to flower or pollinate. Anthers are visible at this stage and extruded from the florets . Pollination occurs beginning with the florets in the central spikelets. Flowering then progresses up and down the wheat spike .
AS to Maturity (M) - once pollination has occurred, the kernels progress through three phases of growth during grain filling . The first is the "watery ripe " and "milk " stages. Then the "soft dough " phase occurs followed by the "hard dough " phase as the kernel approaches maturity. The kernels continue to lose moisture throughout grain filling until they reach 30-40% at physiological maturity . The head and peduncle lose their green color by the time the plant is at maturity.
M to Harvest Ready - the kernels continue to lose moisture and should be harvested when they are at 13 - 14% moisture.
The Back... button will take you back to the previous screen .
The Help... button opens a screen displaying help for this screen.
The Variety drop down list displays the available selections of Spring Wheat varieties in a general sense based on number of leaves . There are five varieties and include 7-Leaved, 8-Leaved which is equivalent to Generic , 9-Leaved, 10-Leaved, and >10-Leaved.
The Run ... button executes the program with the selections that have been chosen.
The Reset button sets all the values in the columns back to their original, default values.
Links to the Phenology Diagram and the Developmental Sequence for Spring Wheat.


In 2015, Na Maka Kindergarten Prep School was established to give children a head start in education. Here, we are dedicated to prepare every child to enter kindergarten with the skills needed for high achievements and the future. Language techniques including reading and writing, math exploration, inquiry, social and cognitive skills, creative movement, music, and fine arts will be implemented in the course. This well-rounded institution is provided to ensure excellence in anyone who is enrolled.
Please let us know if you would like to enroll your child for our summer session or next school year. The enrollment form and your $100 non-refundable deposit are due by December 1, 2016. Due to our waitlist for the 2017-2018 school year, we will be filling
our spaces available on a first come first serve basis (starting from the top of the list). There are currently 15 spaces available for the following summer and school year. Forms and payment can be dropped off at Na Maka K Prep during operation
hours Monday-Friday from 6:00 a.m.-5:00 p.m. to reserve your child's spot. Mahalo and have a great day!
Mandi Scott
Director/Co-owner


{% extends "base.html" %} {% block content %} Manually create scorecards View psych sheet for a competition {% endblock %}


Handling Exceptions and Other Errors with the Python SDK in Couchbase
All Couchbase exceptions are derived from CouchbaseError
.
Exceptions may be caught via except
.
You may catch specific exceptions for specific handling, or you may catch the CouchbaseError
and handle exceptions based on their status codes.
Note that a single error may be part of multiple categories.
CouchbaseDataError
This error category is raised when there is a data logic error (for example, a missing document ID). Handling of this error depends on application logic (for example, either perform corrective action to insert the document, or return an error up the stack indicating the specified resource does not exist).
ArgumentError
This type of exception is thrown during argument/input validation. It indicates that one or more arguments passed to a method are invalid. You should determine how and why the application is passing invalid input to the SDK
CouchbaseNetworkError and CouchbaseTransientError
This error category indicates a connectivity issue between the SDK and the Couchbase Cluster. This error might be a result of a temporary condition or a systematic infrastructure failure.
TimeoutError
and NetworkError
are subclasses of these error types.
Anatomy of an Exception Object
The Python SDK makes full use of the fact that a Python exception is just an object. In addition to catching the exception itself, the exception object may be analyzed for more information regarding the failure, and in the case of batched operations, may be inspected to determine which operations failed and which succeeded.
Applications may use the is_data
property on a CouchbaseError
instance to determine if the error is a negative reply from the server; the property will evaluate to True
for situations where a key is not found, already exists, and so on.
Likewise applications may use the is_network
property to determine if the exception is a result of a potential network issue (and is thus not an issue with the data, but rather an issue concerning the connectivity between client and server).
All exceptions which are either data errors or network errors will contain a non-zero status code from the underlying C library; this status code may be obtained using the rc
property of the exception.
Exceptions which contain an rc
value of 0 are typically ArgumentErrors
which are thrown when a method was supplied with an invalid parameter, or an invalid combination of parameters.
Handling Errors from Multi Operations
When executing multiple operations in a _multi
methods (for example, Bucket.get_multi()
), some of those operations will fail and an exception will be raised.
Some operations may have still succeeded, and in this case you need to inspect the exception object to see which operations failed and which succeeded using the CouchbaseError.split_results
try:
cb.get_multi(keys)
except CouchbaseError as e:
ok, fail = e.split_results()
for k, v in fail.items():
print 'Key {0} failed with error code {1}'.format(k, v.rc)
for k, v in ok.items():
print 'Retrieved {0} with value {1}'.format(k, v.value)
Converting Error Codes to Exception Objects
In cases where exceptions are not raised but the operation fails, you may receive an error code which is the status code returned by the C SDK.
The Python SDK will not automatically convert the error code to an exception object for performance reasons.
You can use the CouchbaseError.rc_to_exctype
class method to get the exception class which would have been raised based on the error code.
Note that an error code of 0 means success.
Data Errors
Data errors are errors returned by the server because a certain data condition was not met. Data errors typically have very clear corrective paths.
Document Does not Exist
If a document is not found, then it has either not yet been created or has since been deleted. It is received on retrieval (get) operations (get a document), replace operations (replace a document that already exists), and remove operations (delete a document).
If this error is received when attempting to retrieve a document, then the item should either be created (if possible) or return an error to the user.
If this error is received when replacing a document, then it indicates an issue in the application state (perhaps you can raise an exception up the stack). If you do not care that the document exists, the upsert method may be used instead which ignores this case.
If receiving this error when removing an document, it may safely be ignored: not-found on remove essentially means the item is already removed.
The Not Found error is returned by the server.
Document Already Exists
The insert operation requires that the document does not exist yet; it is intended to create a new unique record (think about inserting a "new user ID"). This error is returned by the server when a document already exists. Applications at this point should probably return an error up the stack to the user (when applicable); for example indicating that a new account could not be registered with the given user name, since it already exists.
CAS Mismatch
A CAS mismatch error is returned when an operation was executed with a CAS value (supplied by the application) and the CAS value passed differs from the CAS value on the server. The corrective course of action in this case is for the application to re-try the read-update cycle as explained in detail in the CAS documentation.
Document too Big
If the maximum content size is larger than 20MB the server responds with an error noting that it can’t store it since it is too big. This error is not transient and must be raised up the stack since it likely indicates an application error that creates too large document contents.
Transient and Resource Errors
These errors may be received because of resource starvation.
Temporary Failure
This error is received when the server is temporarily inhibiting an error that doesn’t allow it to respond successfully. For example during mutations when the cluster node has run out of memory or is currently warming up. Its disk and replication queues are full and must wait until items in those queues are stored and replicated before it can begin receiving new operations.
While this condition is rare, it may happen under massively concurrent writes from clients and a limited memory allocation on the server.
The short-term corrective action for this error is to throttle and slow down the application, giving Couchbase some time for pending operations to complete (or to complete warmup) before issuing new operations. The long term corrective action is to increase memory capacity on the cluster, either by adding more RAM to each node, or by adding more nodes. The above example shows (in pseudo-code) how to handle a temporary failure error with a linear backoff.
MAX_RETRIES = 5
BASE_DELAY = 50 // milliseconds
current_attempts = 1
do {
try {
bucket.upsert(id, document)
break
} catch (TemporaryFailure error) {
sleep(BASE_DELAY * current_attempts)
}
} while (++current_attempts != MAX_RETRIES)
Out Of Memory
This error indicates a severe condition on the server side and probably needs to be logged and/or signaled to monitoring systems. There is not much the application can do there to mitigate the situation other than backing off significantly and waiting until the server side memory shortage is resolved.


Earnings fall at Exxon, Chevron on lower oil prices
NEW YORK, Nov 1 — US oil giants Exxon Mobil and Chevron reported a drop in their third-quarter profits today on lower oil prices, even as increased investment in US shale projects boosted output.
The companies have pumped heavy investment into the Permian Basin, a shale-rich region in Texas and New Mexico drawing considerable interest due to newer technologies that have made developing unconventional shale resources profitable.
These efforts enabled Exxon and Chevron, the two biggest US oil companies, to increase overall oil and gas production in the quarter ending September 30.
But results were dented by a retreat in crude oil prices during the three-month period, as signs of a slowing global economy amplified worries about a glut of supply.
US oil prices traded in the US$50-US$60 (RM208-RM250) a barrel range for much of the quarter, down about US$15 from the prior year.
Exxon reported quarterly profits of US$3.2 billion, plunging 49.2 per cent from the year-ago period, as revenues fell 15.1 per cent to US$65 billion.
Chief Executive Darren Woods said the company’s ramp-up in the Permian was running ahead of schedule, saying “we are making excellent progress on our long-term growth strategy.”
At Chevron, net profits were US$2.6 billion, which was 36.2 per cent below the same period of 2018. Revenues were US$36.1 billion, a 17.9 per cent decline.
“Third quarter earnings and cash flow were solid, but down from our very strong results of a year ago,” said Chevron Chief Executive Michael Wirth.
“Lower crude oil and natural gas prices more than offset a three per cent increase in net oil-equivalent production from last year’s third quarter.”
Exxon shares rose 0.6 per cent to US$68.00 in pre-market trading, while Chevron’s fell 1.0 per cent to US$115.00. — AFP


{% comment %} The plugin can also override the render() method, but this already shows how to deal with more complex plugin content. The


This example simulates the launch of a SpaceX Falcon 9 modeled using a system of ordinary differential equations.


Guideline |
Link |
Description |
|---|---|---|
Mapping Handbook (2011) |
A comprehensive “how to” mapping guide that covers the data, tools, procedures, support, review, and publication requirements. | |
Instructions for Authors -Author Checklist- |
Checklist for authors submitting planetary geologic maps to USGS for post-peer review editing and publication. | |
Instructions for Authors -Map Submission- |
Instructions for the components and format of geologic maps to be submitted to USGS for technical review. | |
Instructions for Authors -Example Folder and Templates- |
Recommended folder structure for authors to help organize map submission including Pamphlet/COMU/DOMU/Table template examples (Word/Excel/Illustrator or InkScape). | |
FGDC Planetary Symbology |
Federal Geographic Data Committee recommended symbology for planetary geologic maps (FGDC website). Most of these symbols are available via ArcGIS and also available within the Astrogeology provided mapping templates: (1) generic empty template for Mars (empty Mars example) or (2) with example images (Athabasca example) both from June 2014 for ArcMap 10.x. |
Guideline |
Link |
Description |
|---|---|---|
Venus Symbols |
Please use FGDC resources above. | |
Venus Geologic Mappers Handbook |
Published in 1994. Some information specific to Venus may still be valuable if not available in the more current handbook above. | |
Venus COMUs |
Venus Correlation of Map Units (COMU/SOMU) as presented in 2003. | |
Magellan Quantitative Data |
Covers the use & presentation of Magellan quantitative data in Venus mapping (1995). | |
Reno Mapping Guidelines for Venus |
Guidelines and recommendations
from a Meeting of the Venus Geological Mapping Steering Group Reno, NV, August 1996 |
|
Washington D.C. Mapping Guidelines for Venus |
Guidelines and recommendations
from a Meeting of the Venus Geological Mapping Steering Group Washington, D.C., October 1995 |
|
Astrogeology Manuscript Submittal Process |
Please use resources in section above. | |
Tips for Preparation of Astrogeology Maps |
Please use resources in section above. |


That's right, zero rights reserved!
All original art & music in this bundle is dedicated to the public domain via
CC Zero.
This means you may freely use these assets in your projects, both personal or commercial.
Attribution's always appreciated, but not required.
The gamedev community has helped me so much while I was building my new indie game
Nothing To Hide.
This is just my way of giving something back.
The hope is that by releasing all these resources, aspiring gamedevs can use them to build grand works of their own.
Take it - it's yours.
By giving up "power" over my art, my art can have more power.


Precision
The Gladiator knows the weak spots in the body of their enemies and is able to hit them with high precision.
+${value} Offensive Ability
40 55 70 85 100 115 130 145 160 175 190 205
+${value}% Offensive Ability
1 2 3 4 5 6 7 8 9 10 11 12
MaxLevel
8
UltimateLevel
12


Or list URLs:
{% extends 'plag/base_account.html' %} {% load staticfiles %} {% load custom_tags %} {% block header_section %} {% endblock %} {% block title %}Your Protected Resources{% endblock %} {% block desc %}View the resources we are currently scanning and protecting for you, and add/remove/change them as necessary.{% endblock %} {% block content %}
Below is a list of resources (i.e. web pages and files) that we are currently protecting against plagiarism for you. To change the resource being protected, or how often we scan it, simply click edit () next to the resource. Alternatively you can remove () the resource, or add () an entirely new resource for us to protect.
{% endblock %} {% block otherelements %}Or list URLs:


--- layout: post status: publish published: true title: Career+Tech Workshop by Mendaki Club author: display_name: Hazrul login: abanghazrul email<EMAIL_ADDRESS>url: '' author_login: abanghazrul author_email<EMAIL_ADDRESS>wordpress_id: 2978 wordpress_url: http://www.matwp.com/?p=2978 date: '2016-12-10 22:26:07 +0800' categories: - Speaking Appearances tags: [] comments: [] ---
Saturday, December 10, 2016
10am to 12pm
IMDA Labs@NDC
REGISTER TODAY: https://goo.gl/forms/GMa6frKNC2UYK1v73
Career+Tech explores how technology has impacted today's career landscape and how we can ride the "tech wave".
Programme:
[1000-1040] Hands-on Activity by iCommerce Asia
> Learn the inner workings of the E-commerce supply chain from click to doorstep, through an interactive hands-on session by iCommerce Asia.
[1040-1100] Social Discussion by VoidDeck Ventures
> Together with tech enthusiasts, discuss how one can enhance their professional skill sets, and help the community embrace technology.
[1100-1200] Lunch and Networking Session
Career+Tech is the first of a series of workshops under the Career +Plus series, a new initiative by MClub. It is targeted at working professionals within the community, and engages them in key areas alongside their careers.
Do register your spot today, as spaces are limited. We look forward to meeting you soon!


President Donald Trump retweeted a video capturing UFC fighter Jorge Masvidal and congratulated him on a ''great fight''. In the clip, the sportsman calls the President ''a bad motherfucker''.
"No matter what your views on Trump as a president, the guy's a bad motherf*cker, man — the money that he's made, the obstacles that he's conquered. He's a bad motherf*cker in his own way, you know, no matter what your political views are", Masvidal said, apparently in response to a reporter's question.
Earlier on Friday, Masvidal defeated Nate Diaz via a TKO at UFC 244 at Madison Square Garden. President Donald Trump also arrived in New York to watch their fight but received a lot of ''boos'' from the audience.
This is the second time this day that Masvidal has come into the spotlight, as he also promised to "f*ck up" UFC fighter Conor McGregor should they meet in the octagon in the future.


This notebook is more of a blog-style where I'll be discussing what I found useful to know and understand about how research is different and ideas/concepts you should keep in mind:
Understanding the Data
- Understanding the ins and outs of the data plays a large role in being able to interpret behaviors about your model and its performance
- Without this we're just throwing a model at data and while we could perform well, you'll be asked why and understanding both the data and the technique let's you do so
Understanding the Techniques
- You'll be the expert in neural networks on the team (I've found), so you need to make sure what you're telling your team is accurate and reliable information
- I found this a particular struggle
- Test Sets
- How (and why) to create a good validation set
Understanding how to Interpret the Techniques
- This is especially hard with tabular, as many researchers still view neural networks as black boxes where we can never know what's going on
- Understanding how to use the various tools to interpret models for your peers/partners in a way that they can understand is extremely valuable. While we may understand what ClassConfusion, SHAP, etc is doing in the background, it's another set of skills entirely to communicate this effectively
You are keeping yourself accountable
If you're ever iffy about anything, automatically assume you need to read a bit more into how to make something work
I had this issue with my research project
- Probably the hardest thing to do is admit when you are wrong, but it's especially important to do so before it's too late


Vision Portfolio Management Application Layer: Application
| Headstart Applications
|
Application: UniverseProfile
Summary:
The UniverseProfile application is used to provide a summary information
about a universe with links to more in depth information. The summary includes
basic information about the universe and its membership history.
Inputs:
| Position |
Form Id |
Description |
| 1 |
id |
Id of the universe |
Analysis:
-
The id must reference an existing Universe instance.
-
The basic display shows the last 25 dates on which the membership changed
and the number of members in the universe on each date.
Key Data Feeds:
Related Reports:
Sample Usage:
Interface ApplicationWS runWith: "UniverseProfile", "SP500" ;
Sample Input:
Sample Output:
Universe Profile
For: Standard & Poors 500
Membership
History
| |
Members |
| 11/30/97 |
500 |
| 10/31/97 |
500 |
| 09/30/97 |
500 |
| 08/31/97 |
500 |
| 07/31/97 |
500 |
| 06/30/97 |
500 |
| 05/31/97 |
500 |
| 04/30/97 |
500 |
| 03/31/97 |
500 |
| 02/28/97 |
500 |
| 01/31/97 |
500 |
| 12/31/96 |
500 |
| 11/30/96 |
500 |
| 10/31/96 |
500 |
| 09/30/96 |
500 |
| 08/31/96 |
500 |
| 07/31/96 |
500 |
| 06/30/96 |
500 |
| 05/31/96 |
500 |
| 04/30/96 |
500 |
| 03/31/96 |
500 |
| 02/29/96 |
500 |
| 01/31/96 |
500 |
| 12/31/95 |
500 |
| 11/30/95 |
500 |
| Copyright © 1999 Innovative Systems Techniques, Inc.
| Updated January 28, 1999
|


You Are on Extended . Use link bellow to view details or upgrade.
For faster login or register use your social account.


{% extends 'wl/emails/base_email.html' %} {% block greetings %} Dear {{ licence.holder.get_full_name }} {% endblock %} {% block content %}
This is a reminder that your licence
{{ licence.get_title_with_variants }} <{{ licence.reference }}>
is due to expire on {{ licence.end_date|date:'d/m/Y' }}.
Please note that if you have oustanding returns, these are required to be submitted before the licence can be renewed.
If you have any queries, please contact the Wildlife Licencing Section on 9219 9831 or<EMAIL_ADDRESS>{% endblock %} {% block signature %}Yours sincerely
for Jim Sharp
DIRECTOR GENERAL
{% now 'd/m/Y' %}
{% endblock %}


{% load i18n %}
{% trans "Your email has been sent, thank you. We will answer soon" %}
{% trans "Home" %}
{% trans "Error sending contact email" %}


Should be 3 stacked headers on top, 3 stacked tab nav bars on bottom, and content should fill the height in between.


About
This website is part of the course websoft and to get more information about the course click on here
Reviews
User #22: I am really enjoying this course and I recommend this course to anyone who is interested in learning or improving their web development skills.
The website I am working on presents some info about me as well as a report containing the answers to the questions for the assignments 01 to 09.
click to go to the website


Thanks you for sharing your information!
You will receive an automatic email with a compy of your data.
If you have any questions please feel free to contact us at...
Thanks you for sharing your information!
You will receive an automatic email with a compy of your data.
If you have any questions please feel free to contact us at...


This graph show accuracy parameters over time based on the parameters on the top of the page.
Total horizontal accuracy over the specified time.
Total vertical accuracy over the specified time.


Across: 1. Miniature horse, mouse-deer or pygmy hippopotamus, not all are giving their names to others.. (9) 8. ...to imitate another animal... (3) 9. ...sounding like a mob from the East with robust humour... (11) 11. ... (if such a mix of blooming... (7) 12. ...feminist and green far fringe characters... (5) 13. ...can be saddled in groups... (6) 15. ...by some safer retrieving animal) (6) 17. In modern life, a graven nuisance... (5) 18. ...traps characters like you and I in the loft... (7) 20. .. (with a meagre offering of pale sun) to be sorted... (11) 22. ...by divine endowment (ie by birth), ... (3) 23. ...being judged as mighty, or just a standard male: unclear, confused (9) Down: 2. Pear seed? (3) 3. Your talks, at their most extreme, say "no whites."... (5) 4. "...or," I say back, "only some Indians." (6) 5. Top of house (in one bit) (7) 6,7. (1-Across) belted gizmo (11,9) 10,11. (1-Across) CLX balls (11,9) 14. "In eternal sleep..." I tap hammer to write (7) 16. "Last meal?" ... (6) 19. ... "Uh, soy dish... (5) 21. ... "and a bit of sausage from the country." (3)


Where did I come from:
I was born in Paris and moved to New York when I was ten. I have relatives from Myanmar to Hawaii! Fun fact: when I got to school in the US, they made me take Spanish instead of French! Fun fact 2: As soon as we moved, MTV used our house in France for the Real World Paris!
Who am I:
a secret comedian with myriads of passions, obsessions, interests, hobbies over time: coding, cooking, technology, exercise, Pilates, yoga, musical theater, music and singing, dance, acting, Shakespeare, Disney, Pokémon, Saturday Night Live, Game of Thrones, crossword puzzles, crochet, vegan and healthy food.....
The present:
I am currently on the road to breaking into the world of tech. Check out my portfolio as I learn all the things! In other news:
I am working towards teaching Pilates (and completing my Pokédex). Someday I hope to combine all of my interests!


TrackerRanker
This page dumps cumulative tracking data to help you block trackers by category.
Blocking Assistant
Low
: Only blocks Category C trackers.
Medium
: Recommended. Blocks Category B, C, and D trackers.
High
: Blocks all trackers.
Advanced Mode
Category A
Category B
Category C
Category D
Category E