qtg_import = True
except Exception as e:
print("ERROR : Could not import packages for pyqtgraph.")
print("Details : {}".format(e))
qtg_import = False
_QTG_IMPORT = True
except Exception:
_logger.error("Cannot import packages for pyqtgraph: {}".format(
traceback.format_exc()))
_QTG_IMPORT = False


Protocols
The following protocols are available globally.
-
Represents a push style sequence.
See moreDeclaration
Swift
public protocol ObservableType : ObservableConvertibleType
-
Supports push-style iteration over an observable sequence.
See moreDeclaration
Swift
public protocol ObserverType
-
Represents disposable resource with state tracking.
See moreDeclaration
Swift
public protocol Cancelable : Disposable
-
Observable sequences containing 0 or 1 element
See moreDeclaration
Swift
public protocol PrimitiveSequenceType
-
Represents an observable sequence wrapper that can be connected and disconnected from its underlying observable sequence.
See moreDeclaration
Swift
public protocol ConnectableObservableType : ObservableType
-
Represents an entity capable of decoding raw
See moreData
into a concreteDecodable
typeDeclaration
Swift
public protocol DataDecoder
-
Represents a disposable resource.
See moreDeclaration
Swift
public protocol Disposable
-
A type that can be converted to
See moreEvent<Element>
.Declaration
Swift
public protocol EventConvertible
-
Represents an object that immediately schedules units of work.
See moreDeclaration
Swift
public protocol ImmediateSchedulerType
-
Infallible
is anObservable
-like push-style interface which is guaranteed to not emit error events.Unlike
See moreSharedSequence
, it does not share its resources or replay its events, but acts as a standardObservable
.Declaration
Swift
public protocol InfallibleType : ObservableConvertibleType
-
Type that can be converted to observable sequence (
See moreObservable<Element>
).Declaration
Swift
public protocol ObservableConvertibleType
-
A type that has reactive extensions.
See moreDeclaration
Swift
public protocol ReactiveCompatible
-
Represents an object that schedules units of work.
See moreDeclaration
Swift
public protocol SchedulerType : ImmediateSchedulerType
-
Represents an object that is both an observable sequence as well as an observer.
See moreDeclaration
Swift
public protocol SubjectType : ObservableType
-
Parametrization for virtual time used by
See moreVirtualTimeScheduler
s.Declaration
Swift
public protocol VirtualTimeConverterType


The big O per frame varies depending on the selected options in the menu. The default FPS cap is 60. The default complexity is O(n*(n-1)) where n = OBJECTS_IN_SIMULATION. Using the experimental features changes big O. For instance turning ON traces changes complexity to O(n * (n-1) * 180) where 180 is a constant determening the size of stored trace coordinates in the trace stack. Enabling colision also adds overhead, however it doesn't change the amount of cycles. P.S. Adding too many objects to the simulation may exeed the capabilities of your browser or PC, thus resulting in lower FPS.
This project was started purely as an intent to learn using the HTML5 canvas and applying some calculus in order to draw something interesting. Later on, after achieveing theoretical object attraction and repulsion and mapped static graphs on a canvas, I decided to animate some movement. At this step I introduced a simple object orientated render frame callback using browser's API. First the animated implementation was for 1 static and 1 dynamic objects. Next step was using 2 dynamic objects. A bigger step was introducing interraction between multiple objects. Later I advanced with adding proper time control, which in means brings the tool 1 step closer to simulation. Since it is not a descrete event simulation it seemed necessary to introduce time tracking. Tracing of objects and collision was later introduced as extras.


$DE57/56919: Read Jump from $CAA9, $CF5A, $E057, $E065, $E075: DE57: A9 80 LDA #$80 ; command code for reading DE59: 8D 4D 02 STA $024D DE5C: D0 21 BNE $DE7F Previous Page / Next Page


|
Name
|
Type
|
Description
|
| description | xsd:string |
A description of the service. Provides help text on how
to use the service.
|
| location | xsd:string[] |
A list of data that can be used to uniquely identify a particular instance of a service.
Multiple instances of a service can exist across different domains (for instance, a service
that is associated with a particular virtual machine or a particular host). In such cases,
the service name is insufficient to identify the service and location data can be used
to identify the instance of interest. A service may publish as much location data
as is needed to identify it (e.g, vmware.host. or vmware.vm. or both).
The particular choice of locations have to be agreed upon by
the client and the service.
|
| service | ManagedObjectReference |
The managed object that presents this service.
|
| serviceName | xsd:string |
A service name. Each service is expected to create a unique name
for itself that can be used to locate the service. This name
does not need to be unique across hosts or other such locations though.
|
|
Properties inherited from DynamicData |
| None |


module Text:sig
..end
Warning This API is currently unsupported in the `Jsoo backend.
To use keyboard keys as actuators use the Useri.Key
module.
val set_input_enabled : bool React.signal -> unit
set_input_enabled enabled
uses the signal enabled
to determine
whether Useri.Text.input
and Useri.Text.editing
events are enabled. Initially set
to S.const false
.val input : string React.event
input
occurs whenever text is input by the user and
the signal given to Useri.Text.set_input_enabled
is true
.val editing : (string * int * int) React.event
editing
may occur with (text, cpos, sel_len)
before Useri.Text.input
whenever text is being composited for example if multiple key
strokes are needed in order to input a character. text
is the
text being composed, cpos
is the cursor position in the text
and sel_len
the selection length (if any). Only occurs if
the signal given to Useri.Text.set_input_enabled
is true
.val clipboard : string React.signal
clipboard
is the clipboard's textual content (if any). This
signal is defined by changes in the application's environement
and occurences of the event given to Useri.Text.set_clipboard_setter
.val set_clipboard_setter : string React.event -> unit
set_clipboard_setter setter
on occurences of setter
sets the
clipboard's textual content. Initially set to E.never
. Note
that Some ""
is the same as
Warning. setter
should not depend on Useri.Text.clipboard
.


Javascript UI Component - Mask - JavaScript Mask Layer Mask / Bootstrap Mask
"mask" allows users to prevent user actions while an application is running.
https://github.com/ax5ui/ax5ui-mask
Javascript UI Component - Dialog - JavaScript Dialog / Bootstrap Dialog "dialog" displays information on a popup window and also enables users to enter input values.
https://github.com/ax5ui/ax5ui-dialog
Javascript UI Component - Select Extension "select" allows users to select a collection of items.
https://github.com/ax5ui/ax5ui-select
Javascript UI Component - GRID "grid" displays data in a table format with various options provided for configuration.
https://github.com/ax5ui/ax5ui-grid
Javascript UI Component - Calendar ( Dual, Single Calendar ) "calendar" displays dates in a calendar format and enables users to select a single or multiple values.
https://github.com/ax5ui/ax5ui-calendar
Javascript UI Component - Picker ( Calendar, Keyboard, NumberPad ) "picker" provides users a simple way to select a single value from a pre-determined set of values.
https://github.com/ax5ui/ax5ui-picker
Javascript UI Component - Media Viewer (Vimeo, Youtube, Image, Gallery) "media-player" to display media content such as video and image.
https://github.com/ax5ui/ax5ui-media-viewer
Javascript UI Component - Formatter ( Money, Date, Time Formatter ) "formatter" provides a set of pre-defined formats for various types of values.
https://github.com/ax5ui/ax5ui-formatter
Javascript UI Component - Combobox "combobox" lets users make a selection from a drop-down list.
https://github.com/ax5ui/ax5ui-combobox
Javascript UI Component - Layout (Dynamic Layout, Page Layout, Script Layout) "layout" helps users set position and size of multiple panels on a page.
https://github.com/ax5ui/ax5ui-layout
Javascript UI Component - Input AutoComplete "autocomplete" displays suggestions while the input is being typed by users.
https://github.com/ax5ui/ax5ui-autocomplete
Javascript UI Component - Modal (JavaScript Modal ) / jQuery / Bootstrap / Modal "modal" to display content on a secondary window which disables interactions with the main view.
https://github.com/ax5ui/ax5ui-modal
Javascript UI Component - Menu (Context Menu, Inline Menu) "menu" displays a list of items in a hierarchical structure.
https://github.com/ax5ui/ax5ui-menu
Javascript UI Component - Toast - JavaScript Toast / Bootstrap Toast "toast" provides feedbacks about an operation in a temporary popup.
"ax5core" source code is being released on Github. When you click the link to move to Github repository. Feel the joy of contributing to open source. We are always waiting for your action.
'AX5UI' can be used with Bootstrap theme. The development of the distribution of the various UI plug-in. When you click the link to move to AX5UI index page.


Overview | Reports | Quarter | Contract
| Vendor Name: | W. RICHARDS CLIMATE CONSULTING |
| Reference number: | K3D34-13-1209 |
| Contract Date: | 2014-06-30 |
| Description of work: | 0891 Personal Services |
| Contract period: | 2013-09-11 to 2014-03-31 |
| Delivery Date: | |
| Contract Value: | $22,377.24 |
| Comments: | Former Public Servant in receipt of a pension under the Public Service Superannuation Act. Original Amount $16500.00 Amendment to previously disclosed contract. Creating a network of virtual long term stations for Canada, one for each weather offic |


Table of Contents
This chapter specifies activities that occur during execution of a program. It is organized around the life cycle of the Java Virtual Machine and of the classes, interfaces, and objects that form a program.
The Java Virtual Machine starts up by loading a
specified class and then invoking the method main
in this specified class. Section §12.1 outlines
the loading, linking, and initialization steps involved in
executing main
, as an introduction to the concepts
in this chapter. Further sections specify the details of loading
(§12.2),
linking (§12.3),
and initialization (§12.4).
The chapter continues with a specification of the procedures for creation of new class instances (§12.5); and finalization of class instances (§12.6). It concludes by describing the unloading of classes (§12.7) and the procedure followed when a program exits (§12.8).
The Java Virtual Machine
starts execution by invoking the method main
of
some specified class, passing it a single argument, which is an array
of strings. In the examples in this specification, this first class is
typically called Test
.
The precise semantics of Java Virtual Machine startup are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 8 Edition. Here we present an overview of the process from the viewpoint of the Java programming language.
The manner in which the
initial class is specified to the Java Virtual Machine is beyond the scope of this
specification, but it is typical, in host environments that use
command lines, for the fully-qualified name of the class to be
specified as a command-line argument and for following command-line
arguments to be used as strings to be provided as the argument to the
method main
.
For example, in a UNIX implementation, the command line:
java Test reboot Bob Dot Enzo
will typically start a Java Virtual Machine by invoking
method main
of class Test
(a
class in an unnamed package), passing it an array containing the four
strings "reboot
", "Bob
",
"Dot
", and "Enzo
".
We now outline the steps the
Java Virtual Machine may take to execute Test
, as an example of
the loading, linking, and initialization processes that are described
further in later sections.
The initial attempt to
execute the method main
of
class Test
discovers that the
class Test
is not loaded - that is, that the Java Virtual Machine
does not currently contain a binary representation for this class. The
Java Virtual Machine then uses a class loader to attempt to find such a binary
representation. If this process fails, then an error is thrown. This
loading process is described further in
§12.2.
After Test
is loaded, it
must be initialized before main
can be
invoked. And Test
, like all (class or interface)
types, must be linked before it is initialized. Linking involves
verification, preparation, and (optionally) resolution. Linking is
described further in §12.3.
Verification checks that the
loaded representation of Test
is well-formed, with
a proper symbol table. Verification also checks that the code that
implements Test
obeys the semantic requirements of
the Java programming language and the Java Virtual Machine. If a problem is detected during
verification, then an error is thrown. Verification is described
further in §12.3.1.
Preparation involves allocation of static storage and any data structures that are used internally by the implementation of the Java Virtual Machine, such as method tables. Preparation is described further in §12.3.2.
Resolution is the process of
checking symbolic references from Test
to other
classes and interfaces, by loading the other classes and interfaces
that are mentioned and checking that the references are
correct.
The resolution step is
optional at the time of initial linkage. An implementation may resolve
symbolic references from a class or interface that is being linked
very early, even to the point of resolving all symbolic references
from the classes and interfaces that are further referenced,
recursively. (This resolution may result in errors from these further
loading and linking steps.) This implementation choice represents one
extreme and is similar to the kind of "static" linkage that has been
done for many years in simple implementations of the C language. (In
these implementations, a compiled program is typically represented as
an "a.out
" file that contains a fully-linked
version of the program, including completely resolved links to library
routines used by the program. Copies of these library routines are
included in the "a.out
" file.)
An implementation may
instead choose to resolve a symbolic reference only when it is
actively used; consistent use of this strategy for all symbolic
references would represent the "laziest" form of resolution. In this
case, if Test
had several symbolic references to
another class, then the references might be resolved one at a time, as
they are used, or perhaps not at all, if these references were never
used during execution of the program.
The only requirement on when
resolution is performed is that any errors detected during resolution
must be thrown at a point in the program where some action is taken by
the program that might, directly or indirectly, require linkage to the
class or interface involved in the error. Using the "static" example
implementation choice described above, loading and linkage errors
could occur before the program is executed if they involved a class or
interface mentioned in the class Test
or any of the
further, recursively referenced, classes and interfaces. In a system
that implemented the "laziest" resolution, these errors would be
thrown only when an incorrect symbolic reference is actively
used.
The resolution process is described further in §12.3.3.
In our continuing example,
the Java Virtual Machine is still trying to execute the
method main
of class Test
. This
is permitted only if the class has been initialized
(§12.4.1).
Initialization consists of
execution of any class variable initializers and static initializers
of the class Test
, in textual order. But
before Test
can be initialized, its direct
superclass must be initialized, as well as the direct superclass of
its direct superclass, and so on, recursively. In the simplest
case, Test
has Object
as its implicit direct
superclass; if class Object
has not yet been initialized, then it
must be initialized before Test
is
initialized. Class Object
has no superclass, so the recursion
terminates here.
If
class Test
has another
class Super
as its superclass,
then Super
must be initialized
before Test
. This requires loading, verifying, and
preparing Super
if this has not already been done
and, depending on the implementation, may also involve resolving the
symbolic references from Super
and so on,
recursively.
Initialization may thus cause loading, linking, and initialization errors, including such errors involving other types.
The initialization process is described further in §12.4.
Finally, after completion of
the initialization for class Test
(during which
other consequential loading, linking, and initializing may have
occurred), the method main
of Test
is invoked.
The
method main
must be declared public
, static
,
and void
. It must specify a
formal parameter (§8.4.1)
whose declared type is
array of String
. Therefore, either of the following declarations is
acceptable:
public static void main(String[] args)
public static void main(String... args)
Loading
refers to the process of finding the binary form of a class or
interface type with a particular name, perhaps by computing it on the
fly, but more typically by retrieving a binary representation
previously computed from source code by a Java compiler, and
constructing, from that binary form, a Class
object to represent the
class or interface.
The precise semantics of loading are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 8 Edition. Here we present an overview of the process from the viewpoint of the Java programming language.
The binary format of a class
or interface is normally the class
file format described in The Java Virtual Machine Specification, Java SE 8 Edition
cited above, but other formats are possible, provided they meet the
requirements specified in §13.1. The
method defineClass
of class ClassLoader
may be
used to construct Class
objects from binary representations in the
class
file format.
Well-behaved class loaders maintain these properties:
Given the same name, a good class loader should always return the same class object.
If a class
loader L1
delegates loading of a class C
to
another loader L2
, then for any type T
that
occurs as the direct superclass or a direct superinterface of
C, or as the type of a field in C, or as the
type of a formal
parameter of a method or constructor in C, or as a return type
of a method in C, L1
and L2
should return the same Class
object.
A malicious class loader could violate these properties. However, it could not undermine the security of the type system, because the Java Virtual Machine guards against this.
For further discussion of these issues, see The Java Virtual Machine
Specification, Java SE 8 Edition
and the paper Dynamic Class Loading in the Java Virtual
Machine, by Sheng Liang and Gilad Bracha,
in Proceedings of OOPSLA '98, published
as ACM SIGPLAN Notices, Volume 33, Number 10,
October 1998, pages 36-44. A basic principle of the design of the
Java programming language is that the run-time type system cannot be subverted by
code written in the Java programming language, not even by implementations of such
otherwise sensitive system classes as ClassLoader
and SecurityManager
.
The loading process is
implemented by the class ClassLoader
and its subclasses.
Different subclasses of
ClassLoader
may implement different loading policies. In particular,
a class loader may cache binary representations of classes and
interfaces, prefetch them based on expected usage, or load a group of
related classes together. These activities may not be completely
transparent to a running application if, for example, a newly compiled
version of a class is not found because an older version is cached by
a class loader. It is the responsibility of a class loader, however,
to reflect loading errors only at points in the program where they
could have arisen without prefetching or group loading.
If an error occurs during
class loading, then an instance of one of the following subclasses of
class LinkageError
will be thrown at any point in the program that
(directly
or indirectly) uses the type:
ClassCircularityError
: A class or
interface could not be loaded because it would be its own
superclass or superinterface (§8.1.4,
§9.1.3,
§13.4.4).
ClassFormatError
:
The binary data
that purports to specify a requested compiled class or interface
is malformed.
NoClassDefFoundError
:
No definition
for a requested class or interface could be found by the relevant
class loader.
Because loading involves the
allocation of new data structures, it may fail with an OutOfMemoryError
.
Linking is the process of taking a binary form of a class or interface type and combining it into the run-time state of the Java Virtual Machine, so that it can be executed. A class or interface type is always loaded before it is linked.
Three different activities are involved in linking: verification, preparation, and resolution of symbolic references.
The precise semantics of linking are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 8 Edition. Here we present an overview of the process from the viewpoint of the Java programming language.
This specification allows an implementation flexibility as to when linking activities (and, because of recursion, loading) take place, provided that the semantics of the Java programming language are respected, that a class or interface is completely verified and prepared before it is initialized, and that errors detected during linkage are thrown at a point in the program where some action is taken by the program that might require linkage to the class or interface involved in the error.
For example, an implementation may choose to resolve each symbolic reference in a class or interface individually, only when it is used (lazy or late resolution), or to resolve them all at once while the class is being verified (static resolution). This means that the resolution process may continue, in some implementations, after a class or interface has been initialized.
Because linking involves the
allocation of new data structures, it may fail with an OutOfMemoryError
.
Verification ensures that the binary representation of a class or interface is structurally correct. For example, it checks that every instruction has a valid operation code; that every branch instruction branches to the start of some other instruction, rather than into the middle of an instruction; that every method is provided with a structurally correct signature; and that every instruction obeys the type discipline of the Java Virtual Machine language.
If an error occurs during
verification, then an instance of the following subclass of class LinkageError
will be thrown at the point in the program that caused the class to be
verified:
VerifyError
: The
binary
definition for a class or interface failed to pass a set of
required checks to verify that it obeys the semantics of the
Java Virtual Machine language and that it cannot violate the integrity of the
Java Virtual Machine. (See §13.4.2,
§13.4.4, §13.4.9,
and
§13.4.17
for some examples.)
Preparation involves
creating the static
fields (class variables and constants) for a
class or interface and initializing such fields to the default values
(§4.12.5).
This does not require the execution of
any source code; explicit initializers for static fields are executed
as part of initialization (§12.4),
not
preparation.
Implementations of the Java Virtual Machine may precompute additional data structures at preparation time in order to make later operations on a class or interface more efficient. One particularly useful data structure is a "method table" or other data structure that allows any method to be invoked on instances of a class without requiring a search of superclasses at invocation time.
The binary representation of a class or interface references other classes and interfaces and their fields, methods, and constructors symbolically, using the binary names (§13.1) of the other classes and interfaces (§13.1). For fields and methods, these symbolic references include the name of the class or interface type of which the field or method is a member, as well as the name of the field or method itself, together with appropriate type information.
Before a symbolic reference can be used it must undergo resolution, wherein a symbolic reference is checked to be correct and, typically, replaced with a direct reference that can be more efficiently processed if the reference is used repeatedly.
If an error occurs during
resolution, then an error will be thrown. Most typically, this will be
an instance of one of the following subclasses of the class IncompatibleClassChangeError
,
but it may also be an instance of some other subclass of IncompatibleClassChangeError
or
even an instance of the class IncompatibleClassChangeError
itself. This
error may be thrown
at any point in the program that uses a symbolic reference to the
type, directly or indirectly:
IllegalAccessError
:
A symbolic
reference has been encountered that specifies a use or
assignment of a field, or invocation of a method, or creation of
an instance of a class, to which the code containing the
reference does not have access because the field or method was
declared with private
, protected
,
or package access (not
public
), or because the class was not declared
public
.
This can occur, for example, if a field that is
originally declared public
is changed to be private
after
another class that refers to the field has been compiled
(§13.4.7).
InstantiationError
:
A symbolic reference has been encountered that is used in class
instance creation expression, but an instance cannot be created
because the reference turns out to refer to an interface or to
an abstract class.
This can occur, for example, if a class that is
originally not abstract
is changed to be abstract
after
another class that refers to the class in question has been
compiled (§13.4.1).
NoSuchFieldError
: A
symbolic
reference has been encountered that refers to a specific field
of a specific class or interface, but the class or interface
does not contain a field of that name.
This can occur, for example, if a field declaration was deleted from a class after another class that refers to the field was compiled (§13.4.8).
NoSuchMethodError
: A
symbolic
reference has been encountered that refers to a specific method
of a specific class or interface, but the class or interface
does not contain a method of that signature.
This can occur, for example, if a method declaration was deleted from a class after another class that refers to the method was compiled (§13.4.12).
Additionally, an
UnsatisfiedLinkError
, a subclass of LinkageError
, may be thrown if a class
declares a native
method for which no implementation can be
found. The error will occur if the method is used, or earlier,
depending on what kind of resolution strategy is being used by an
implementation of the Java Virtual Machine (§12.3).
Initialization
of a class consists of executing its static initializers and the
initializers for static
fields (class variables) declared in the
class.
Initialization of an interface consists of executing the initializers for fields (constants) declared in the interface.
A class or interface type T will be initialized immediately before the first occurrence of any one of the following:
When a class is initialized, its superclasses are initialized (if they have not been previously initialized), as well as any superinterfaces (§8.1.5) that declare any default methods (§9.4.3) (if they have not been previously initialized). Initialization of an interface does not, of itself, cause initialization of any of its superinterfaces.
A reference to a static
field (§<IP_ADDRESS>)
causes
initialization of only the class or interface that actually declares
it, even though it might be referred to through the name of a
subclass, a subinterface, or a class that implements an
interface.
Invocation of certain reflective methods in class Class
and in
package java.lang.reflect
also causes class or interface
initialization.
A class or interface will not be initialized under any other circumstance.
Note that a compiler may generate synthetic default methods in an interface, that is, default methods that are neither explicitly nor implicitly declared (§13.1). Such methods will trigger the interface's initialization despite the source code giving no indication that the interface should be initialized.
The intent is that a class or interface type has a set of initializers that put it in a consistent state, and that this state is the first state that is observed by other classes. The static initializers and class variable initializers are executed in textual order, and may not refer to class variables declared in the class whose declarations appear textually after the use, even though these class variables are in scope (§8.3.3). This restriction is designed to detect, at compile time, most circular or otherwise malformed initializations.
The fact that initialization code is unrestricted allows examples to be constructed where the value of a class variable can be observed when it still has its initial default value, before its initializing expression is evaluated, but such examples are rare in practice. (Such examples can be also constructed for instance variable initialization (§12.5).) The full power of the Java programming language is available in these initializers; programmers must exercise some care. This power places an extra burden on code generators, but this burden would arise in any case because the Java programming language is concurrent (§12.4.2).
Example 12.4.1-1. Superclasses Are Initialized Before Subclasses
class Super { static { System.out.print("Super "); } } class One { static { System.out.print("One "); } } class Two extends Super { static { System.out.print("Two "); } } class Test { public static void main(String[] args) { One o = null; Two t = new Two(); System.out.println((Object)o == (Object)t); } }
This program produces the output:
Super Two false
The class One
is never
initialized, because it not used actively and therefore is never
linked to. The class Two
is initialized only after
its superclass Super
has been initialized.
Example 12.4.1-2. Only The Class That Declares static
Field Is Initialized
class Super { static int taxi = 1729; } class Sub extends Super { static { System.out.print("Sub "); } } class Test { public static void main(String[] args) { System.out.println(Sub.taxi); } }
This program prints only:
1729
because the class Sub
is never
initialized; the reference to Sub.taxi
is a
reference to a field actually declared in
class Super
and does not trigger initialization of
the class Sub
.
Example 12.4.1-3. Interface Initialization Does Not Initialize Superinterfaces
interface I { int i = 1, ii = Test.out("ii", 2); } interface J extends I { int j = Test.out("j", 3), jj = Test.out("jj", 4); } interface K extends J { int k = Test.out("k", 5); } class Test { public static void main(String[] args) { System.out.println(J.i); System.out.println(K.j); } static int out(String s, int i) { System.out.println(s + "=" + i); return i; } }
This program produces the output:
1 j=3 jj=4 3
The reference to J.i
is to a
field that is a constant variable
(§4.12.4); therefore, it does not
cause I
to be initialized
(§13.4.9).
The reference to K.j
is a
reference to a field actually declared in
interface J
that is not
a constant variable; this causes
initialization of the fields of interface J
, but
not those of its superinterface I
, nor those of
interface K
.
Despite the fact that the name K
is used to refer to field j
of
interface J
, interface K
is not
initialized.
Because the Java programming language is multithreaded, initialization of a class or interface requires careful synchronization, since some other thread may be trying to initialize the same class or interface at the same time. There is also the possibility that initialization of a class or interface may be requested recursively as part of the initialization of that class or interface; for example, a variable initializer in class A might invoke a method of an unrelated class B, which might in turn invoke a method of class A. The implementation of the Java Virtual Machine is responsible for taking care of synchronization and recursive initialization by using the following procedure.
The
procedure assumes that the Class
object has already been verified
and prepared, and that the Class
object contains state that
indicates one of four situations:
For each class or interface C, there is a unique initialization lock
LC
. The mapping from C to LC
is left to the discretion of the
Java Virtual Machine implementation. The procedure for initializing C is then
as
follows:
Synchronize on the initialization lock, LC
, for C. This
involves waiting until the current thread can acquire
LC
.
If the Class
object for C indicates
that initialization is
in progress for C by some other thread, then release LC
and
block the current thread until informed that the in-progress
initialization has completed, at which time repeat this
step.
If the Class
object for C indicates
that initialization is
in progress for C by the current thread, then this must be a
recursive request for initialization. Release LC
and complete
normally.
If the Class
object for C indicates
that C has already
been initialized, then no further action is required. Release
LC
and complete normally.
If the Class
object for C is in an
erroneous state, then
initialization is not possible. Release LC
and throw a
NoClassDefFoundError
.
Otherwise, record the fact that initialization of the Class
object for C is in progress by the current thread, and release
LC
.
Then, initialize the
static
fields of C which are constant
variables
(§4.12.4,
§8.3.2,
§9.3.1).
Next, if C is a class rather than an interface, and its
superclass has not yet been initialized, then let SC be its
superclass and let SI1,
..., SIn be all
superinterfaces of C that declare at least one default
method. The order of superinterfaces is given by a recursive
enumeration over the superinterface hierarchy of each interface
directly implemented by C (in the left-to-right order of C's
implements
clause). For each
interface I directly implemented by C,
the enumeration
recurs on I's superinterfaces (in the left-to-right order of
I's extends
clause) before returning
I.
For each S in the list [ SC, SI1, ..., SIn ], recursively perform this entire procedure for S. If necessary, verify and prepare S first.
If the initialization of S completes abruptly because of a
thrown exception, then acquire LC
, label the Class
object
for C as erroneous, notify all waiting threads, release LC
,
and complete abruptly, throwing the same exception that resulted
from initializing S.
Next, determine whether assertions are enabled (§14.10) for C by querying its defining class loader.
Next, execute either the class variable initializers and static initializers of the class, or the field initializers of the interface, in textual order, as though they were a single block.
If the execution of the initializers completes normally, then
acquire LC
, label the Class
object
for C as fully
initialized, notify all waiting threads, release LC
, and
complete this procedure normally.
Otherwise, the initializers must have completed abruptly by
throwing some exception E. If the class of E is not Error
or one of its subclasses, then create a new instance of the
class ExceptionInInitializerError
, with E as the argument,
and use this object in place of E in the following step. If a
new instance of ExceptionInInitializerError
cannot be created
because an OutOfMemoryError
occurs, then instead use an OutOfMemoryError
object in
place of E in the following step.
Acquire LC
, label the Class
object
for C as erroneous,
notify all waiting threads, release LC
, and complete this
procedure abruptly with reason E or its replacement as
determined in the previous step.
An implementation may optimize this procedure by eliding the lock acquisition in step 1 (and release in step 4/5) when it can determine that the initialization of the class has already completed, provided that, in terms of the memory model, all happens-before orderings that would exist if the lock were acquired, still exist when the optimization is performed.
Code generators need to preserve the points of
possible initialization of a class or interface, inserting an
invocation of the initialization procedure just described. If this
initialization procedure completes normally and the Class
object is
fully initialized and ready for use, then the invocation of the
initialization procedure is no longer necessary and it may be
eliminated from the code - for example, by patching it out or
otherwise regenerating the code.
Compile-time analysis may, in some cases, be able to eliminate many of the checks that a type has been initialized from the generated code, if an initialization order for a group of related types can be determined. Such analysis must, however, fully account for concurrency and for the fact that initialization code is unrestricted.
A new class instance is explicitly created when evaluation of a class instance creation expression (§15.9) causes a class to be instantiated.
A new class instance may be implicitly created in the following situations:
Loading of a class or interface that contains a String
literal
(§3.10.5) may create a new String
object
to represent that literal. (This might not occur if the same
String
has previously been interned
(§3.10.5).)
Execution of an operation that causes boxing conversion (§5.1.7). Boxing conversion may create a new object of a wrapper class associated with one of the primitive types.
Execution of a string concatenation operator +
(§15.18.1) that is not part of
a constant
expression (§15.28) always
creates a new String
object to represent the result. String
concatenation operators may also create temporary wrapper
objects for a value of a primitive type.
Evaluation of a method reference expression (§15.13.3) or a lambda expression (§15.27.4) may require that a new instance of a class that implements a functional interface type be created.
Each of these situations identifies a particular constructor (§8.8) to be called with specified arguments (possibly none) as part of the class instance creation process.
Whenever a new class instance is created, memory space is allocated for it with room for all the instance variables declared in the class type and all the instance variables declared in each superclass of the class type, including all the instance variables that may be hidden (§8.3).
If there
is not sufficient space available to allocate memory for the object,
then creation of the class instance completes abruptly with an
OutOfMemoryError
. Otherwise, all the instance variables in the new object,
including those declared in superclasses, are initialized to their
default values (§4.12.5).
Just before a reference to the newly created object is returned as the result, the indicated constructor is processed to initialize the new object using the following procedure:
Assign the arguments for the constructor to newly created parameter variables for this constructor invocation.
If
this constructor begins with an explicit constructor invocation
(§<IP_ADDRESS>) of another
constructor in the
same class (using this
), then evaluate the arguments and
process that constructor invocation recursively using these same
five steps. If that constructor invocation completes abruptly,
then this procedure completes abruptly for the same reason;
otherwise, continue with step 5.
This
constructor does not begin with an explicit constructor
invocation of another constructor in the same class (using
this
). If this constructor is for a class other than Object
,
then this constructor will begin with an explicit or implicit
invocation of a superclass constructor (using super
). Evaluate
the arguments and process that superclass constructor invocation
recursively using these same five steps. If that constructor
invocation completes abruptly, then this procedure completes
abruptly for the same reason. Otherwise, continue with step
4.
Execute the instance initializers and instance variable initializers for this class, assigning the values of instance variable initializers to the corresponding instance variables, in the left-to-right order in which they appear textually in the source code for the class. If execution of any of these initializers results in an exception, then no further initializers are processed and this procedure completes abruptly with that same exception. Otherwise, continue with step 5.
Execute the rest of the body of this constructor. If that execution completes abruptly, then this procedure completes abruptly for the same reason. Otherwise, this procedure completes normally.
Unlike C++, the Java programming language does not specify altered rules for method dispatch during the creation of a new class instance. If methods are invoked that are overridden in subclasses in the object being initialized, then these overriding methods are used, even before the new object is completely initialized.
Example 12.5-1. Evaluation of Instance Creation
class Point { int x, y; Point() { x = 1; y = 1; } } class ColoredPoint extends Point { int color = 0xFF00FF; } class Test { public static void main(String[] args) { ColoredPoint cp = new ColoredPoint(); System.out.println(cp.color); } }
Here, a new instance
of ColoredPoint
is created. First, space is
allocated for the new ColoredPoint
, to hold the
fields x
, y
,
and color
. All these fields are then initialized to
their default values (in this case, 0
for each field). Next,
the ColoredPoint
constructor with no arguments is
first invoked. Since ColoredPoint
declares no
constructors, a default constructor of the following form is
implicitly declared:
ColoredPoint() { super(); }
This constructor then invokes
the Point
constructor with no
arguments. The Point
constructor does not begin
with an invocation of a constructor, so the Java compiler provides an
implicit invocation of its superclass constructor of no arguments, as
though it had been written:
Point() { super(); x = 1; y = 1; }
Therefore, the constructor for Object
which takes
no arguments is invoked.
The class Object
has no superclass, so the
recursion terminates here. Next, any instance initializers and
instance variable initializers of Object
are invoked. Next, the body
of the constructor of Object
that takes no arguments is executed. No
such constructor is declared in Object
, so the Java compiler
supplies a default one, which in this special case is:
Object() { }
This constructor executes without effect and returns.
Next, all initializers for the instance variables of
class Point
are executed. As it happens, the
declarations of x
and y
do not
provide any initialization expressions, so no action is required for
this step of the example. Then the body of
the Point
constructor is executed,
setting x
to 1
and y
to
1
.
Next, the initializers for the instance variables of
class ColoredPoint
are executed. This step assigns
the value 0xFF00FF
to color
. Finally, the rest of the body of
the ColoredPoint
constructor is executed (the part
after the invocation of super
); there happen to be
no statements in the rest of the body, so no further action is
required and initialization is complete.
Example 12.5-2. Dynamic Dispatch During Instance Creation
class Super { Super() { printThree(); } void printThree() { System.out.println("three"); } } class Test extends Super { int three = (int)Math.PI; // That is, 3 void printThree() { System.out.println(three); } public static void main(String[] args) { Test t = new Test(); t.printThree(); } }
This program produces the output:
0 3
This shows that the invocation
of printThree
in the constructor for
class Super
does not invoke the definition
of printThree
in class Super
,
but rather invokes the overriding definition
of printThree
in
class Test
. This method therefore runs before the
field initializers of Test
have been executed,
which is why the first value output is 0
, the default value to
which the field three
of Test
is
initialized. The later invocation of printThree
in
method main
invokes the same definition
of printThree
, but by that point the initializer
for instance variable three
has been executed, and
so the value 3
is printed.
The class
Object
has a protected
method called finalize
;
this method can be overridden by other classes. The particular
definition of finalize
that can be invoked for an
object is called the finalizer of that
object. Before the storage for an object is reclaimed by the garbage
collector, the Java Virtual Machine will invoke the finalizer of that object.
Finalizers provide a chance to free up resources that cannot be freed automatically by an automatic storage manager. In such situations, simply reclaiming the memory used by an object would not guarantee that the resources it held would be reclaimed.
The Java programming language does not specify how soon a finalizer will be invoked, except to say that it will happen before the storage for the object is reused.
The Java programming language does not specify which thread will invoke the finalizer for any given object.
It is important to note that many finalizer threads
may be active (this is sometimes needed on large shared memory
multiprocessors), and that if a large connected data structure becomes
garbage, all of the finalize
methods for every
object in that data structure could be invoked at the same time, each
finalizer invocation running in a different thread.
The
Java programming language imposes no ordering on finalize
method
calls. Finalizers may be called in any order, or even
concurrently.
As an example, if a circularly linked group of unfinalized objects becomes unreachable (or finalizer-reachable), then all the objects may become finalizable together. Eventually, the finalizers for these objects may be invoked, in any order, or even concurrently using multiple threads. If the automatic storage manager later finds that the objects are unreachable, then their storage can be reclaimed.
It is straightforward to implement a class that will cause a set of finalizer-like methods to be invoked in a specified order for a set of objects when all the objects become unreachable. Defining such a class is left as an exercise for the reader.
It is guaranteed that the thread that invokes the finalizer will not be holding any user-visible synchronization locks when the finalizer is invoked.
If an uncaught exception is thrown during the finalization, the exception is ignored and finalization of that object terminates.
The
completion of an object's constructor happens-before
(§17.4.5)
the execution of
its finalize
method (in the formal sense of
happens-before).
The finalize
method declared
in class Object
takes no action. The fact that class Object
declares a finalize
method means that
the finalize
method for any class can always invoke
the finalize
method for its superclass. This should
always be done, unless it is the programmer's intent to nullify the
actions of the finalizer in the superclass. (Unlike constructors,
finalizers do not automatically invoke the finalizer for the
superclass; such an invocation must be coded explicitly.)
For efficiency, an implementation may keep track of
classes that do not override the finalize
method of
class Object
, or override it in a trivial way.
For example:
protected void finalize() throws Throwable { super.finalize(); }
We encourage implementations to treat such objects as having a finalizer that is not overridden, and to finalize them more efficiently, as described in §12.6.1.
A finalizer may be invoked explicitly, just like any other method.
The package java.lang.ref
describes weak references, which interact with garbage collection and
finalization. As with any API that has special interactions with the
Java programming language, implementors must be cognizant of any requirements imposed
by the java.lang.ref
API. This specification does not discuss weak
references in any way. Readers are referred to the API documentation
for details.
Every object can be characterized by two attributes: it may be reachable, finalizer-reachable, or unreachable, and it may also be unfinalized, finalizable, or finalized.
A reachable object is any object that can be accessed in any potential continuing computation from any live thread.
A finalizer-reachable object can be reached from some finalizable object through some chain of references, but not from any live thread.
An unreachable object cannot be reached by either means.
An unfinalized object has never had its finalizer automatically invoked.
A finalized object has had its finalizer automatically invoked.
A finalizable object has never had its finalizer automatically invoked, but the Java Virtual Machine may eventually automatically invoke its finalizer.
An
object o
is not finalizable until its constructor
has invoked the constructor for Object
on o
and
that invocation has completed successfully (that is, without throwing
an exception). Every pre-finalization write to a field of an object
must be visible to the finalization of that object. Furthermore, none
of the pre-finalization reads of fields of that object may see writes
that occur after finalization of that object is initiated.
Optimizing transformations
of a program can be designed that reduce the number of objects that
are reachable to be less than those which would naively be considered
reachable. For example, a Java compiler or code generator may choose
to set a variable or parameter that will no longer be used to null
to cause the storage for such an object to be potentially reclaimable
sooner.
Another example of this occurs if the values in an object's fields are stored in registers. The program may then access the registers instead of the object, and never access the object again. This would imply that the object is garbage. Note that this sort of optimization is only allowed if references are on the stack, not stored in the heap.
For example, consider the Finalizer Guardian pattern:
class Foo { private final Object finalizerGuardian = new Object() { protected void finalize() throws Throwable { /* finalize outer Foo object */ } } }
The finalizer guardian
forces super.finalize
to be called if a subclass
overrides finalize
and does not explicitly
call super.finalize
.
If these optimizations are allowed for references
that are stored on the heap, then a Java compiler can detect that
the finalizerGuardian
field is never read, null it
out, collect the object immediately, and call the finalizer
early. This runs counter to the intent: the programmer probably wanted
to call the Foo
finalizer when
the Foo
instance became unreachable. This sort of
transformation is therefore not legal: the inner class object should
be reachable for as long as the outer class object is
reachable.
Transformations of this sort may result in
invocations of the finalize
method occurring
earlier than might be otherwise expected. In order to allow the user
to prevent this, we enforce the notion that synchronization may keep
the object alive. If an object's finalizer can result in
synchronization on that object, then that object must be alive and
considered reachable whenever a lock is held on it.
Note that this does not prevent synchronization elimination: synchronization only keeps an object alive if a finalizer might synchronize on it. Since the finalizer occurs in another thread, in many cases the synchronization could not be removed anyway.
It must be possible for the memory model (§17.4) to decide when it can commit actions that take place in a finalizer. This section describes the interaction of finalization with the memory model.
Each execution has a number of reachability decision points, labeled di. Each action either comes-before di or comes-after di. Other than as explicitly mentioned, the comes-before ordering described in this section is unrelated to all other orderings in the memory model.
If r is a read that sees a write w and r comes-before di, then w must come-before di.
If x and y are synchronization actions on the same variable or monitor such that so(x, y) (§17.4.4) and y comes-before di, then x must come-before di.
At each
reachability decision point, some set of objects are marked as
unreachable, and some subset of those objects are marked as
finalizable. These reachability decision points are also the points at
which references are checked, enqueued, and cleared according to the
rules provided in the API documentation for the package
java.lang.ref
.
The only objects that are considered definitely reachable at a point di are those that can be shown to be reachable by the application of these rules:
An
object B
is definitely reachable
at di from static
fields
if there exists
a write w1 to a static
field v
of a class C such that the
value
written by w1 is a reference
to B
, the class C is loaded by a
reachable
classloader, and there does not exist a
write w2 to v
such
that hb(w2, w1) is not true and
both w1 and w2
come-before di.
An
object B
is definitely reachable
from A
at di if there is
a write w1 to an
element v
of A
such that
the value written by w1 is a reference
to B
and there does not exist a
write w2 to v
such
that hb(w2, w1) is not true and
both w1 and w2
come-before di.
If
an object C
is definitely reachable from an
object B
, and object B
is
definitely reachable from an object A
,
then C
is definitely reachable
from A
.
If an
object X
is marked as unreachable
at di, then:
X
must not
be
definitely reachable at di from static
fields; and
All active uses
of X
in thread t
that
come-after di must occur in the finalizer
invocation for X
or as a result of
thread t
performing a read that
comes-after di of a reference
to X
; and
All reads that
come-after di that see a reference
to X
must see writes to elements of objects
that were unreachable at di, or see writes
that came-after di.
An
action a is an active use of X
if and only if at least one of the following is true:
An implementation of the Java programming language may unload classes.
A class or interface may be unloaded if and only if its defining class loader may be reclaimed by the garbage collector as discussed in §12.6.
Classes and interfaces loaded by the bootstrap loader may not be unloaded.
Class unloading is an optimization that helps reduce memory use. Obviously, the semantics of a program should not depend on whether and how a system chooses to implement an optimization such as class unloading. To do otherwise would compromise the portability of programs. Consequently, whether a class or interface has been unloaded or not should be transparent to a program.
However, if a class or interface C was unloaded while its defining loader was potentially reachable, then C might be reloaded. One could never ensure that this would not happen. Even if the class was not referenced by any other currently loaded class, it might be referenced by some class or interface, D, that had not yet been loaded. When D is loaded by C's defining loader, its execution might cause reloading of C.
Reloading may not be transparent if, for example,
the class has static
variables (whose state would be lost), static
initializers (which may have side effects), or native
methods (which
may retain static state). Furthermore, the hash value of the Class
object is dependent on its identity. Therefore it is, in general,
impossible to reload a class or interface in a completely transparent
manner.
Since we can never guarantee that unloading a class or interface whose loader is potentially reachable will not cause reloading, and reloading is never transparent, but unloading must be transparent, it follows that one must not unload a class or interface while its loader is potentially reachable. A similar line of reasoning can be used to deduce that classes and interfaces loaded by the bootstrap loader can never be unloaded.
One must also argue why it is safe to unload a class C if its defining class loader can be reclaimed. If the defining loader can be reclaimed, then there can never be any live references to it (this includes references that are not live, but might be resurrected by finalizers). This, in turn, can only be true if there are can never be any live references to any of the classes defined by that loader, including C, either from their instances or from code.
Class unloading is an optimization that is only significant for applications that load large numbers of classes and that stop using most of those classes after some time. A prime example of such an application is a web browser, but there are others. A characteristic of such applications is that they manage classes through explicit use of class loaders. As a result, the policy outlined above works well for them.
Strictly speaking, it is not essential that the issue of class unloading be discussed by this specification, as class unloading is merely an optimization. However, the issue is very subtle, and so it is mentioned here by way of clarification.


| « PreviousNext » | |
| Did this page help you? Yes | No | Tell us about it... |
The following table describes the important changes to the documentation since the last release of AWS CloudFormation.
API Version: 2010-05-15
Latest documentation update: December 30, 2013
| Change | Description | Release Date | ||
|---|---|---|---|---|
|
Auto Scaling update |
You can specify an instance ID for an Auto Scaling group or launch configuration. You can also specify additional Auto Scaling block device properties. For more information, see AWS::AutoScaling::AutoScalingGroup or AWS::AutoScaling::LaunchConfiguration. |
December 30, 2013 |
||
|
Amazon SQS update |
You can update Amazon SQS queues and specify additional properties. For more information, see AWS::SQS::Queue. |
December 30, 2013 |
||
|
Limit increases |
You can specify up to 60 parameters and 60 outputs in your AWS CloudFormation templates |
December 30, 2013 |
||
|
New console |
The new AWS CloudFormation console adds features like auto-refreshing stack events and alphabetical ordering of stack parameters. |
December 19, 2013 |
||
|
Cross-zone load balancing |
With cross-zone load balancing, you can route traffic to back-end instances across all Avalibility Zones. For more information, see AWS::ElasticLoadBalancing::LoadBalancer. |
December 19, 2013 |
||
|
AWS Elastic Beanstalk environment tiers |
You can specify whether AWS Elastic Beanstalk provisions resources to support a web server or to handle background-processing tasks. For more information, see AWS::ElasticBeanstalk::Environment. |
December 19, 2013 |
||
|
Resource names |
You can assign names (physical IDs) to the following resources:
For more information, see Name Type. |
December 19, 2013 |
||
|
VPN support |
You can enable a virtual private gateway (VGW) to propagate routes to the routing tables of a VPC. For more information, see AWS::EC2::VPNGatewayRoutePropagation. |
November 22, 2013 |
||
|
Conditionally create resources and assign properties |
Using input parameters, you can control the creation and settings of designated stack resources by defining conditions in your AWS CloudFormation templates. For example, you can use conditions to create stack resources for a production environment. Using the same template, you can create similar stack resources with lower capacity for a test environment. For more information, see Condition Functions. |
November 08, 2013 |
||
|
Prevent accidental updates to stack resources |
You can prevent stack updates that might result in unintentional changes to stack resources. For example, if you have a stack with a database layer that should rarely be updated, you can set a stack policy that prevents most users from updating that database layer. For more information, see Prevent Updates to Stack Resources. |
November 08, 2013 |
||
|
Name resources |
Instead of using AWS CloudFormation-generated physical IDs, you can assign names to certain resources. The following AWS CloudFormation resources support naming:
For more information, see Name Type. |
November 08, 2013 |
||
|
Assign custom resource types |
In your templates, you can specify your own resource type for AWS CloudFormation custom
resources ( |
November 08, 2013 |
||
|
Add pseudo parameter |
You can now refer to the AWS AccountID inside AWS CloudFormation templates by referring
to the |
November 08, 2013 |
||
|
Specify stacks in IAM policies |
You can allow or deny IAM users, groups, or roles to operate on specific AWS CloudFormation stacks. For example, you can deny the delete stack action on a specific stack ID. For more information, see Controlling Access with AWS Identity and Access Management. |
November 08, 2013 |
||
|
Federation support |
AWS CloudFormation supports temporary security credentials from IAM roles, which enable scenarios such as federation and single sign-on to the AWS Management Console. You can also make calls to AWS CloudFormation from Amazon EC2 instances without embedding long-term security credentials by using IAM roles. For more information about AWS CloudFormation and IAM, see Controlling Access with AWS Identity and Access Management. |
October 14, 2013 |
||
|
Amazon RDS read replica support |
You can now create Amazon RDS read replicas from a source DB instance. For more information, see the SourceDBInstanceIdentifier property in the AWS::RDS::DBInstance resource. |
September 24, 2013 |
||
|
Associate public IP address with instances in Auto Scaling group. |
You can now associate public IP addresses with instances in an Auto Scaling group. For more information, see AWS::AutoScaling::LaunchConfiguration. |
September 19, 2013 |
||
|
Additional VPC support. |
AWS CloudFormation added several enhancements to support VPC and VPN functionality:
|
September 17, 2013 |
||
|
Redis and VPC security groups support for Amazon ElastiCache. |
You can now specify Redis as the cache engine for an ElastiCache cluster. You can also now assign VPC security groups to ElastiCache clusters. For more information, see AWS::ElastiCache::CacheCluster. |
September 3, 2013 |
||
|
Parallel stack creation, update and deletion, and nested stack updates. |
CloudFormation now creates, updates, and deletes resources in parallel, improving the operations' performance. If you update a top-level template, CloudFormation automatically updates any nested stacks that have changed. For more information, see AWS CloudFormation Stacks Updates. |
August 12, 2013 |
||
|
VPC security groups can now be set in AWS RDS instances |
You can now assign VPC security groups to an Amazon RDS instance with AWS CloudFormation. For more information, see the VPCSecurityGroups property in AWS::RDS::DBInstance. |
February 28, 2013 |
||
|
Rolling Deployments for Auto Scaling Groups |
AWS CloudFormation now supports update policies on autoscaling groups, which describe how instances in the autoscaling group are replaced or modified when the auto scaling group adds or removes instances. You can modify these settings at stack creation or during a stack update. For more information and an example, see UpdatePolicy. |
February 20, 2013 |
||
|
Cancel and Rollback Action for Stack Updates |
AWS CloudFormation supports the ability to cancel a stack update. The stack must be in the UPDATE_IN_PROGRESS state when the update request is made. More information is available in the following topics:
|
February 20, 2013 |
||
|
EBS-Optimized Instances for Auto Scaling Groups |
You can now provision EBS-optimized instances in auto scaling groups for dedicated throughput to Amazon EBS in autoscaled instances. The implementation is similar to that of the previously released support for optimized EBS EC2 instances. For more information, see the new |
February 20, 2013 |
||
|
New Documentation |
AWS::EC2::Instance now provides a BlockDeviceMappings property to allow you to set block device mappings for your EC2 instance. With this change, two new types have been added: |
December 21, 2012 |
||
|
New Documentation |
New sections have been added to describe the procedures for creating and viewing stacks using the recently redesigned AWS Management Console. You can find them here: |
December 21, 2012 |
||
|
New Documentation |
Custom resources are special AWS CloudFormation resources that provide a way for a template developer to include resources in an AWS CloudFormation stack that are provided by a source other than Amazon Web Services. The custom resource provider can be either a template developer or a separate third-party resource provider. Information about custom resources is provided in the following topics: |
November 15, 2012 |
||
|
Updated Documentation |
AWS CloudFormation now supports specifying provisioned I/O operations per second (IOPS) for Amazon RDS instances. You can set this value from 1000–10,000 in 1000 IOPS increments by using the new Iops property in AWS::RDS::DBInstance. For more information about specifying IOPS for RDS instances, see Provisioned IOPS in the Amazon Relational Database Service User Guide. |
November 15, 2012 |
||
|
New and Updated Documentation |
Reorganization of topics to more clearly provide specific information about using the AWS Management Console and using the AWS CloudFormation command-line interface (CLI). Information about tagging AWS CloudFormation stacks has been added to the documentation, including new guides and updated reference topics:
New information about working with Windows Stacks: New topic: Using Regular Expressions in AWS CloudFormation Templates. |
August 27, 2012 |
||
|
New Feature |
AWS CloudFormation now provides full support for Virtual Private Cloud (VPC) security with Amazon EC2. You can now create and populate an entire VPC with every type of VPC resource (subnets, gateways, network ACLs, route tables, and so forth) using a single AWS CloudFormation template. Templates can be downloaded that demonstrate new VPC features:
Documentation for the following resource types has been updated: New resource types have been added to the documentation: |
April 25, 2012 |
||
|
New Feature |
AWS CloudFormation now allows you to add or remove elements from a stack when updating it. AWS CloudFormation Stacks Updates has been updated, and a new section has been added to the walkthrough: Change the Stack's Resources, which describes how to add and remove resources when updating the stack. The reference topics: ElasticBeanstalk ConfigurationTemplate, and ElasticBeanstalk OptionSettings Property Type, have been significantly updated in response to developer requests for more information. |
April 13, 2012 |
||
|
New Feature |
AWS CloudFormation now provides support for resources in an existing Amazon Virtual Private Cloud (VPC). With this release, you can:
|
February 2, 2012 | ||
|
New Feature |
You can now update properties for the following resources in an existing stack:
For the full list of updateable resources and details about things to consider when updating a stack, see AWS CloudFormation Stacks Updates. |
February 2, 2012 | ||
|
Restructured Guide |
Reorganized existing sections into new sections: Working with AWS CloudFormation Templates and Managing Stacks. Moved Template Reference to the top level of the Table of Contents. Moved Estimating the Cost of Your AWS CloudFormation Stack to the Getting Started section. |
February 2, 2012 | ||
|
New Content |
Added three new sections:
|
February 2, 2012 | ||
|
New Feature |
AWS CloudFormation now provides the aws cloudformation list-stacks command, which enables you to list stacks filtered by stack status. Deleted stacks can be listed for up to 90 days after they have been deleted. For more information, see Describing and Listing Your Stacks. |
May 26, 2011 | ||
|
New Features |
The aws cloudformation describe-stack-resources and aws cloudformation get-template commands now enable you to get information from stacks which have been deleted for 90 days after they have been deleted. For more information, see Listing Resources and Retrieving a Template. |
May 26, 2011 | ||
|
New Link |
AWS CloudFormation endpoint information is now located in the Amazon Web Services General Reference. For more information, go to Regions and Endpoints in Amazon Web Services General Reference. |
March 1, 2011 | ||
|
Initial Release |
This is the initial public release of AWS CloudFormation. |
February 25, 2011 |


Solid is not blockchain
Interoperability with Solid and blockchain technologies
Solid is not blockchain
Interoperability with Solid and blockchain technologies
Who am I?
Arne Hassel
Core Contributor to the Solid project
Senior front-end developer at
inrupt
© CERN
© Tim McDonagh
Solid to the rescue
Linked Data og RDF
WebID
WebID-TLS, WebID-OIDC
Web Access Control (WAC)
Read and write
Social Web App Protocols
And much, much more
Decentralize all the data!
© Ruben Verborgh
Reuse data across applications
© Ruben Verborgh
Create new ways of innovation
© Ruben Verborgh
So what about blockchain?
© Kaboompics.com
Learn more & join us!
solid.inrupt.com
gitter.im/solid
forum.solidproject.org


Updates:
(latest version is Sun Apr 21 2019)
Aaryan is the Supreme Leader of the UniverseTomer will execute all who defy the crown.


LIAR LIAR A film review by Michael John Legeros Copyright 1997 Michael John Legeros
(Universal) Directed by Tom Shadyac Written by Paul Guay and Stephen Mazur Cast Jim Carrey, Maura Tierney, Justin Cooper, Jennifer Tilley, Cary Elwes, Amanda Donohoe, Swoosie Kurtz MPAA Rating "PG-13" Running Time 87 minutes Reviewed at Mission Valley Cinemas, Raleigh, NC (19MAR97)
==
This crowd-pleasing comedy-fantasy stars Jim Carrey as a lawyer who must tell the truth for 24 hours. His son makes a birthday wish and, poof, magic happens. Just like a Penny Marshall movie. And, because dad is played by Plastic Man, he can't simply speak the truth. He has to shout it, or spit it, or contort his body to express it. LIAR, LIAR is as predictable as its one-joke premise suggests, with Carrey on only a slightly shorter leash than usual. Though the occasional bit is side- splitting-- a board-room roast, a violent double-take or two, and the definitive answer to "how's it hangin'?"-- there's little here that we haven't seen (or heard) before. Well, okay, he's never tried to tug at our hearts, which is what happens at the end, easily the worst part of the movie. Thank God for the outtake reel, rolled over the closing credits.
Grade: B-
Notes =====
LIAR, LIAR was screened at Mission Valley Cinemas, in Raleigh. Fifteen minutes passed before the correct lens was installed. And the rude people in the row behind me were expectedly hostile, when I sug- gested that they continue their conversation after the movie.
-- Mike Legeros - Raleigh, NC, USA, Earth<EMAIL_ADDRESS>(h) -<EMAIL_ADDRESS>(w) I'm also on the Web! http://www.pagesz.net/~legeros/
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


--- permalink: /staff/banners/index.html ---
Fill, previous event: Event slot:
Title: Game: Type: Auto live-alert: Ping None Ping @here Ping @everyone Description: External Link: Banner Image: Sponsor: --- MindGames
Modes: Stages: Items:
Date: Start: : in time zone: Duration: min.
events.json data Copy to Clipboard Event boundary times (for local time for Discord built-in events): NA - NA Discord built-in events blurb Copy to Clipboard Direct link (valid only after publishing):
events.json
Have a nice day :)


{% extends "base.html" %} {% block title %}Willamette Randonneurs{% endblock %} {% block pagehead %} Willamette Randonneurs
{% endblock %} {% block subhead %}{% endblock %} {% block pagecss %} {% endblock %} {% block content %}Willamette Randonneurs is a group of randonneurs and those interested in randonneuring in the southern Willamette Valley and surrounding areas. Willamette Randonneurs was formed in late 2016, with our first official season in calendar year 2017.
The regional brevet admistrator (RBA) for our region is Michal Young.
Informal news and announcements often appear in our Facebook group Eugene Area Randonneurs or on our Facebook page Willamette Randonneurs. For those who prefer email forums to Facebook, I will do my best to cross post to our will-rando group, and to respond to posts there.
Randonneuring, also known as audax, is long-distance, mostly unsupported cycling. (more)
We expect to hold a full brevet season in 2023, with each distance offered before the deadline for qualifying for Paris-Brest-Paris (PBP). If you are building a qualifying series for PBP, we suggest planning first and second chances at each distance by combining Willamette Randonneurs events with events offered by Seattle International Randonneurs and Oregon Randonneurs.
Susan Otcenas has established a shared Spotwalla event tracking page for Will-Rando events. If you carry a satellite tracker (Spot, Garmin InReach, Zoleo) or a mobile phone running Bubbler GPS or SWTracker, you can add your track to an event.
Coming soon: Protocol for when to add yourself and when a track will be active.
Add your tracker to the upcoming event.
View rider tracks for the current event.
ACP-sanctioned events are set in September of the preceding year. RUSA-sanctioned events, including populaires as well as brevets, can be added with relatively short notice. Only ACP-sanctioned brevets count toward qualifying for Paris-Brest-Paris.
| {{ "2023-03-18" | fmtdate }} | ACP 200k brevet. 7:30am start outside Palace (Full City) Coffee, 842 Pearl Street, Eugene. Five Rivers 200k (ACP). Eugene to Walterville, Sweet Home, Lebanon, Brownsville, Eugene. $8 charge. |
| {{ "2023-04-02" | fmtdate }} | ACP 200k brevet. World's Tallest Sugarpine #2, starting and ending in Winston, OR. $8 charge. Starts 7:00am by the Cheetah at the intersection of Hwy 99 and Hwy 42 (NW Douglas Blvd) in Winston, OR. |
| {{ "2023-04-30" | fmtdate }} | Flèche weekend with Seattle International
Randonneurs. This is not a Will-Rando event, but we hope to have at
least one team of Will-Rando riders participating. A flèche is excellent training for night riding at Paris-Brest-Paris. |
| {{ "2023-05-07" | fmtdate }} | ACP 200k brevet. Alsea Loop, starting and finishing in Eugene, OR. |
| {{ "2023-05-27" | fmtdate }} evening start (overnight). | ACP 400k and 200k brevets,
starting Saturday evening 8pm in Eugene.
Mezza Luna 200k starts Saturday evening in Eugene
and finishes Sunday morning in Forest Grove. The route is the
first half of the Lunar 400k.
Lunar 400k starts Saturday evening in Eugene and finishes Sunday
afternoon or evening in Eugene. Note Monday is the Memorial Day holiday,
so many riders should be able to travel Saturday to Eugene, ride Saturday
night and Sunday, and return Monday to be at work Tuesday without missing
a day of work. Moon phase should be first quarter. If you plan to ride PBP in August, we strongly suggest you include at least one overnight brevet in your training plan. Register by 25 May. |
| {{ "2023-06-17" | fmtdate }} | ACP 300k and 600k starting Saturday morning in Eugene.
Smith River Loop 300k goes to west to Florence, south to Reedsport, and
returns to Eugene via Smith River Road and Wolf Creek. Smith River 600k
follows the same route for approximately 150 miles, but stays on Siuslaw
River Road through Lorane to Cottage Grove, then north to Eugene for
a loop north and through Independence. 600k riders may choose to overnight
in Cottage Grove or Eugene. I will also create a shared document for
registered riders to discuss shared overnight lodging and other logistics, so
early registration is advised if you wish to discuss logistics with other riders.
Register by June 15. |
| {{ "2022-03-26" | fmtdate }} | Five Rivers< 200k (ACP). |
| {{ "2022-04-16" | fmtdate }} | Colliding Rivers ACP 200k brevet from Sutherlin, OR. |
| {{ "2022-06-04" | fmtdate }} | Umpqua 300k ACP brevet from Cottage Grove, OR |
| {{ "2022-06-11" | fmtdate }} | Smith River 300k ACP brevet and Smith River 600k ACP brevet from Eugene, OR. |
| {{ "2022-07-15" | fmtdate }} | Lunar 400 (ACP 400k) and Mezza Luna (200k) evening start brevets from Eugene, OR. |
| {{ "2022-10-22" | fmtdate }} | ACP 200km brevet, Alsea Loop, virtually in Lviv, Ukraine. |
March events were canceled.
| {{ "2021-04-03" | fmtdate }} | Five Rivers 200k (ACP). |
| {{ "2021-04-17" | fmtdate }} | RUSA populaire (100k). Lunch in Veneta. |
| {{ "2021-05-22" | fmtdate }} | ACP 200km brevet, Alsea Loop. |
| {{ "2021-06-19" | fmtdate }} | Smith River 300k and Smith River 600k. |
| {{ "2021-08-20" | fmtdate }} | Lunar 400 (ACP 400k brevet). |
Due to the Corona virus pandemic, rides in summer 2020 were canceled.
| {{ "2020-02-22" | fmtdate }} | RUSA populaire (100k). Lunch in Veneta. |
| {{ "2020-03-08" | fmtdate }} | RUSA populaire (100k). International Women's Day. |
| {{ "2020-03-21" | fmtdate }} | Five Rivers 200k (ACP). |
|
|
|
|
|
|
|
|
|
| {{ "2020-05-24" | fmtdate }} | |
| {{ "2020-06-06" | fmtdate }} | |
| {{ "2020-06-20" | fmtdate }} | |
| {{ "2020-07-18" | fmtdate }} | |
| {{ "2020-07-31" | fmtdate }} |
| {{ "2019-02-24" | fmtdate }} | RUSA populaire (100k). (Canceled due to weather) |
| {{ "2019-03-09" | fmtdate }} | Five Rivers ACP 200k brevet. |
| {{ "2019-03-30" | fmtdate }} | Cottage Grove — Umpqua Loop ACP 200k. Begins and ends in Cottage Grove and loops south through Drain, Yoncalla, and Tyee, along the Umpqua river, returning north through Sutherlin. |
| {{ "2019-05-25" | fmtdate }} | Evening start 400k (with Monday holiday to recover). Loop north to Forest Grove, beginning and ending in downtown Eugene. |
| {{ "2019-06-08" | fmtdate }} | Smith River ACP 600K. Two loops from downtown Eugene. The first loop will be to Florence, along the coast south to Reedsport, back in via Smith River Road and continuing to Lorane and Cottage Grove, then north to Eugene, about 360k. Second loop will be north to Brownsville, Lebanon, Independence, then south through Albany, Harrisburg, Coburg back to Eugene, about 240k. 5am Saturday start from Mandy's 24-hour diner in downtown Eugene. |
| {{ "2019-06-22" | fmtdate }} | Smith River ACP 300k. A 300km (187 mile) loop from Eugene to Florence via Triangle Lake, south to Reedsport, returning over Smith River Road and Wolf Creek to Eugene, with a staffed control at Oxbow Summit. 5am Saturday start from Mandy's 24-hour diner in downtown Eugene. Finish is at Falling Sky until it closes at 11pm, then at Mandy's. |
| {{ "2018-03-31" | fmtdate }} | Five Rivers ACP 200km brevet. |
| {{ "2018-05-19" | fmtdate }} | ACP 200km brevet, Alsea Loop. |
| {{ "2018-06-16" | fmtdate }} | ACP 300km brevet, Smith River Loop. |
| {{ "2018-07-27" | fmtdate }} | ACP 400km brevet (Lunar 400), Friday night 8pm start. |
| {{ "2017-03-11" | fmtdate }} | Alsea Loop 200k |
| {{ "2017-06-24" | fmtdate }} | Smith River Loop 300k ACP brevet. |
| {{ "2017-08-20" | fmtdate }} | Dart to Darkness Dart Populaire (team ride), 120km to Willamina for the total eclipse. |


About Us
Our Vision
Keep you updated with the latest technologies, help you learn new things and to keep the web free and open to all.
Facts
92
Members
12
Events
9
Sponsers
10
Hard Workers
Events
- All
- Upcoming Events
- Past Events
Node.js Workshop
3 August 2019
HTML, CSS AND Javascript Workshop
5 OCTOBER 2019
Networking Workshop
Past Event
Github Workshop
Past Event
Mozi Tech Talk 2019
Past Event
Hackathon 2019
Past Event
Ethical Hacking Seminar
Past Event
PHP Workshop
Past Event
Typing Contest
Past Event
Android Workshop
Past Event
Mozi Tech Talk 2018
Past Event
UnScript 2018
Past Event
Bash Shell Scripting
Past Event
Our Sponsers
Faculty Incharge
Prof. Mahendra Mehra
Team
Rajesh Manjrekar
CaptainAditya Shrotriya
Vice CaptainDylan Dsouza
Event HeadSherwyn D'souza
WebmasterTresa Pothen
Marketing HeadSamruddhi Shrawne
PR HeadKarishma Potdukhe
SE RepresentativeCarol Mendonca
Logistics InchargeSahaana Iyer
Documentation HeadShreya Bilonikar
TreasurerKamlesh Mistry
Design HeadContact Us
Address
Fr. Conceicao Rodrigues College of EngineeringFr. Agnel Ashram, Bandstand, Bandra (West)
Mumbai, India - 400050.


This week, we're focusing on combinatorics, or counting things! This shows up in competitions all the time, and judges (especially Chip), love writing combinatorics problems. Be careful, integer overflows abound here! You'll need to watch all of your intermediate calculations to make sure they don't get too big.
Here is a counting problem that's very
elegant if written recursively. However, do note that the recursive function that models this problem uses
a second variable aside from k
.
It's also worth noting that this problem is not only recursive, but exhibits Optimal Substructure. That means that it's solution can be computed efficiently from smaller versions of the problem (it's recursive nature). Moreover, it has Overlapping Subproblems, meaning C(k, n) might end up calculating smaller subproblems multiple times. However, Dynamic Programming provides relief to this problem (see the first paragraph, and the "In Computer Programming" section.
Look at this visualization on recursion (in particular the
Fibonacci numbers for n
=5 or 6). Note that F(2)
is calculated multiple times in
the recursion tree. That's the essense of Dynamic programming: Put previously calculated values in a
table so you don't recopy them. The Python dict
or Java HashMap
are
excellent choices for this, but you may need a tuple
Python or custom object as your key in
order to map multiple items (sometimes people use multi-dimensional arrays for that reason).


ZSH
I believe the HISTTIMEFORMAT is for Bash shells. If you're using zsh then you could use these switches to the history command:
Examples
$ history -E
1 2.12.2013 14:19 history -E
$ history -i
1 2013-12-02 14:19 history -E
$ history -D
1 0:00 history -E
2 0:00 history -i
If you do a man zshoptions or man zshbuiltins you can find out more information about these switches as well as other info related to history.
excerpt from zshbuiltins man page
Also when listing,
-d prints timestamps for each command
-f prints full time-date stamps in the US `MM/DD/YY hh:mm' format
-E prints full time-date stamps in the European `dd.mm.yyyy hh:mm' format
-i prints full time-date stamps in ISO8601 `yyyy-mm-dd hh:mm' format
-t fmt prints time and date stamps in the given format; fmt is formatted
with the strftime function with the zsh extensions described for
the %D{string} prompt format in the section EXPANSION OF PROMPT
SEQUENCES in zshmisc(1). The resulting formatted string must be no
more than 256 characters or will not be printed.
-D prints elapsed times; may be combined with one of the options above.
BASH
echo 'export HISTTIMEFORMAT="%d/%m/%y %T "' >> ~/.bash_profile
source ~/.bash_profile
and this is permanent way.


---
layout: post
title: 2/28
date: '2013-02-28T22:41:00.001-07:00'
author: Jacob .
tags:
modified_time: '2013-02-28T22:41:52.511-07:00'
blogger_id: tag:blogger.com,1999:blog-6400085873105072120.post-7950220398645169721
blogger_orig_url: http://www.svlark.com/2013/02/228.html
---
I let it get too late for coherent sentences.
Painting contractors, lesson 72, and South from Alaska today.
238.


VKWebEdit
A simple WebMIDI patch editor for the
Korg Volca Keys
synthesizer.
MIDI Chart
.
Select your MIDI output:
Test Note
Send patch
Save patch
Load patch
Generic
Expression
Voice
Octave
8'
VCO
Detune
Portamento
VCO EG Int
VCF
Cutoff
VCF EG Int
LFO
LFO Rate
LFO Pitch Int
LFO Cutoff Int
EG
EG Attack
EG Decay/Release
EG Sustain
DELAY
Delay Time
Delay Feedback
DISCLAIMER: This is just a personal initiative, useful for me, and hopefully for someone else. If you want to use software to extend you Korg Volca Keys, there are
more complete alternatives
.
Contact
|
GitHub


Genesis 21:8
And the child grew, and was weaned: and Abraham made a great feast the same day that Isaac was weaned.


Files
- file mainpage.dox
- file AlienBase.cpp
- file AlienBase.h Superclass for all alien types. AlienBase has a default population of 10,000 and a increase of 10% for every iteration of the simulation. AlienBase occupies either a Planet or Spaceship.
- file ClassFilter.cpp
- file ClassFilter.h Utility functions for creating new instances of aliens and space objects.
- file EventHandler.cpp
- file EventHandler.h Utility functions for facilitating interactions, updating aliens' population and spawning spaceships.
- file Explosion.cpp
- file Explosion.h Explosions occur when a spaceship loses a battle (either by another spaceship or by occupants of a planet).
- file Galaxy.cpp
- file Galaxy.h A Galaxy is used to store all grid objects required for the simulation. Additionally, Galaxy handles all the computation for updating objects' positions in the grid and interaction between other objects on encounters. All stored objects in the grid will be initialized as nullptrs, which result in an empty space when drawing the simulation. A requirement for all galaxies is a predefined map.txt file. Two are provided to show examples (see Map1.txt, Map2.txt).
- file GalaxyGUI.cpp
- file GalaxyGUI.h GalaxyGUI handles the visualization of the simulation computed by Galaxy class. User can specify the background image, a map (objects to populate in the grid). Moreover, the simulation can be started, stopped, or reset.
- file Greenhouse.cpp Bare planet class. Did not have time to implement differences.
- file Greenhouse.h Bare planet class. Did not have time to implement differences.
- file IceWorld.cpp Bare planet class. Did not have time to implement differences.
- file IceWorld.h Bare planet class. Did not have time to implement differences.
- file main.cpp Runs the galaxy simulation.
- file Orbits.cpp
- file Orbits.h Utility enums and vectors used for handling object movements.
- file Patawlian.cpp Bare alien class. Did not have time to implement differences.
- file Patawlian.h Bare alien class. Did not have time to implement differences.
- file PinkGoblin.cpp Bare alien class. Did not have time to implement differences.
- file PinkGoblin.h Bare alien class. Did not have time to implement differences.
- file Planet.cpp
- file Planet.h A habitable SpaceObject.
- file PurpleGas.cpp Bare planet class. Did not have time to implement differences.
- file PurpleGas.h Bare planet class. Did not have time to implement differences.
- file RockSlide.cpp Bare planet class. Did not have time to implement differences.
- file RockSlide.h Bare planet class. Did not have time to implement differences.
- file Saveela.cpp Bare alien class. Did not have time to implement differences.
- file Saveela.h Bare alien class. Did not have time to implement differences.
- file SpaceObject.cpp
- file SpaceObject.h A superclass used for objects in the grids of Galaxy class.
- file Spaceship.cpp
- file Spaceship.h A spaceship is used when the population of a planet reaches its max capacity. The primary purpose is to occupy other planets through exploration of the galaxy.
- file Star.cpp
- file Star.h A star has planets that orbit around it. Stars are not habitable and spaceships can fly past them without damage.
- file ToxicWasteland.cpp Bare planet class. Did not have time to implement differences.
- file ToxicWasteland.h Bare planet class. Did not have time to implement differences.
- file Zed.cpp Bare alien class. Did not have time to implement differences.
- file Zed.h Bare alien class. Did not have time to implement differences.


Id :
{{form.id(class="form-control restrictsize req",style="height:30px")}}
Auth-Level :
{{form.authlevel(class="form-control restrictsize req",style="height:30px")}}
Phase :
{{form.phase(class="form-control restrictsize req",style="height:30px")}}
Start Date (dd-mm-yy):
{{form.dateStart(class="form-control restrictsize req",style="height:30px",pattern="(0[1-9]|1[0-9]|2[0-9]|3[01])-(0[1-9]|1[012])-[0-9]{2}")}}
End Date (dd-mm-yy):
{{form.dateEnd(class="form-control restrictsize req",style="height:30px",pattern="(0[1-9]|1[0-9]|2[0-9]|3[01])-(0[1-9]|1[012])-[0-9]{2}")}}
Phase Type :
{{form.phaseType(class="form-control restrictsize req",style="height:30px")}}
Goalsheet Level Flag
Gs-assignment :
{{form.gs_enable_assignment}}
If enabled, the Admin will be able to Assign Goalsheet template to Employees
MidYear-Self :
{{form.gs_enable_mid_year_self}}
If enabled the Employee will be able to submit there Mid Year Review or write comment on each Tasks.
MidYear-dc-approve :
{{form.gs_enable_mid_year_dc_approve}}
If enabled the Dc lead will be able to approve reportes Goalsheet form Pending Review to Approved.
EndYear-Self :
{{form.gs_enable_end_year_self}}
If enabled the Employees will be able to submit there End-Year reviews and Comments.
EndYear-dc-approve :
{{form.gs_enable_end_year_dc_approve}}
If enabled the Dc Lead will be able to perform action regarding Goalsheet End-Year review and add feedback.
EndYear-closure :
{{form.gs_enable_assignment}}
If enabled, the Admin will be able to Assign Goalsheet template to Employees
Gs-assignment :
{{form.gs_enable_end_year_closure}}
If enabled the Dc Lead will be able to perform action regarding Goalsheet closure.
Goal Level Flag
Goal-Task-approve :
{{form.gs_enable_assignment}}
If enabled the Dc lead will be able to approve or returned each task individually.
Goal-edit :
{{form.goal_enable_edit}}
If enabled the Employee will be able to Add/Update task in Goals.
Goal-approve :
{{form.goal_enable_approve}}
If enabled the Dc lead will be able to approve Goal of reportees
Task Level Flag
Task-Status-change |
Phase Type |
Task-update :
{{form.task_enable_update}}
If enabled, user will be able to Update existing task present in Goalsheet.
Task-delete :
{{form.task_enable_delete}}
If enabled, user will be able to delete task from Goals.
Task-Activity-edit :
{{form.task_enable_activity_edit}}
If enabled, user will be able to update only activity of existing task.
Task-Status-change :
{{form.task_enable_status_change}}
If enabled, user will be able to change the status of task to anything reflecting in dropdown menu.
{{ form.submit(class="btn btn-success") }}