| ↑ Blog |
Separation between formatted printing to stdout
and string
buffers shall be resolved. Formatted printing to stdout
shall be removed in favor of string buffers.
Moss gets a function and syntax for formatted printing. I will compare it with equivalents from C.
C: printf("(%li,%li)",x,y) Moss: print("({},{})"%[x,y]) C: snprintf(s,N,"(%li,%li)",x,y) Moss: s = "({},{})" % [x,y]
The template syntax will be similar to format
from Python but may differ more or less.
# Here is an example of proper usage: a = list(0..10).map(|x| [x,x^2]) buffer=[] for t in a buffer.push("({},{})"%t) end s = buffer.join("\n") print(s) # More briefly: /*1*/ a = list(0..10).map(|x| [x,x^2]) /*2*/ s = a.map(|t| "({},{})"%t).join("\n") /*3*/ print(s)
We see a practical pattern: a strict separation between actual information structure (1), formatting (2) and stdout (3).
Note: to have advanced output, libraries should be provided that return tables as HTML5, LaTeX2e and plots as PNG, SVG as automatically as possible. Whole documents or books (libraries?) could be generated automatically from data. But one must say to this, that HTML5 is more easy to use than LaTeX2e.
As sets are a special case of maps (dictionaries) and set operations do not interfere with map operations, them can be joined. Maps with values absent can be considered as sets:
{1, 2} == {1: null, 2: null}
Multisets cannot be included as well, because
they introduce problems. For example, '==
' behaves
differently if there are keys with m[key]==0
.
But it is clear that maps may be used as internal data
structures of multisets. An alternative is, to simply monkey patch
the necessary operations into Map
(Map
is the data type of maps).
A syntactical sugar for assignments to function applications is added to the language.
1. a.m()=y is equivalent to a.set_m(y) 2. a.m(x1,...,xn)=y is equivalent to a.set_m(x1,...,xn,y) 3. a.m(x) = y1,y2 the same as a.m(x)=[y1,y2] and therefore equivalent to a.set_m(x,[y1,y2]) 4. a.m1(),a.m2() = t is not possible (t=[y1,y2]) 5. a[i]()=y is not possible
The point in (4) is that the language should be minimalistic and (4) would blow it up. It is definitely much harder to implement than (1,2,3) which required less than 40 lines of code.
There is a problem with standard printing of floating point numbers. For example, one can get
> list(0..1:0.2) [0.0, 0.2, 0.4, 0.6000000000000001, 0.8, 1.0]
So we can have output of the form 000000000...some digit and (under other circumstances) 999999999...some digit. This is because of printf("%.16g\n",x). In most cases one has engineering tasks and does not suffer from slightly lower precision. So I think I will change that to %.14g to make output more stable. One can always get full precision by "{g16}"%[x] or even "{g17}"%[x]. (#include <float.h>: DBL_DECIMAL_DIG==17)
It is clear for me now, that the Moss interpreter must be rewritten in Rust. I have to struggle with segmentation faults too often. The security goals are:
Security (1). Maybe it is possible to achieve a memory safe implementation.
Security (2). Access to files will be realized by a mandatory access control system. In that system the main program obtains a right to access files in some path. This right is given explicitly to the subprograms that do the task. The difference to the flat model is, that in the flat model a third party library routine can do anything, once the main program got the right.
Security (3). What makes the most headache is a general call of shell commands. Any call of an external program (e.g. in a scripting language) can undermine the access control system. Thus such a call is ill behaved and shall only be possible in the unsafe mode. Ideally, the unsafe mode is made forbidden outside of a sandbox environment.
Update (2018-03-22). The interpreter kernel is ported to Rust, it's construction was successful and is is almost complete now. There were some pitfalls, interesting ones, but it was possible to take them into account. The most interesting pitfalls are:
env
has to be given
to every Rust function that needs to call a Moss function or needs to
have access to the RTE (runtime environment). This is
much less obfuscated than handling global variables.
gtab
(table of global variables) of its module. And the module has a
pointer to this function. Therefore we have a cyclic data structure
that turns out to be a memory leak.
One could have used a weak pointer, but that would have made things
complicated. The best solution was to add a destructor at the
destruction of the interpreter that clears the gtabs.
A small difficulty remains: If a module shall be unloaded properly
sooner than at the ending of the main program,
this destructor must be called explicitly.
Drop
, Eq
,
Hash
cannot take env
,
nor can they return error information. A solution I have found for
env
is to store a RTE pointer in a table object
(the implementation is inside of TableExtra
), and to
store a stack of alternative calling environments in the RTE.
This is my worst problem so far, but it only affects custom Moss
destructors and hashables.
Security goal (1) is achieved, the interpreter is memory safe, provided Rust is sound, the Rust compiler produces safe code and each used FFI (foreign function interface) is safe. It is also possible to make it almost completely logically safe in terms of overflow checks (there is a compiler option for that). There are some remaining overflows from integer casts that should be audited. Inline functions can be used to abstract this, making the overflow checks optional.
Security goals (2) and (3), running untrusted code by a capability-based security model, are much harder to achieve, because this security model is deeply connected to privateness and immutability of data. For file access, a model with sandbox directories seems to be, albeit less fine grained, easier to achieve without loopholes.
The standard syntax for formal self-arguments has a problem. The following is not possible, bacause the inner self-argument shadows the outer one:
Function.o = |f| |x| self(f(x))
One is forced to write instead:
Function.o = fn|f| g = self return |x| g(f(x)) end
This problem occurs often if one uses methods, because closures and higher order functions are frequently used. Now the idea is, to separate the self-argument via an semicolon from the other arguments. For actual arguments this syntax is already possible, but I will provide it also for formal arguments. Then we have:
Function.o = |g;f| |x| g(f(x))
What is the difference between what follows? Firstly:
m = load("m")
And secondly:
m = eval(read("m.moss"))
Behavior is different, because eval
returns a value rather than a module object. But the question that
comes into mind is: should they be equivalent? In order to achieve
that, in a module a module object should be returned explicitly rather
than implicitly. This would also solve another problem: How to
state a module that consists only of a single class or a single
function (e.g. to achieve advanced lazy loading and lazy
evaluation)? The problem here is an oddly looking import statement:
use class_name: class_name # vs. use class_name
Note that eval
can be made quite powerful. It can
take an additional argument that specifies information about
the environment. For example, global variable of the environment
are used by default by eval
. If a module would be loaded,
eval
had to take an empty environment.
The interpreter already supports default arguments for
build in functions. Now a function's argument count can simply be
a range. Not given arguments will be filled out with
null
. Now
function f(x,y=expression)
is simply syntactic sugar for
function f(x,y=null) if y is null then y=expression end
An implementation is straightforward:
Now construct (or compile in this order):
* block-node * if-node-1 * if-node-2 ... * if-node-n * body-node
Easy going. At next, default named arguments are stated as follows:
function f(x,m={}) a = m["a"] if "a" in m else a0 b = m["b"] if "b" in m else b0 # ... end
That's clumsy. I believe, default named arguments are very important for usability and thus should be supported by the language. Now let
{a=a0, b=b0} = m
be syntactic sugar for
a = m["a"] if "a" in m else a0 b = m["b"] if "b" in m else b0
Without default arguments it should be more strict: Let
{a,b} = m
be syntactic sugar for
a = m["a"]; b = m["b"]
I call this the map unpacking statement.
It took me 100 lines of C code to implement map unpacking, including construction of a temporary variable if the right hand side is an expression. I think it was a worthwhile effort.
Finally it can be moved into the arguments list:
function f(x,{a=a0,b=b0}) # ... endas syntactic sugar for
function f(x,_m0_) {a=a0,b=b0} = _m0_ # ... end
Furthermore,
function f([x,y]) # ... end
is syntactic sugar for
function f(_t0_) x,y = _t0_ # ... end
In addition I achieved (by 30 lines of C code) syntactic sugar for named actual arguments:
f(x,y,a=e1,b=e2) ≡≡ f(x,y,{a=e1,b=e2})
They may appear in any order, independently from positional arguments. That is a little more welfare than simply omitting the curly brackets.
At first I recall that
begin ... end
is syntactic sugar for:
fn|| ... end()
Often we want to create a local variable, use it in one or more functions, and forget it afterwards. Thus we want to have a local scope, so that the variable does not exist outside of this scope. In Moss I have used this ugly construction so far:
f = begin n = 42 return |x| n*x end
But if one wants to bind some value to more than one function, this construction becomes even more unpleasant:
f,g = begin n = 42 f = |x| n*x g = |x| x+n return f,g end
In Lua it is possible to restrict variables to a local scope:
do local n = 42 function f(x) return n*x end function g(x) return x+n end end print(f(2))
I did not realize until now that this is perfectly possible in my own programming language too:
begin global f,g n = 42 f = |x| n*x g = |x| x+n end print(f(2))
Furthermore, this actually solves the problem of having variables that are restricted to a module.1 And fortunately these variables can be accessed faster, since local variables are stored in a stack frame rather than the map of global variables.
A problem that remains is mutual recursion. In JavaScript this is solved by making it possible to use a local variable that is defined later on. For now, in Moss one would need to switch to global variables for this purpose.
Footnote 1: It would be possible to achieve that
a variable may be declared to be local to a module (module scope).
In C known as a static variable. Such a variable would also
be stored inside an array rather than a map. But to me
begin-end
is nicer and more powerful as it leads
to more fine-grained constructions.
In Moss, a module, for example math, is made available by the following statement:
use math
The implementation so far was an internal import-function that added math to the map of global variables. A change to this behavior will be proposed now. The import-statement will be made syntactic sugar to:
math = load("math")
This has the advantage that math can be a local variable
now. We recapitulate that a private variable is a (can be modeled
as a) local variable of a block (in Moss: begin-end
).
The full syntax is as follows:
# (A) use pathnode.pathnode.m: f,g # (B) use malias=pathnode.pathnode.m: falias=f, galias=g
This is defined to be syntactic sugar to:
# (A) m = load("pathnode/pathnode/m") f = m.f g = m.g # (B) malias = load("pathnode/pathnode/m") falias = malias.f galias = malias.g
In Addition:
use m:* # is meant to be m = load("m") gtab().update(record(m)) # and use(m): f, g # is meant to be (without load) f = m.f; g = m.g
The assert statement was added to the language:
assert condition assert condition, text
It is implemented as syntactic sugar, because text
shall be lazily evaluated. So we have:
if not condition assertion_failed(text) end
Example of usage:
function pow(x,n) assert n: Int and n>=0, "pow(x,n), n: Int, n>=0" y=1 for k in 1..n y=y*x end return y end print(pow(2,-2)) # Assertion failed: pow(x,n), n: Int, n>=0.
A failed assertion results in an ordinary exception that is shown together with a stack trace.
Update. Maybe it is a good idea to enable compilation
of assert statements only in debug mode. Debug mode will be
switched on by "moss -d
". So, if something goes
wrong and a long stack trace is returned, debug mode could be
turned on to inspect the situation further.
If we have a string s
, it is expensive to
create a slice s[i..j]
. But as s
is
immutable, a slice object could be returned, without copying data.
Now we can make every string a slice object, if we say we have a
immutable data array and a (pointer,len)
to a part of it.
 We would need a double allocation. At next, the data array has to contain a reference counter. Ideally the data array is a struct with a flexible array last member. Not to forget that the string object itself needs an independent reference counter.
This sounds more complicated. So what have we won? Now we can take slices and slices of slices without the need of allocating and copying around data. Take into mind the basic algorithm that searches a substring in a string.
Interestingly this is an implementation detail that is transparent to the programming language because strings are chosen to be immutable.
Moving further, such a behavior is also interesting for
dynamic arrays (type List
in Moss). If a slice
is obtained from an array, the arrays length should become immutable.
The information about immutable length, immutable data and
slicing can be modeled as an option type (extra behavior flag),
to separate it from the standard behavior. A problem is again,
that the data array needs an independent reference counter.
Alternatively, we could have a sum type (a tagged union) that chooses whether to point to data or to slice another array.
So, what have we won? Let's take a look on some naive algorithms:
# Naive quicksort qsort = |a| ([] if len(a)==0 else qsort(a[1..].filter(|x| x<a[0]))+[a[0]]+ qsort(a[1..].filter(|x| x>=a[0]))) # Naive sieve of Eratosthenes sieve = |a| ([] if len(a)==0 else [a[0]]+sieve(a[1..].filter(|x| x%a[0]!=0)))
Many huge copies are created by a[1..]
.
The algorithms could be made a bit more quick and memory
friendly, but it hardly is worthwhile as these algorithms are
terribly inefficient.
In Moss, the index operations a[i]
, m[key]
are strict. If i
is out of bounds or key
is not found, an exception will be thrown. Now we could introduce
sloppy index operations a(i)
, a(key)
,
that return null
if i
is out of bounds or
key
is not found. That's right, we simply overload the
function call operator.
Furthermore we introduce the null coalescing operator as
"a or else b
". Now these to statements are
semantically equivalent:
y = m[key] if key in m else x y = m(key) or else x
In both statements, x
is lazily evaluated.
In Moss, there is the member access operation "a.x
".
One can have reflection this way:
y = record(a)["x"]
Here the problem emerges, that the ordinary index operation
does not respect the prototype chain. Now we find, that an
expression "a.x
" is parsed into an AST
(dot a "x")
. But the compiler
ever since the beginning was able to compile the more general
AST (dot a x)
where a
and x
are arbitrary expressions. The recursive descent may simply take an
atom after the dot. Thus I will introduce the general syntax
"a.(x)
". So, adding very few lines to the compiler allows
us nice reflection with respect to the prototype chain. For clarity,
we have:
a.x ≡≡ a.("x")
The basic idea for the object system of Moss is so far, that
the type and prototype of an object coincide. A property
(including methods) is searched in the object first,
then in the object's prototype, and then in the prototype's
prototype and so on until null
is reached.
This simple model is shown by this graph:
Now, the problem arises that a type should have an own object-to-string method. But placed somewhere in the prototype chain, it will conflict with the object-to-string method for the type's instances. A solution is to obtain the object-to-string method from the object's type. But in order to do that, the type-prototype coincidence must be removed.
Now, the idea is, not to change the object system, but to patch the coincidence breakage into it. A table object is constructed as follows:
signature = prototype t = table signature{x=value, y=value} ≡≡ table signature({x=value, y=value})
We can have multiple inheritance:
signature = [prototype1, prototype2, ..., prototypeN]
Now, a tuple is used to differentiate between a type and a prototype:
signature = (type, object_name, prototype)
This leads to the following model:
The patched type system looks as follows:
To make things easy, property access only searches the prototype chain. A complicated rule "one left then upwards" will not be used.
For object-to-string, the type name must be stored somewhere, and it should be easy to create a named class. For convenience the tuple is extended by optional elements. The complete signature is:
signature = (type, object_name, prototype, hidden_properties)
A simple example:
Bird = table(Type,"Bird"){ function string "{} is a bird." % [self.name] end, function fly "{} can fly!" % [self.name] end } Duck = table(Type,"Duck",Bird){ function string "{} is a duck." % [self.name] end, function dive "{} can dive!" % [self.name] end } d = table Duck{name = "Donald"} print(d) print(d.fly()) print(d.dive()) print("type: ", type(d)) # Output: # Donald is a duck. # Donald can fly! # Donald can dive! # type: Duck
Not possible in Moss so far is proper lexical scoping.
Proper lexical scoping is a closure capture of an external local
variable from lexical scope by mutable reference. The local variable's
lifetime is increased from 'scope
to
max('scope
, 'closure
).
In Moss, lexically scoped closures are possible, but by capture per cloning. Not possible so far is such a construct:
function main s = 0 (1..4).each(fn|k| s = s+k end) print(s) end
The outer and inner s
are two different variables
because of a cloning at closure creation. Thus, the outer
s
will not be modified. How to solve this problem?
At first let me explain how I implemented closures. I will use
f = |x,y| |z| x+y+z
as an example to examine what is happening. This is transformed into the following pseudo-Moss:
f = fn|x,y| _t = [x,y] return fn(_t)|z| t[0]+t[1]+z end end
After transformation one can see why nothing happens:
function main s = 0 _t = [s] (1..4).each(fn(_t)|k| _t[0] = _t[0]+k end) print(s) end
Now, the idea is to regard the situation as a move of
s
into _t
. Thus also in outer scope,
we need to replace every occurrence of a captured variable
by _t[i]
. In this case, print(s)
is replaced by print(_t[0])
.
Closure chains are not problematic:
function main s = 0 _t = [s] (1..4).each(fn(_t)|k| _t[0] = _t[0]+k end) _t = [_t[0]] (1..4).each(fn(_t)|k| _t[0] = _t[0]+k end) print(_t[0]) end
Closure nesting is more problematic:
function main s = 0 _t1 = [s] (1..4).each(fn(_t1)|i| _t2 = [_t1[0]] (1..4).each(fn(_t2)|j| _t2[0] = _t2[0]+i*j end) # lifetime of _t2 ends here end) print(_t2[0]) end
This is not possible, because the lifetime of _t2
is not long enough. There is more than one possible solution
to this problem. We have to take in mind that all of this
is about lexical scoping. Because of this situation, we could
simply move _t2
into the outmost local scope:
function main s = 0 _t1 = [s] _t2 = [] (1..4).each(fn(_t1)|i| _t2.push(_t1[0]) (1..4).each(fn(_t2)|j| _t2[0] = _t2[0]+i*j end) end) print(_t2[0]) end
Again, difficulties arise when nesting and chaining are combined.
For convenience, in some higher order functions there was automatic list unpacking:
scalar_product = |v,w| zip(v,w).sum(|x,y| x*y) = |v,w| zip(v,w).sum(|t| t[0]*t[1])
This is not possible in general and thus is removed in favor of explicit unpacking:
scalar_product = |v,w| zip(v,w).sum(|[x,y]| x*y)
For argument list unpacking there was so far:
f(1,2) ≡≡ f.apply([1,2])
This approach has the drawback that self arguments must be given explicitly:
x.m(1,2) ≡≡ x.m.apply(x;[1,2]) /*but not*/ x.m.apply([1,2])
Due to this reason, f.apply(a)
is replaced
by f(*a)
.
Surprisingly, the implementation patch
was very short and took me only 30 min. I added the unary prefix operator
"*
" to the recursive descent at the same level
as the unary prefix operators "+ - ~
". Now in AST
compilation we match splat
in these ASTs:
(apply f (splat (list 1 2))), (apply (dot x "m") (splat (list 1 2))), (apply (dot x "m") x (splat (list 1 2))),
and branch to compilation of unpacking apply. There we take
explicit and implicit self arguments into account again.
A new byte code APPLY
is added to the interpreter.
This byte code calls a very short function that takes
f,self,a
from the stack and calls the Rust-Moss
transition env.call(f,self,a)
where env
is a pointer to the calling environment. The very same behavior
was in f.apply(self,a)
.
In before I mused about alternative approaches. One could have unpacked to the object stack and taken a dynamic argument count from the object stack. But firstly this would have made calling slower and secondly would have lead to stack overflow in case of large lists.
The following behavior is not implemented at this point of time:
f(*a,*b) ≡≡ f(*(a+b)), f(x,y,*a) ≡≡ f(*([x,y]+a)) etc.
Thus we need to use the right hand side.
The function call
object(prototype,properties)
is replaced by
table prototype(properties)
Thus we have
T = table{} m = {x=1,y=2} table{x=1,y=2} ≡≡ table null(m) table T{x=1,y=2} ≡≡ table T(m)
In the last week I mused about adding generator comprehensions to the language. From that we receive list, set and dictionary comprehensions as a gift.
The most simple implementation is reduction to syntactic sugar. For example
list(f(x) for x in a)
will be transformed into:
list(fn*|| for x in a do yield f(x) end end)
The more complicated expression
list(f(x,y) for x in a if p(x) for y in b if q(x,y))
will be transformed into:
list(fn*|| for x in a if p(x) for y in b if q(x,y) yield f(x,y) end end end end end)
This could be done directly during syntactic analysis, and done elegantly, the compiler would become only slightly slightly larger by 100 up to 200 lines.
After musing for some time about a capability based security model, I decided to compose a model of irreversible restrictions instead.
Capabilities are the most fine grained model, but are complicated to use because a system environment object has to be given to every function that shall have rights for system access. And this object has to be invisible for other functions. It would be a security hole, if this object is a global variable that could be made visible by an untrusted module.
Because of the emerging complexity, I decided to use a simpler
security model, which allows system access in the old fashion.
Basically, every system access needs to have a capability (a right,
a permission), which is stored in rte
, the internal
runtime environment used in the interpreter. As per default, any file
can be read, but all other system access is prohibited. But running
"moss -unsafe
" instead of "moss
" enters
root mode, allowing for everything. Now, calls to the runtime system
(ordinary Moss functions) place irreversible restriction locks,
that cannot be unlocked anymore. There might be different of such
locks, for example for running shell commands, writing/reading
files, network access and so on. Note that unrestricted call of
shell commands implies writing files and network access too.
If such first few lines of a Moss program are written in a standard style, it is very easy to reason about what the program is allowed to and what not. The interface that these few lines provide, should be as easy and failure tolerant as possible. All default parameters should perform the most restriction.
The insistent drawback of this system is, that it is insecure to load untrusted modules in an authorized program. That is, one cannot have untrusted modules and authorization at the same time.
So, implementing custom getters and setters is not very difficult,
as I have found. Basically one provides a new class object from
a class constructor, but this is an Object::Interface
instead of an Object::Table
. Let me explain,
Interface
is the residual enum variant that contains
a dyn trait pointer, i.e. is the interface to all different kinds
of objects, for example long integers, multidimensional arrays,
file objects etc.
If a table object has such a class object A
as its
prototype, the behavior of the dot operator will be determined by
methods of A
. Ideally, the additional behavior is shadowed
by a branch on Object::Interface
, i.e. against a simple
integer loaded from a pointer. That's a very small runtime penalty.
Implementing custom destructors is more difficult. Here the
problem arises that function calls need a reference to the calling
environment env
. This reference must be given as an
argument to the destructor. But objects are designed to be destructed
everywhere. A custom Drop
may be implemented, but
drop
takes no additional arguments. Linear typing could
provide additional arguments, but this leads to very ugly code
and changes the overall design.
The solution I came up with is as follows. A class object
A
contains an Rc-pointer to the runtime environment
rte
. If an object is a child of A
, by
calling drop
it will be stored togehter with its
destructor in a buffer inside of rte
. A flag of type
Cell<bool>
inside of rte
will be
set, indicating a non-empty buffer. Now, when returning from a
function, after a branch on the flag, the delayed destructions
are processed, because we have access to env
.
But note, branching at this point is particularly time critical.
Any additional code will affect the calling mechanism and thus
the general interpreter performance. So, one branch on a
Cell<bool>
behind a pointer to a struct
is bearable, but not more. But wait, we can do better.
To circumvent this, there is a slight modification of this technique.
A secondary calling environment will be stored inside of
rte
. A flag in rte
indicates whether
we are in a root destructor. All custom sub-destructions will be
stored in the buffer. After returning from all drops, the buffer will
be processed in the root destructor with the secondary calling
environment. We need to do it this way, because otherwise
sub-destructions would need a third calling environment,
sub-sub-destructions a fourth calling environment and so on.
Don't get confused, but I would consider it somewhat similar
to trampolining tail calls.
A typed programming language Moss is planned, the compiler producing Moss byte code. The syntax will be so similar that both languages will have the same file extension. The typed Moss will only have a few more keywords. For comparison, an example:
function map(a,f) b = [] for x in a b.push(f(x)) end return b end function map[X,Y,n](a: List[X,n], f: X=>Y): List[Y,n]; let mut b: List[Y] = []; for x in a do b.push(f(x)); end return b; end
The dynamic Moss is actually more general, emulated by:
function map(a: List[Object], f: Object=>Object): List[Object]; let mut b: List[Object] = []; for x in a do b.push(f(x)); end return b; end
Another example:
let qsort[T: Ord, n](a: List[T,n]): List[T,n] = [] if a==[] else qsort(a[1..].filter(|x| x<a[0]))+[a[0]]+ qsort(a[1..].filter(|x| x>=a[0]));
Checking for leftover named arguments was very unergonomic so far.
The most flexible design I have figured out employs a wrapper type
Drain
, which depletes the argument map by operator
overloading. This approach is also compatible with default arguments.
use unpack: drain, assert_empty argm = {x=1,y=2,z=3} {x,y} = drain(argm) assert_empty(argm) # Value error: unexpected named arguments: {"z": 3}.
The unpacking may be splitted into parts:
argm = {x=1,y=2} dargm = drain(argm) {x} = dargm {y} = dargm assert_empty(argm)
The unpacking may drain a copy, leaving the original argument map untouched:
m = copy(argm) {x,y} = drain(m) assert_empty(m)
To my pleasure, being a library feature, it holds the interpreter kernel smaller.
So, with the introduction of classes, Moss has got a second slightly different object system. Now this system was made the primary object system, as I have found ordinary named types to be the most common pattern. The prototype based object system is just used very infrequently. Furthermore, the prototype system was unified with the class system, which means that both approaches may be mixed.
For the sake of convenience, a new class literal syntax is introduced:
class Duck = { function quack() print(self.name, " quacks.") end } d = table Duck{name = "Dagobert"} d.quack()
More generally:
class Name = map_object class Name: Parent = map_object class Name: [Parent1,Parent2,...] = map_object
where Parent
is an atomic expression
and map_object
is an expression.
Or as an expression:
class name_string: parent_signature map_object
where name_string
, parent_signature
and map_object
are atomic expressions.
The syntax is just syntactic sugar for:
class_constructor(name_string,parent_signature,map_object)
So the first example is just:
Duck = class_constructor("Duck",null,{ "quack": fn quack|| print(self.name, " quacks.") end })
The algorithms for deep copy can become quite complicated. For example, when there is a non-tree-like graph, the possibility of respecting the graph structure emerges. The operations in such algorithms are actually handled quite well in Moss. For these reasons I have decided to move the functionality out of the interpreter into a library. That makes the interpreter a bit smaller again.
Concerning Unicode identifiers, these were prohibited until now in order not to open the door to homoglyph attacks. It was unclear to me how to deal with them. However, the problem is already present in that strings are also affected, of which the program may be dependent in a sensitive way. Thus the Pandora's box is already open, so to speak. In some editors it may also be possible to hide code in the carriage return or in overlong lines. In addition, ASCII-only does not prevent typosquatting.
For these reasons, as I believe, it makes more sense to check files with an external tool. Such a tool would also be able to scan an entire directory.
Therefore I am inclined to allow Unicode for identifiers as well. For the sake of simplicity this concerns all code points greater than 127. A remaining question is, whether Unicode should be the default mode or be enabled by a command-line option. The former is more convenient while the latter is safer. As ASCII-only input in default mode would be a strong convenience regression, it seems better to me to allow Unicode in default mode. A bad stomach feeling remains.


Search Widget Demo Page
(Custom Element Version)
The following panel is implemented as a Custom Element called search-widget


Quick Start¶
You can easily start using spark-crowd
through our docker image or through spark-packages.
See Installation, for all installation alternatives (such as how to add the package as a dependency in your project).
Start with our docker image¶
The quickest way to try out the package is through the provided docker image with the latest version of our package, as you do not need to install any other software (apart from docker).
docker pull enriquegrodrigo/spark-crowd
Thanks to it, you can run the examples provided along with the package. For example, to run DawidSkeneExample.scala we can use:
docker run --rm -it -v $(pwd)/:/home/work/project enriquegrodrigo/spark-crowd DawidSkeneExample.scala
You can also open a spark shell with the library preloaded.
docker run --rm -it -v $(pwd)/:/home/work/project enriquegrodrigo/spark-crowd
By doing that, you can test you code directly. You will not benefit from the distributed execution of Apache Spark, but you are still able to use the algorithms with medium-sized datasets (since docker can use several cores in your machine).
Start with spark-packages¶
If you have an installation of Apache Spark you can open a spark-shell with our package pre-loaded using:
spark-shell --packages com.enriquegrodrigo:spark-crowd_2.11:0.2.1
Likewise, you can submit an application to your cluster that uses spark-crowd using:
spark-submit --packages com.enriquegrodrigo:spark-crowd_2.11:0.2.1 application.scala
To use this option you do not need to have a cluster of computers, you can also execute the code from your local machine because Apache Spark can be installed locally. For more information on how to install Apache Spark, please refer to its homepage.
Basic usage¶
Once you have chosen a procedure to run the package, you have to import the method that you want to use as well as the types for your data, as you can see below:
import com.enriquegrodrigo.spark.crowd.methods.DawidSkene
import com.enriquegrodrigo.spark.crowd.types.MulticlassAnnotation
val exampleFile = "examples/data/multi-ann.parquet"
val exampleData = spark.read.parquet(exampleFile).as[MulticlassAnnotation]
//Applying the learning algorithm
val mode = DawidSkene(exampleData)
//Get MulticlassLabel with the class predictions
val pred = mode.getMu().as[MulticlassLabel]
//Annotator precision matrices
val annprec = mode.getAnnotatorPrecision()
You can find a description of the code below:
- First the method and the type are imported, in this case
DawidSkene
andMulticlassAnnotation
. The type is needed as the package API only accepts typed datasets for the annotations. - Then the data file (provided with the package) is loaded. It contains annotations for different examples. As you
can see, the examples uses the method
as
to convert the Spark DataFrame in a typed Spark Dataset (with type MulticlassAnnotation). - To execute the model and obtain the result, you can use the model name directly.
This function returns a
DawidSkeneModel
, which includes several methods to obtain results from the algorithm. - The method
getMu
returns the ground truth estimations made by the model. - We use
getAnnotatorPrecision
to obtain the annotator quality calculated by the model.
You can consult the models implemented in this package in Methods, where you can find a link to the original article for each algorithm.


Take a selfie before
Inventory
You failed. Your followers have forgotten you... forever...
Retry ?
Welcome to How I Saved The Internet!
To play, use Arrow-Keys to move.
Good Luck!
Start
Well done! You find everything! Mmmmh... Nope, we can't do anything here, you will have to call the hotline! Bye!
¯\_(ツ)_/¯
Play again? (Really?)


1 write to _wReserved
System.Management.Automation (1)
engine\ComInterop\ExcepInfo.cs (1)
53
_wReserved
= -1; // to ensure that the method gets called only once
1 reference to _wReserved
System.Management.Automation (1)
engine\ComInterop\ExcepInfo.cs (1)
52
System.Diagnostics.Debug.Assert(
_wReserved
!= -1);


Enumeration IncomingMessageType
Enumeration members
DeliveryReceipt
DeliveryReceipt: = 6
MessageReaction
MessageReaction: = 3
MessageRegular
MessageRegular: = 0
MessageReply
MessageReply: = 1
MessageUnsend
MessageUnsend: = 2
ReadReceipt
ReadReceipt: = 7
ThreadEvent
ThreadEvent: = 4
TypingIndicator
TypingIndicator: = 5
UserPresence
UserPresence: = 8


Hi. My name is Beet. Please don't freak out. I know who you are, but probably, you may not know who am I. I like to introduce myself as, a "friend". I've been keeping track of your progress as a security engineer, and let me say that I think you're phenomenal, and that's why I need your help.
Although you're great at what you do, you are working for the wrong people. And I know you know this deep inside yourself. For years, one of your clients Evil Enterprise has been mocking people out, leading them to believe that what they "own" really belongs to them. This is a pile of bulls*it. Pardon my french.
I've been trying for a while to wipe out Evil Enterprise once and for all. I've almost acomplished this, but this path I've followed has led me to dangerous roads. If you're reading this, well I'm probably... well hidden in some nice cave out there. But that's exactly the problem. I don't have the means to finish this journey. But with your help, we can get rid of this pile of wise asses over there. If we manage to wipe out all of their information from their main server and the redundant ones we will make some good for the mankind.
I hope I had made the best decision by contacting you. The future of many humble people is in your hands.
I've left some gifts for you in one of my servers. I've left the details below.
Good luck my friend.
Beet
IP: <IP_ADDRESS>
Username: freakbeet
Password: dinglebingle


This document describes the syntax and semantics of the template engine and will be most useful as reference to those creating Twig templates.
A template is simply a text file. It can generate any text-based format (HTML, XML, CSV, LaTeX, etc.). It doesn’t have a specific extension, .html or .xml are just fine.
A template contains variables or expressions, which get replaced with values when the template is evaluated, and tags, which control the logic of the template.
Below is a minimal template that illustrates a few basics. We will cover the details later on:
<!DOCTYPE html>

<title>My Webpage</title>

{% for item in navigation %}

{{ item.caption }}

{% endfor %}

My Webpage

{{ a_variable }}

There are two kinds of delimiters: {% ... %} and {{ ... }}. The first one is used to execute statements such as for-loops, the latter prints the result of an expression to the template.
Many IDEs support syntax highlighting and auto-completion for Twig:
The application passes variables to the templates you can mess around in the template. Variables may have attributes or elements on them you can access too. How a variable looks like heavily depends on the application providing those.
You can use a dot (.) to access attributes of a variable (methods or properties of a PHP object, or items of a PHP array), or the so-called “subscript” syntax ([]):
{{ foo.bar }}
{{ foo['bar'] }}
When the attribute contains special characters (like - that would be interpreted as the minus operator), use the attribute function instead to access the variable attribute:
{# equivalent to the non-working foo.data-foo #}
{{ attribute(foo, 'data-foo') }}
Note
It’s important to know that the curly braces are not part of the variable but the print statement. If you access variables inside tags don’t put the braces around.
If a variable or attribute does not exist, you will get back a null value when the strict_variables option is set to false, otherwise Twig will throw an error (see environment options).
Note
If you want to get a dynamic attribute on a variable, use the attribute function instead.
The following variables are always available in templates:
Variables can be modified by filters. Filters are separated from the variable by a pipe symbol (|) and may have optional arguments in parentheses. Multiple filters can be chained. The output of one filter is applied to the next.
The following example removes all HTML tags from the name and title-cases it:
{{ name|striptags|title }}
Filters that accept arguments have parentheses around the arguments. This example will join a list by commas:
{{ list|join(', ') }}
To apply a filter on a section of code, wrap it with the filter tag:
{% filter upper %}
This text becomes uppercase
{% endfilter %}
Go to the filters page to learn more about the built-in filters.
Functions can be called to generate content. Functions are called by their name followed by parentheses (()) and may have arguments.
For instance, the range function returns a list containing an arithmetic progression of integers:
{% for i in range(0, 3) %}
{{ i }},
{% endfor %}
Go to the functions page to learn more about the built-in functions.
New in version 1.12: Support for named arguments was added in Twig 1.12.
Arguments for filters and functions can also be passed as named arguments:
{% for i in range(low=1, high=10, step=2) %}
{{ i }},
{% endfor %}
Using named arguments makes your templates more explicit about the meaning of the values you pass as arguments:
{{ data|convert_encoding('UTF-8', 'iso-2022-jp') }}
{# versus #}
{{ data|convert_encoding(from='iso-2022-jp', to='UTF-8') }}
Named arguments also allow you to skip some arguments for which you don’t want to change the default value:
{# the first argument is the date format, which defaults to the global date format if null is passed #}
{{ "now"|date(null, "Europe/Paris") }}
{# or skip the format value by using a named argument for the timezone #}
{{ "now"|date(timezone="Europe/Paris") }}
You can also use both positional and named arguments in one call, in which case positional arguments must always come before named arguments:
{{ "now"|date('d/m/Y H:i', timezone="Europe/Paris") }}
Tip
Each function and filter documentation page has a section where the names of all arguments are listed when supported.
A control structure refers to all those things that control the flow of a program - conditionals (i.e. if/elseif/else), for-loops, as well as things like blocks. Control structures appear inside {% ... %} blocks.
For example, to display a list of users provided in a variable called users, use the for tag:

Members

{% for user in users %}

{{ user.username|e }}

{% endfor %}

The if tag can be used to test an expression:
{% if users|length > 0 %}

{% for user in users %}

{{ user.username|e }}

{% endfor %}

{% endif %}
Go to the tags page to learn more about the built-in tags.
To comment-out part of a line in a template, use the comment syntax {# ... #}. This is useful for debugging or to add information for other template designers or yourself:
{# note: disabled template because we no longer use this
{% for user in users %}
...
{% endfor %}
#}
The include tag is useful to include a template and return the rendered content of that template into the current one:
{% include 'sidebar.html' %}
Per default included templates are passed the current context.
The context that is passed to the included template includes variables defined in the template:
{% for box in boxes %}
{% include "render_box.html" %}
{% endfor %}
The included template render_box.html is able to access box.
The filename of the template depends on the template loader. For instance, the Twig_Loader_Filesystem allows you to access other templates by giving the filename. You can access templates in subdirectories with a slash:
{% include "sections/articles/sidebar.html" %}
This behavior depends on the application embedding Twig.
The most powerful part of Twig is template inheritance. Template inheritance allows you to build a base “skeleton” template that contains all the common elements of your site and defines blocks that child templates can override.
Sounds complicated but is very basic. It’s easier to understand it by starting with an example.
Let’s define a base template, base.html, which defines a simple HTML skeleton document that you might use for a simple two-column page:
<!DOCTYPE html>

{% block head %}
<link rel="stylesheet" href="style.css" />
<title>{% block title %}{% endblock %} - My Webpage</title>
{% endblock %}

{% block content %}{% endblock %}

{% block footer %}
© Copyright 2011 by you.
{% endblock %}

In this example, the block tags define four blocks that child templates can fill in. All the block tag does is to tell the template engine that a child template may override those portions of the template.
A child template might look like this:
{% extends "base.html" %}
{% block title %}Index{% endblock %}
{% block head %}
{{ parent() }}

{% endblock %}
{% block content %}

Index

Welcome to my awesome homepage.

{% endblock %}
The extends tag is the key here. It tells the template engine that this template “extends” another template. When the template system evaluates this template, first it locates the parent. The extends tag should be the first tag in the template.
Note that since the child template doesn’t define the footer block, the value from the parent template is used instead.
It’s possible to render the contents of the parent block by using the parent function. This gives back the results of the parent block:
{% block sidebar %}

Table Of Contents

...
{{ parent() }}
{% endblock %}
Tip
The documentation page for the extends tag describes more advanced features like block nesting, scope, dynamic inheritance, and conditional inheritance.
Note
Twig also supports multiple inheritance with the so called horizontal reuse with the help of the use tag. This is an advanced feature hardly ever needed in regular templates.
When generating HTML from templates, there’s always a risk that a variable will include characters that affect the resulting HTML. There are two approaches: manually escaping each variable or automatically escaping everything by default.
Twig supports both, automatic escaping is enabled by default.
Note
Automatic escaping is only supported if the escaper extension has been enabled (which is the default).
If manual escaping is enabled, it is your responsibility to escape variables if needed. What to escape? Any variable you don’t trust.
Escaping works by piping the variable through the escape or e filter:
{{ user.username|e }}
By default, the escape filter uses the html strategy, but depending on the escaping context, you might want to explicitly use any other available strategies:
{{ user.username|e('js') }}
{{ user.username|e('css') }}
{{ user.username|e('url') }}
{{ user.username|e('html_attr') }}
Whether automatic escaping is enabled or not, you can mark a section of a template to be escaped or not by using the autoescape tag:
{% autoescape %}
Everything will be automatically escaped in this block (using the HTML strategy)
{% endautoescape %}
By default, auto-escaping uses the html escaping strategy. If you output variables in other contexts, you need to explicitly escape them with the appropriate escaping strategy:
{% autoescape 'js' %}
Everything will be automatically escaped in this block (using the JS strategy)
{% endautoescape %}
It is sometimes desirable or even necessary to have Twig ignore parts it would otherwise handle as variables or blocks. For example if the default syntax is used and you want to use {{ as raw string in the template and not start a variable you have to use a trick.
The easiest way is to output the variable delimiter ({{) by using a variable expression:
{{ '{{' }}
For bigger sections it makes sense to mark a block verbatim.
New in version 1.12: Support for default argument values was added in Twig 1.12.
Macros are comparable with functions in regular programming languages. They are useful to reuse often used HTML fragments to not repeat yourself.
A macro is defined via the macro tag. Here is a small example (subsequently called forms.html) of a macro that renders a form element:
{% macro input(name, value, type, size) %}
<input type="{{ type|default('text') }}" name="{{ name }}" value="{{ value|e }}" size="{{ size|default(20) }}" />
{% endmacro %}
Macros can be defined in any template, and need to be “imported” via the import tag before being used:
{% import "forms.html" as forms %}

{{ forms.input('username') }}

Alternatively, you can import individual macro names from a template into the current namespace via the from tag and optionally alias them:
{% from 'forms.html' import input as input_field %}

Username

{{ input_field('username') }}

Password

{{ input_field('password', '', 'password') }}

A default value can also be defined for macro arguments when not provided in a macro call:
{% macro input(name, value = "", type = "text", size = 20) %}
<input type="{{ type }}" name="{{ name }}" value="{{ value|e }}" size="{{ size }}" />
{% endmacro %}
Twig allows expressions everywhere. These work very similar to regular PHP and even if you’re not working with PHP you should feel comfortable with it.
Note
The operator precedence is as follows, with the lowest-precedence operators listed first: b-and, b-xor, b-or, or, and, ==, !=, <, >, >=, <=, in, .., +, -, ~, *, /, //, %, is, **, |, [], and .:
{% set greeting = 'Hello' %}
{% set name = 'Fabien' %}
{{ greeting ~ name|lower }} {# Hello fabien #}
{# use parenthesis to change precedence #}
{{ (greeting ~ name)|lower }} {# hello fabien #}
New in version 1.5: Support for hash keys as names and expressions was added in Twig 1.5.
The simplest form of expressions are literals. Literals are representations for PHP types such as strings, numbers, and arrays. The following literals exist:
"Hello World": Everything between two double or single quotes is a string. They are useful whenever you need a string in the template (for example as arguments to function calls, filters or just to extend or include a template). A string can contain a delimiter if it is preceded by a backslash (\) – like in 'It\'s good'.
42 / 42.23: Integers and floating point numbers are created by just writing the number down. If a dot is present the number is a float, otherwise an integer.
["foo", "bar"]: Arrays are defined by a sequence of expressions separated by a comma (,) and wrapped with squared brackets ([]).
{"foo": "bar"}: Hashes are defined by a list of keys and values separated by a comma (,) and wrapped with curly braces ({}):
{# keys as string #}
{ 'foo': 'foo', 'bar': 'bar' }
{# keys as names (equivalent to the previous hash) -- as of Twig 1.5 #}
{ foo: 'foo', bar: 'bar' }
{# keys as integer #}
{ 2: 'foo', 4: 'bar' }
{# keys as expressions (the expression must be enclosed into parentheses) -- as of Twig 1.5 #}
{ (1 + 1): 'foo', (a ~ 'b'): 'bar' }
true / false: true represents the true value, false represents the false value.
null: null represents no specific value. This is the value returned when a variable does not exist. none is an alias for null.
Arrays and hashes can be nested:
{% set foo = [1, {"foo": "bar"}] %}
Tip
Using double-quoted or single-quoted strings has no impact on performance but string interpolation is only supported in double-quoted strings.
Twig allows you to calculate with values. This is rarely useful in templates but exists for completeness’ sake. The following operators are supported:
You can combine multiple expressions with the following operators:
Note
Twig also support bitwise operators (b-and, b-xor, and b-or).
The following comparison operators are supported in any expression: ==, !=, <, >, >=, and <=.
The in operator performs containment test.
It returns true if the left operand is contained in the right:
{# returns true #}
{{ 1 in [1, 2, 3] }}
{{ 'cd' in 'abcde' }}
Tip
You can use this filter to perform a containment test on strings, arrays, or objects implementing the Traversable interface.
To perform a negative test, use the not in operator:
{% if 1 not in [1, 2, 3] %}
{# is equivalent to #}
{% if not (1 in [1, 2, 3]) %}
The is operator performs tests. Tests can be used to test a variable against a common expression. The right operand is name of the test:
{# find out if a variable is odd #}
{{ name is odd }}
Tests can accept arguments too:
{% if loop.index is divisibleby(3) %}
Tests can be negated by using the is not operator:
{% if loop.index is not divisibleby(3) %}
{# is equivalent to #}
{% if not (loop.index is divisibleby(3)) %}
Go to the tests page to learn more about the built-in tests.
New in version 1.12.0: Support for the extended ternary operator was added in Twig 1.12.0.
The following operators are very useful but don’t fit into any of the other categories:
..: Creates a sequence based on the operand before and after the operator (this is just syntactic sugar for the range function).
|: Applies a filter.
~: Converts all operands into strings and concatenates them. {{ "Hello " ~ name ~ "!" }} would return (assuming name is 'John') Hello John!.
., []: Gets an attribute of an object.
?:: The ternary operator:
{{ foo ? 'yes' : 'no' }}
{# as of Twig 1.12.0 #}
{{ foo ?: 'no' }} == {{ foo ? foo : 'no' }}
{{ foo ? 'yes' }} == {{ foo ? 'yes' : '' }}
New in version 1.5: String interpolation was added in Twig 1.5.
String interpolation (#{expression}) allows any valid expression to appear within a double-quoted string. The result of evaluating that expression is inserted into the string:
{{ "foo #{bar} baz" }}
{{ "foo #{1 + 2} baz" }}
New in version 1.1: Tag level whitespace control was added in Twig 1.1.
The first newline after a template tag is removed automatically (like in PHP.) Whitespace is not further modified by the template engine, so each whitespace (spaces, tabs, newlines etc.) is returned unchanged.
Use the spaceless tag to remove whitespace between HTML tags:
{% spaceless %}

foo

{% endspaceless %}
{# output will be
foo
 #}
In addition to the spaceless tag you can also control whitespace on a per tag level. By using the whitespace control modifier on your tags, you can trim leading and or trailing whitespace:
{% set value = 'no spaces' %}
{#- No leading/trailing whitespace -#}
{%- if true -%}
{{- value -}}
{%- endif -%}
{# output 'no spaces' #}
The above sample shows the default whitespace control modifier, and how you can use it to remove whitespace around tags. Trimming space will consume all whitespace for that side of the tag. It is possible to use whitespace trimming on one side of a tag:
{% set value = 'no spaces' %}

 {{- value }}

{# outputs '
no spaces
' #}
Twig can be easily extended.
If you are looking for new tags, filters, or functions, have a look at the Twig official extension repository.
If you want to create your own, read the Creating an Extension chapter.


What is your name?
What's your favorite color of egg?
How do you like to travel?
What is your favorite animal?


Home
About Me
Tech Ideas
Updates
♦Update Section♦
Page Bottom
Overview: The content that was added in V1 was
index.html, techideas.html, aboutme.html, styles.css, about.html files.
4 navigation links at the top of my page. Home, About Me, Tech Ideas, Updates.
A heading with diamonds on each end.
A page bottom button that will take you to the bottom of the page. Major Headings and paragraphs.

A page Top button that takes you to the top of the page.
*Christian Haugaard* - Youtube hyperlink. As a footer with a hypertext link.
Page Top


{{trans "Your friend %email is sharing an event with you:" email=$post.email}}
{{trans "View the detailed page: %url" url=$event.url}}


SHINE A film review by Edwin Jahiel Copyright 1997 Edwin Jahiel
SHINE (Australia, 1995) *** 1/2 Directed by Scott Hicks. Written by Jan Sardi. hotography, Geoffrey Simpson. Editing,Pip Karmel. Production design, Vicki Niehus. Music, David Hirschfelder. Produced by Jane Scott. Cast: Geoffrey Rush (David Helfgott as an adult), Noah Taylor (David as a young man), Alex Rafalowicz (David as a child), Armin Mueller-Stahl (Peter Helfgott), Lynn Redgrave (Gillian), John Gielgud (Cecil Parkes), Googie Withers (Katharine Prichard) et al. A Fine Line release. 105 min. PG-13
"Shine" was the sensation at last year's Sundance Festival. You can see (and hear) why. It is not a film-by-the-numbers concoction of special effects or robotic characters, made for everybody's major target audience of teens to 25-year olds, plus a few old geezers in their thirties. It is about real people, doubly so as this is a true, un-fancied up story. While the facts are special, they are not as as unusual as some may think. Artists can and do crack under severe pressures, the way Australian pianist David Helfgott did.
The movie is excellent, although it leaves some questions unanswered about certain times, places and people's backgrounds. The Helfgotts live in Perth, I believem but various press items say Adelaide, Melbourne or "a city." There are other unclarities.
Peter Helfgott, the head (most emphatically) of the family, is a Polish Jew who had emigrated to Australia before World War II. (I have seen mentions of "a German Jews," perhaps because he speaks the language). His late father seems to have been very authoritarian. Peter's passion was music but this was opposed. A violin he had bought when young was smashed by his father.
Peter is a gravely traumatized individual. All or most of his relatives were killed in the Holocaust. The man is a pauper, not merely a low-income earner.
The apple of his eye is young David who, as a child, is something of a piano prodigy. His teacher is his father. Peter is imperious,bullying, tyrannical, intolerant yet at the same time terribly possessive. "No one will love you as I" is his leitmotiv to David at all stages of his son's life. It is clear that Monster Dad is not quite all there.Which gene went wrong in him is unknown. So is information of how and when Peter acquired the musical training that allows him to teach his son so ably.
When a professional teacher wants to instruct the so-promising David, Peter's "I can't afford to pay for lessons" is true statement but also an alibi. He just won't let go of his son.Eventually he relents. Later he grudgingly accepts having the local Jewish community lend a hand to the boy. Visiting Jewish-American super-star violinist Isaac Stern offers to get David to America, a wonderful scholarship and invitation are extended Peter, perhaps the Holcaust destroyed so many families, wants the boy to stay with him. He refuses to let him go to the U.S.A.
In spite of his horrid, mad background, when David places second in an all-Australia competition he becomes a young star nationally. Finally breaking away from Dad, he ignores his maledictions and opposition and accepts a scholarship at London's Royal Academy of Music.
His first public concert in England is a triumph. But it is immediately followed by a mental collapse, then a long maladythat lasts for several years. Eventually comes a cure, incomplete but sufficient to return David to the world of performing brilliantly in public. He will tour North America in March 1997.
Except for some lack of fact-giving "Shine" shines in every way. The performances could not be better. In small parts, beautifully done, are: the great, amazing, versatile Sir John Gielgud ( David's teacher in London) who will be 93 in April 1997 (Aries); Lynn Redgrave (the astrologer who marries David and helps his recovery), a youngster of 54 (in March 1997), sweet and lovely ; the charmingly named Googie Withers (David's good, understanding friend) who, though not a major star, enhanced more than a dozen, mostly British films from the late1930s to the mid-1950s. She resurfaced in two fine features in 1985 and 1994.
The youngsters who play David as a child and as an adolescent are perfectly cast. Geoffrey Rush (David as an adult), an admired stage actor who has also been in films, is extraordinary. His constant, endlessly repeated, jabbered comments to himself and to others, uttered with a happy, friendly face, are a unique tour-de-force which copies the real David. The only approximate comparisons I can make are to the manic David Thewlis in "Naked" and to several agitated characters by James Woods.
Peter is played by the former East German actor Armin Mueller-Stahl. He has been in American films since 1989's "The Music Box." You may remember him in "Avalon," "Kafka," "Night on Earth" (the New York cabbie) and "The Last Good Time." While David is the center of the movie, Peter's portrayal is the most cryptic and perhaps complex.
Eloquent bits of business are numerous. Like Peter, a non-believer, visiting a rabbi to make arrangements for David and donning a skullcap --perhaps for the first time everr. Or else he once had faith but the Holocaust may have caused him to lose it. As he starts on the corridor leading to the exit, he removes the cap. Like Peter again,in his pitiful yard, simply glances at a barbed wire.The reference to death camps is instantaneous.
"Shine" gives a new meaning to "family movie," as do the current "Mother" and especially the French "Thieves."
This review and others can be found at : http://www.prairienet.org/ejahiel/
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


HOME
(current)
WEB DEVELOPMENT
HTML
CSS
JAVASCRIPT
ARTIFICIAL INTELLIGENCE
MACHINE LEARNING
DEEP LEARNING
CONVERSIONS
BINARY TO HEXADECIMAL
BINARY TO OCTA DECIMAL
BINARY TO DECIMAL
DECIMAL TO OCTA DECIMAL
OCTA DECIMAL TO HEXADECIMAL
HEXADECIMAL TO OCTA DECIMAL
ENCRYPTION/DECRYPTION
TRIPLE DES
RSA
AES
ABOUT US
SERVICES
PERQUISITES
Numpy
Pandas
Matplotlib
MATHS BEHIND
Algebra
Statistics
Probability
DATA PROCESSING
Intro
Data cleaning
Data transform
Data scaling
ACTIVATION
Relu
Tanh
Sigmoid
Leaky Relu
Softmax
ML GLOSSARY
Bias
Weight
Regularization
Optimization
SUPERVISED ALGO
Linear regresion
Logistic regression
Naive Bayesian
Decision Trees
Random Forest
Support Vector Machines
UNSUPERVISED ALGO
PCA
K-mean
KNN
Apriori algorithm
REINFORCEMENT ALGO
remain to code


Hello! the rules of this are simple.
* Each square on the top row needs to have lines drawn connecting them to each square on the bottom row.
* Your lines cannot cross or overlap with each other.
Enjoy!!!
(Please make sure you have scrolled back to the top before you start.)


The following document contains the results of PMD 5.0.2.
| Violation | Line |
|---|---|
| Avoid unused constructor parameters such as 'config'. | 31 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 31 |
| Violation | Line |
|---|---|
| Too many static imports may lead to messy code | 14 - 628 |
| Useless parentheses. | 608 |
| Useless parentheses. | 624 - 625 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 30 |
| Avoid modifiers which are implied by the context | 39 |
| Avoid modifiers which are implied by the context | 45 |
| Avoid modifiers which are implied by the context | 54 |
| Avoid modifiers which are implied by the context | 61 |
| Avoid modifiers which are implied by the context | 70 |
| Avoid modifiers which are implied by the context | 76 |
| Avoid modifiers which are implied by the context | 85 |
| Avoid modifiers which are implied by the context | 90 |
| Avoid modifiers which are implied by the context | 99 |
| Avoid modifiers which are implied by the context | 105 |
| Avoid modifiers which are implied by the context | 116 |
| Avoid modifiers which are implied by the context | 122 |
| Avoid modifiers which are implied by the context | 129 |
| Avoid modifiers which are implied by the context | 136 |
| Avoid modifiers which are implied by the context | 143 |
| Avoid modifiers which are implied by the context | 152 |
| Avoid modifiers which are implied by the context | 161 |
| Avoid modifiers which are implied by the context | 168 |
| Avoid modifiers which are implied by the context | 176 |
| Avoid modifiers which are implied by the context | 181 |
| Avoid modifiers which are implied by the context | 186 |
| Avoid modifiers which are implied by the context | 196 |
| Avoid modifiers which are implied by the context | 206 |
| Avoid modifiers which are implied by the context | 211 |
| Avoid modifiers which are implied by the context | 222 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 232 |
| Violation | Line |
|---|---|
| Unnecessary use of fully qualified name 'ServletContextUtils.getContextPath' due to existing import 'net.jawr.web.util.ServletContextUtils' | 227 |
| Useless parentheses. | 230 |
| Violation | Line |
|---|---|
| Useless parentheses. | 104 |
| Useless parentheses. | 104 - 105 |
| Useless parentheses. | 104 |
| Useless parentheses. | 104 |
| Useless parentheses. | 138 |
| Violation | Line |
|---|---|
| Useless parentheses. | 62 |
| Useless parentheses. | 122 |
| Useless parentheses. | 267 |
| Useless parentheses. | 291 |
| Useless parentheses. | 320 |
| Violation | Line |
|---|---|
| Avoid empty while statements | 227 - 229 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 201 - 203 |
| Avoid empty catch blocks | 219 - 221 |
| Avoid empty catch blocks | 236 - 238 |
| Avoid empty catch blocks | 253 - 255 |
| Avoid empty catch blocks | 270 - 272 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 36 |
| Avoid modifiers which are implied by the context | 39 |
| Avoid modifiers which are implied by the context | 46 |
| Avoid modifiers which are implied by the context | 55 |
| Avoid modifiers which are implied by the context | 62 |
| Avoid modifiers which are implied by the context | 70 |
| Avoid modifiers which are implied by the context | 75 |
| Avoid modifiers which are implied by the context | 83 |
| Avoid modifiers which are implied by the context | 90 |
| Avoid modifiers which are implied by the context | 97 |
| Avoid modifiers which are implied by the context | 105 |
| Avoid modifiers which are implied by the context | 113 |
| Avoid modifiers which are implied by the context | 120 |
| Avoid modifiers which are implied by the context | 127 |
| Avoid modifiers which are implied by the context | 134 |
| Avoid modifiers which are implied by the context | 143 |
| Avoid modifiers which are implied by the context | 150 |
| Avoid modifiers which are implied by the context | 160 |
| Avoid modifiers which are implied by the context | 169 |
| Avoid modifiers which are implied by the context | 176 |
| Avoid modifiers which are implied by the context | 185 |
| Avoid modifiers which are implied by the context | 197 |
| Avoid modifiers which are implied by the context | 206 |
| Avoid modifiers which are implied by the context | 213 |
| Avoid modifiers which are implied by the context | 221 |
| Avoid modifiers which are implied by the context | 228 |
| Avoid modifiers which are implied by the context | 238 |
| Avoid modifiers which are implied by the context | 249 |
| Avoid modifiers which are implied by the context | 256 |
| Avoid modifiers which are implied by the context | 264 |
| Avoid modifiers which are implied by the context | 272 |
| Avoid modifiers which are implied by the context | 280 |
| Avoid modifiers which are implied by the context | 288 |
| Avoid modifiers which are implied by the context | 296 |
| Avoid modifiers which are implied by the context | 304 |
| Avoid modifiers which are implied by the context | 311 |
| Violation | Line |
|---|---|
| Too many static imports may lead to messy code | 16 - 342 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 35 |
| Avoid modifiers which are implied by the context | 41 |
| Avoid modifiers which are implied by the context | 47 |
| Avoid modifiers which are implied by the context | 53 |
| Avoid modifiers which are implied by the context | 60 |
| Avoid modifiers which are implied by the context | 70 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 259 - 261 |
| Avoid empty catch blocks | 277 - 279 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 29 |
| Avoid modifiers which are implied by the context | 34 |
| Violation | Line |
|---|---|
| Useless parentheses. | 112 - 121 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 29 |
| Avoid modifiers which are implied by the context | 36 |
| Violation | Line |
|---|---|
| Useless parentheses. | 255 |
| Unnecessary final modifier in final class | 363 - 374 |
| Unnecessary final modifier in final class | 382 - 389 |
| Unnecessary final modifier in final class | 560 - 590 |
| Useless parentheses. | 719 |
| Useless parentheses. | 726 |
| Unnecessary final modifier in final class | 761 - 773 |
| Unnecessary final modifier in final class | 799 - 847 |
| Useless parentheses. | 826 |
| Useless parentheses. | 827 |
| Useless parentheses. | 833 |
| Useless parentheses. | 834 |
| Unnecessary final modifier in final class | 922 - 932 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 26 |
| Violation | Line |
|---|---|
| These nested if statements could be combined | 280 - 284 |
| These nested if statements could be combined | 281 - 283 |
| This for loop could be simplified to a while loop | 545 - 552 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 30 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 42 |
| Violation | Line |
|---|---|
| Useless parentheses. | 242 |
| These nested if statements could be combined | 333 - 336 |
| Violation | Line |
|---|---|
| Useless parentheses. | 102 |
| Useless parentheses. | 102 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 33 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 29 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 28 |
| Avoid modifiers which are implied by the context | 31 |
| Avoid modifiers which are implied by the context | 34 |
| Avoid modifiers which are implied by the context | 52 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 30 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 33 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 33 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 34 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 36 |
| Violation | Line |
|---|---|
| Unnecessary use of fully qualified name 'JawrConstant.JAR_URL_PREFIX' due to existing import 'net.jawr.web.JawrConstant' | 179 |
| Useless parentheses. | 202 |
| Avoid empty catch blocks | 252 - 254 |
| Unnecessary use of fully qualified name 'JawrConstant.FILE_URL_PREFIX' due to existing import 'net.jawr.web.JawrConstant' | 318 |
| Unnecessary use of fully qualified name 'JawrConstant.JAR_URL_PREFIX' due to existing import 'net.jawr.web.JawrConstant' | 320 |
| Unnecessary use of fully qualified name 'JawrConstant.FILE_URL_PREFIX' due to existing import 'net.jawr.web.JawrConstant' | 320 |
| Unnecessary use of fully qualified name 'JawrConstant.FILE_URL_PREFIX' due to existing import 'net.jawr.web.JawrConstant' | 321 |
| Useless parentheses. | 321 |
| Unnecessary use of fully qualified name 'JawrConstant.JAR_URL_PREFIX' due to existing import 'net.jawr.web.JawrConstant' | 321 |
| Unnecessary use of fully qualified name 'JawrConstant.FILE_URL_PREFIX' due to existing import 'net.jawr.web.JawrConstant' | 345 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 167 - 169 |
| Violation | Line |
|---|---|
| Unnecessary use of fully qualified name 'JawrConstant.SASS_GENERATOR_URL_MODE' due to existing import 'net.jawr.web.JawrConstant' | 129 |
| Unnecessary use of fully qualified name 'JawrConstant.SASS_GENERATOR_URL_MODE' due to existing import 'net.jawr.web.JawrConstant' | 142 |
| Unnecessary use of fully qualified name 'JawrConstant.SASS_GENERATOR_URL_MODE' due to existing import 'net.jawr.web.JawrConstant' | 144 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 124 - 126 |
| Violation | Line |
|---|---|
| Unnecessary use of fully qualified name 'JawrConstant.URL_SEPARATOR' due to existing import 'net.jawr.web.JawrConstant' | 146 |
| Useless parentheses. | 175 |
| These nested if statements could be combined | 176 - 194 |
| These nested if statements could be combined | 205 - 214 |
| Violation | Line |
|---|---|
| Useless parentheses. | 166 |
| Useless parentheses. | 167 |
| Useless parentheses. | 188 |
| Useless parentheses. | 296 |
| Useless parentheses. | 296 |
| Useless parentheses. | 328 |
| Useless parentheses. | 349 |
| Useless parentheses. | 350 |
| Useless parentheses. | 396 |
| Useless parentheses. | 396 |
| Useless parentheses. | 445 |
| Useless parentheses. | 445 |
| Useless parentheses. | 446 - 447 |
| Useless parentheses. | 446 |
| Useless parentheses. | 449 |
| Useless parentheses. | 449 - 450 |
| Useless parentheses. | 449 - 450 |
| Useless parentheses. | 451 - 452 |
| Useless parentheses. | 451 |
| Useless parentheses. | 454 - 455 |
| Useless parentheses. | 454 |
| Useless parentheses. | 456 - 457 |
| Useless parentheses. | 456 |
| Useless parentheses. | 456 - 457 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 731 - 733 |
| Avoid empty catch blocks | 764 - 766 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 709 - 711 |
| Violation | Line |
|---|---|
| These nested if statements could be combined | 190 - 192 |
| Violation | Line |
|---|---|
| Avoid unused constructor parameters such as 'messageLog'. | 83 |
| These nested if statements could be combined | 190 - 192 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 29 |
| Avoid modifiers which are implied by the context | 37 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 33 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 33 |
| Avoid modifiers which are implied by the context | 36 |
| Avoid modifiers which are implied by the context | 44 |
| Avoid modifiers which are implied by the context | 51 |
| Avoid modifiers which are implied by the context | 60 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 189 - 190 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 47 |
| Avoid modifiers which are implied by the context | 57 |
| Avoid modifiers which are implied by the context | 66 |
| Avoid modifiers which are implied by the context | 77 - 78 |
| Avoid modifiers which are implied by the context | 91 - 92 |
| Avoid modifiers which are implied by the context | 105 - 106 |
| Avoid modifiers which are implied by the context | 123 - 124 |
| Avoid modifiers which are implied by the context | 143 - 144 |
| Avoid modifiers which are implied by the context | 157 |
| Avoid modifiers which are implied by the context | 170 |
| Avoid modifiers which are implied by the context | 177 |
| Avoid modifiers which are implied by the context | 184 |
| Avoid modifiers which are implied by the context | 189 |
| Avoid modifiers which are implied by the context | 196 |
| Avoid modifiers which are implied by the context | 203 |
| Avoid modifiers which are implied by the context | 213 |
| Avoid modifiers which are implied by the context | 220 |
| Avoid modifiers which are implied by the context | 227 |
| Avoid modifiers which are implied by the context | 235 |
| Avoid modifiers which are implied by the context | 242 |
| Avoid modifiers which are implied by the context | 247 |
| Avoid modifiers which are implied by the context | 254 |
| Avoid modifiers which are implied by the context | 262 |
| Avoid modifiers which are implied by the context | 269 |
| Avoid modifiers which are implied by the context | 277 |
| Violation | Line |
|---|---|
| Useless parentheses. | 680 |
| These nested if statements could be combined | 855 - 858 |
| Useless parentheses. | 1193 |
| Useless parentheses. | 1194 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 31 |
| Avoid modifiers which are implied by the context | 37 |
| Violation | Line |
|---|---|
| These nested if statements could be combined | 100 - 101 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 31 |
| Violation | Line |
|---|---|
| Avoid unused imports such as 'java.util.ResourceBundle' | 23 |
| Useless parentheses. | 56 |
| Avoid empty catch blocks | 262 - 264 |
| Avoid empty catch blocks | 269 - 271 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 105 - 106 |
| Violation | Line |
|---|---|
| Unnecessary use of fully qualified name 'JawrConstant.JAWR_LOCALE_GENERATOR_FALLBACK_TO_SYSTEM_LOCALE' due to existing import 'net.jawr.web.JawrConstant' | 127 |
| Unnecessary use of fully qualified name 'JawrConstant.JAWR_LOCALE_GENERATOR_RESOURCE_BUNDLE_CHARSET' due to existing import 'net.jawr.web.JawrConstant' | 129 |
| Violation | Line |
|---|---|
| Useless parentheses. | 273 |
| Violation | Line |
|---|---|
| Useless parentheses. | 280 |
| Violation | Line |
|---|---|
| These nested if statements could be combined | 50 - 52 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 32 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 167 - 169 |
| Violation | Line |
|---|---|
| Useless parentheses. | 99 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 33 |
| Avoid modifiers which are implied by the context | 42 - 43 |
| Avoid modifiers which are implied by the context | 48 |
| Avoid modifiers which are implied by the context | 55 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 40 - 42 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 39 - 40 |
| Avoid modifiers which are implied by the context | 58 - 59 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 32 |
| Avoid modifiers which are implied by the context | 42 |
| Violation | Line |
|---|---|
| Useless parentheses. | 138 |
| Useless parentheses. | 139 |
| Violation | Line |
|---|---|
| Avoid unused constructor parameters such as 'generatorRegistry'. | 114 |
| Avoid empty catch blocks | 309 - 311 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 37 |
| Avoid modifiers which are implied by the context | 48 |
| Avoid modifiers which are implied by the context | 59 |
| Avoid modifiers which are implied by the context | 71 |
| Avoid modifiers which are implied by the context | 82 |
| Avoid modifiers which are implied by the context | 89 |
| Avoid modifiers which are implied by the context | 96 |
| Avoid modifiers which are implied by the context | 104 |
| Avoid modifiers which are implied by the context | 111 |
| Avoid modifiers which are implied by the context | 118 |
| Violation | Line |
|---|---|
| Avoid unused constructor parameters such as 'generatorRegistry'. | 74 |
| Violation | Line |
|---|---|
| Useless parentheses. | 163 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 148 - 150 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 68 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 35 |
| Violation | Line |
|---|---|
| These nested if statements could be combined | 285 - 301 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 32 |
| Avoid modifiers which are implied by the context | 44 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 34 |
| Avoid modifiers which are implied by the context | 43 |
| Violation | Line |
|---|---|
| Avoid modifiers which are implied by the context | 27 |
| Violation | Line |
|---|---|
| These nested if statements could be combined | 167 - 175 |
| Useless parentheses. | 190 - 191 |
| Violation | Line |
|---|---|
| Too many static imports may lead to messy code | 14 - 387 |
| Avoid empty catch blocks | 313 - 314 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 486 - 488 |
| Unnecessary use of fully qualified name 'JawrConstant.URL_SEPARATOR' due to existing import 'net.jawr.web.JawrConstant' | 615 |
| Violation | Line |
|---|---|
| These nested if statements could be combined | 835 - 842 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 43 - 44 |
| Avoid empty catch blocks | 47 - 48 |
| Avoid empty catch blocks | 51 - 52 |
| Avoid empty catch blocks | 55 - 56 |
| Avoid empty catch blocks | 59 - 60 |
| Avoid empty catch blocks | 64 - 65 |
| Violation | Line |
|---|---|
| Useless parentheses. | 206 |
| Useless parentheses. | 214 |
| Useless parentheses. | 222 |
| Useless parentheses. | 230 |
| Useless parentheses. | 238 |
| Useless parentheses. | 246 |
| Useless parentheses. | 254 |
| Useless parentheses. | 262 |
| Useless parentheses. | 270 |
| Useless parentheses. | 278 |
| Useless parentheses. | 286 |
| Useless parentheses. | 294 |
| Useless parentheses. | 302 |
| Useless parentheses. | 310 |
| Useless parentheses. | 318 |
| Useless parentheses. | 326 |
| Useless parentheses. | 334 |
| Useless parentheses. | 342 |
| Useless parentheses. | 350 |
| Useless parentheses. | 358 |
| Useless parentheses. | 366 |
| Useless parentheses. | 374 |
| Useless parentheses. | 382 |
| Useless parentheses. | 390 |
| Useless parentheses. | 398 |
| Useless parentheses. | 406 |
| Useless parentheses. | 670 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 48 - 49 |
| Avoid empty catch blocks | 53 - 54 |
| Avoid empty catch blocks | 58 - 59 |
| Avoid empty catch blocks | 63 - 64 |
| Avoid empty catch blocks | 68 - 69 |
| Avoid empty catch blocks | 73 - 74 |
| Avoid empty catch blocks | 78 - 79 |
| Avoid empty catch blocks | 83 - 84 |
| Avoid empty catch blocks | 88 - 89 |
| Avoid empty catch blocks | 93 - 94 |
| Avoid empty catch blocks | 98 - 99 |
| Avoid empty catch blocks | 103 - 104 |
| Avoid empty catch blocks | 108 - 109 |
| Avoid empty catch blocks | 113 - 114 |
| Avoid empty catch blocks | 118 - 119 |
| Avoid empty catch blocks | 123 - 124 |
| Avoid empty catch blocks | 128 - 129 |
| Avoid empty catch blocks | 133 - 134 |
| Avoid empty catch blocks | 138 - 139 |
| Avoid empty catch blocks | 143 - 144 |
| Avoid empty catch blocks | 148 - 149 |
| Avoid empty catch blocks | 153 - 154 |
| Avoid empty catch blocks | 158 - 159 |
| Avoid empty catch blocks | 163 - 164 |
| Avoid empty catch blocks | 168 - 169 |
| Avoid empty catch blocks | 173 - 174 |
| Avoid empty catch blocks | 178 - 179 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 47 - 48 |
| Avoid empty catch blocks | 52 - 53 |
| Violation | Line |
|---|---|
| Useless parentheses. | 314 |
| Useless parentheses. | 322 |
| Useless parentheses. | 330 |
| Useless parentheses. | 338 |
| Useless parentheses. | 346 |
| Useless parentheses. | 354 |
| Useless parentheses. | 362 |
| Useless parentheses. | 370 |
| Useless parentheses. | 378 |
| Useless parentheses. | 386 |
| Useless parentheses. | 394 |
| Useless parentheses. | 402 |
| Useless parentheses. | 410 |
| Useless parentheses. | 418 |
| Useless parentheses. | 426 |
| Useless parentheses. | 434 |
| Useless parentheses. | 442 |
| Useless parentheses. | 450 |
| Useless parentheses. | 458 |
| Useless parentheses. | 466 |
| Useless parentheses. | 474 |
| Useless parentheses. | 482 |
| Useless parentheses. | 490 |
| Useless parentheses. | 498 |
| Useless parentheses. | 506 |
| Useless parentheses. | 514 |
| Useless parentheses. | 522 |
| Useless parentheses. | 530 |
| Useless parentheses. | 538 |
| Useless parentheses. | 546 |
| Useless parentheses. | 554 |
| Useless parentheses. | 562 |
| Useless parentheses. | 570 |
| Useless parentheses. | 578 |
| Useless parentheses. | 586 |
| Useless parentheses. | 594 |
| Useless parentheses. | 602 |
| Useless parentheses. | 610 |
| Useless parentheses. | 618 |
| Useless parentheses. | 626 |
| Useless parentheses. | 634 |
| Useless parentheses. | 642 |
| Useless parentheses. | 650 |
| Useless parentheses. | 658 |
| Useless parentheses. | 1084 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 43 - 44 |
| Avoid empty catch blocks | 48 - 49 |
| Avoid empty catch blocks | 53 - 54 |
| Avoid empty catch blocks | 58 - 59 |
| Avoid empty catch blocks | 63 - 64 |
| Avoid empty catch blocks | 68 - 69 |
| Avoid empty catch blocks | 73 - 74 |
| Avoid empty catch blocks | 78 - 79 |
| Avoid empty catch blocks | 83 - 84 |
| Avoid empty catch blocks | 88 - 89 |
| Avoid empty catch blocks | 93 - 94 |
| Avoid empty catch blocks | 98 - 99 |
| Avoid empty catch blocks | 103 - 104 |
| Avoid empty catch blocks | 108 - 109 |
| Avoid empty catch blocks | 113 - 114 |
| Avoid empty catch blocks | 118 - 119 |
| Avoid empty catch blocks | 123 - 124 |
| Avoid empty catch blocks | 128 - 129 |
| Avoid empty catch blocks | 133 - 134 |
| Avoid empty catch blocks | 138 - 139 |
| Avoid empty catch blocks | 143 - 144 |
| Avoid empty catch blocks | 148 - 149 |
| Avoid empty catch blocks | 153 - 154 |
| Avoid empty catch blocks | 158 - 159 |
| Avoid empty catch blocks | 163 - 164 |
| Avoid empty catch blocks | 168 - 169 |
| Avoid empty catch blocks | 173 - 174 |
| Avoid empty catch blocks | 178 - 179 |
| Violation | Line |
|---|---|
| Avoid empty catch blocks | 43 - 44 |
| Avoid empty catch blocks | 47 - 48 |
| Avoid empty catch blocks | 51 - 52 |
| Avoid empty catch blocks | 55 - 56 |
| Avoid empty catch blocks | 60 - 61 |
| Violation | Line |
|---|---|
| These nested if statements could be combined | 206 - 208 |
| These nested if statements could be combined | 521 - 523 |
| Useless parentheses. | 542 |
| Violation | Line |
|---|---|
| Useless parentheses. | 157 |
| Useless parentheses. | 164 |
| Violation | Line |
|---|---|
| Useless parentheses. | 52 |
| Useless parentheses. | 53 |
| Violation | Line |
|---|---|
| These nested if statements could be combined | 226 - 228 |
| Violation | Line |
|---|---|
| Useless parentheses. | 60 |
| Useless parentheses. | 61 |
| Useless parentheses. | 62 |
| Violation | Line |
|---|---|
| Useless parentheses. | 61 |
| Useless parentheses. | 62 |
| Useless parentheses. | 63 |
| Useless parentheses. | 64 |
| Useless parentheses. | 70 |
| Useless parentheses. | 71 |
| Useless parentheses. | 72 |
| Useless parentheses. | 73 |
| Useless parentheses. | 80 |
| Useless parentheses. | 81 |
| Useless parentheses. | 82 |
| Useless parentheses. | 89 |
| Useless parentheses. | 90 |
| Useless parentheses. | 96 |
| Useless parentheses. | 97 |
| Check the value returned by the skip() method of an InputStream to see if the requested number of bytes has been skipped. | 137 |
| Violation | Line |
|---|---|
| Useless parentheses. | 146 |
| Useless parentheses. | 146 |
| Useless parentheses. | 146 |
| Useless parentheses. | 147 |
| Useless parentheses. | 150 |
| Useless parentheses. | 150 |
| Useless parentheses. | 150 |
| Useless parentheses. | 151 |
| Useless parentheses. | 157 |
| Useless parentheses. | 157 |
| Useless parentheses. | 157 |
| Useless parentheses. | 163 |
| Useless parentheses. | 163 |
| Useless parentheses. | 166 |
| Useless parentheses. | 166 |
| Violation | Line |
|---|---|
| Useless parentheses. | 328 |
| Useless parentheses. | 330 |


ndau Glossary and Usage Guide¶
Definitions¶
ndau Chain - The main ndau blockchain.
Chaincode - Chaincode is a stack-based programming language that allows users of ndau to express complex logic about how their ndau should behave and implement sophisticated security systems.
ndau – A single unit of currency. Always spelled with a lowercase ‘n’, including when it is the first word in a sentence. Pronounced as “EN-dow”. ndau is a count noun, not a mass noun: “many ndau”, not “a lot of ndau”, and “fewer ndau”, not “less ndau”. Use the indefinite article ‘an’: “an ndau account”.
napu - The smallest possible division of one ndau, equal to 1 x 10^-8 ndau. (Derived by flipping the word ndau
upside down.)
Account – A single container of ndau. An account has many properties (e.g. lock status, weighted average age, etc.) in addition to its address. Do not use ‘address’ as a synonym for ‘account’: use ‘address’ only when referring to that specific attribute of an account.
Address – A 48-character string identifying an account on the ndau blockchain. All ndau transactions identify an account by its address.
Transaction Terminology - Transfer transactions have a source and destination account. The source account sends ndau and the destination receives them. The affected ndau have been transferred. Transactions that only affect a single account (e.g. locking) act on that account as the object of the transaction verb: the holder locks an account, sets a Recourse Period, changes a validation script.
Ecosystem Alignment Incentive (EAI) – (Not Economic Alignment Incentive) Newly-created ndau available to ndau holders to encourage holder behavior in support of ndau fiscal policy and goals.
Locked – A locked account does not permit outgoing transfers. Locked accounts accrue additional EAI as an incentive for locking, and are subject to restrictions on when they become unlocked.
Recourse Period – A period during which ndau transferred from a source account to a destination account are not yet available to destination account. Capitalize both words, do not use an acronym. Do not use ‘escrow’ as a synonym.
Key – A private key and a public key together make up a keypair. Information (of any sort) can be combined with one of those two keys, creating a signature. The signature can be verified by a holder of the other key, and the information can be confirmed to be unmodified since it was signed. In most ndau (and other blockchain) contexts, information is signed with the private key and verified with the public key: therefore, it is usually not necessary to qualify ‘key’ as ‘private key’ or ‘public key’. Do not confuse ‘signature’ with ‘key’: a signature is created by the combination of information and a key.
Signature - A combination of a key and information.
Node - A computing device participating in the ndau network, running the ndau blockchain software. Also referred to as “Network Node”.
Node operator - An entity responsible for operating one or more nodes.
Reward - A payment made in response to user behavior. Both EAI and node operations payments are rewards.
Delegate - When an ndau holder assigns the calculation of EAI for a specific account to a specific network node.
Stake - A quantity of ndau assigned to an ndau account to be used as a sort of surety bond for ndau node operations. “Stake” is also a verb describing the process of that assignment.
Primary Stake - ndau from a source account that are staked to a rules account. ndau staked to a Primary Stake account is “co-stake”.
Active node - An active node is a node that has self-staked a minimum quantity of ndau (as set by the BPC).
Resiliency score - A measure of the quality of an active node’s performance in support of the ndau network. It is based on a node’s total stake, uptime/responsiveness, and other metrics.
Validator node - An active node currently assigned to the ndau consensus engine’s validation network.
Transaction fee - All transactions are charged a fee, deducted from the transaction’s source account. Fees are defined by a published fee schedule that is controlled by the BPC. In some cases, a fee’s value may be determined by a formula based on the fields in a transaction rather than being a scalar value.
EAI Service Fees - Mandatory service fees deducted from all EAI: they include
An Ecosystem Funding Fee (4%)
A Market Maker Price Discovery Fee (1%)
A Node Operations Fee (10%)
Node operation rewards – Incentives for node operators to improve network performance and resilience. Rewards are paid from both transaction fees and from node operations fees deducted from EAI.
Recovery Phrase - A 12-word (could be longer in the future) phrase that can be used to reconstruct the keypairs and addresses of all accounts in a wallet.
Wallet - A collection of account addresses and their associated private keys.
Wallet - The ndau mobile app, a Hierarchical Deterministic Wallet (HD Wallet) developed by ndev. A wallet is a client software application used by an ndau holder to manage the collection of ndau accounts they own. ‘Wallet’ is also used to refer to that collection itself: both “I installed the ndau wallet” and “There are six accounts in my wallet” are correct. This is a very confusing term in the cryptocurrency world. It is sometimes also used to refer to the software required to run a node (sometimes that’s called a ‘full wallet’). Only use wallet in the two meanings given above. ndau blockchain transactions only operate on individual accounts: a wallet is a client-side convenience for users.
App Password - The password a user enters whenever they want to open and use the Wallet App.


/*
* Copyright: IRT 2019
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/**
* Utility to parse HbbTV-compliant user-agent strings.
*
* @module HbbTVUserAgentParser
*
* @example
* var userAgentParser = require("hbbtv-lib/tools/HbbTVUserAgentParser");
* var userAgent = HbbTVUserAgentParser('User-Agent: HbbTV/1.2.1 (+PVR+DL; Sonic; 40VX700WDR; 1.32.455; 2.002; test reserved) BKit/445.27.1');
*/
/**
* Object representing the version of the HbbTV specification.
*
* @typedef {object} HbbTVVersion
* @property {number} major
* @property {number} minor
* @property {number} micro
*/
/**
* Object with individual fields of an HbbTV user agent string.
*
* Requirements for certain fields are defined in HbbTV 2 onwards, see section <IP_ADDRESS>.
* familyName is not included in HbbTV versions before 2.0.
*
* 'The "vendorName", "softwareVersion", "familyName" combination, along with "hardwareVersion" where
* included, shall differ between terminals with significantly different implementations or performance.'
*
* @typedef {object} HbbTVUserAgent
* @property {string} str a string with the HbbTV portion of the user agent string
* @property {HbbTVVersion} version the version of the HbbTV specification the device thinks it complies to (due to ETSI rules, usually only differs in the minor part)
* @property {Array<string>} options one or multiple HbbTV capability strings, see clause 10.2.4, e.g. DRM
* @property {string} vendor shall reflect the consumer-facing make / brand of the terminal
* @property {string} model should be representative of the consumer-facing model name to allow log messages to be matched up with user reported problems
* @property {string} swVersion software version
* @property {string} hwVersion optional hardware version
* @property {string} familyName shall have the semantics defined in clause <IP_ADDRESS> of the OIPF DAE specification [1]
* but shall additionally be chosen so as to be globally unique. This shall be achieved either by prefixing with a
* reverse domain name of the organisation allocating the remaining portion of the familyName, or by using a
* version 4 UUID as the familyName, formatted as a simple string (i.e. without any urn:uuid prefix)
* @property {string} reserved for future extensions
*/
/**
* Parses an HbbTV compliant user agent string into its individual fields.
*
* @param {string} userAgentString user agent string of an HbbTV TV. Applications can try to retrieve it from the navigator object, which is mandatory since 2.0,
* or via an HTTP request.
*
* @returns {HbbTVUserAgent} an HbbTVUserAgent or null if ua does not include an HbbTV compliant user agent string.
*/
module.exports = function (ua) {
var version = null;
var fields = null;
var str = null;
try {
if (!ua) {
ua = navigator.userAgent;
}
var reg = /.*(HbbTV\/(\d\.\d\.\d)\s+\((.*)\)).*/g;
var match = reg.exec(ua);
str = match[1];
version = match[2].split('.');
fields = match[3].split(';');
fields[0] = fields[0].trim();
if (fields[0].length > 0)
fields[0] = fields[0].substring(1);
if (fields.length >= 6)
return {
str: str,
version: {
major: parseInt(version[0]),
minor: parseInt(version[1]),
micro: parseInt(version[2])
},
options: fields[0].length > 0 ? fields[0].split("+") : null,
vendor: fields[1],
model: fields[2],
swVersion: fields[3],
hwVersion: fields[4],
familyName: fields.length == 7 ? fields[5] : null,
reserved: fields[fields.length - 1]
};
} catch (e) {
}
return null;
};


Subtraction from l0 or Less |
Count all the flowers in the set. Then count the flowers that were crossed out. How many flowers are left in the set?
Taking away 3 flowers from the set of 8 is subtracting them. Subtraction is taking away something from a whole or from a set. The subtraction sentence for the set of flowers is:
The subtraction sentence is read as “eight minus three is equal to five.”
The minuend is 8. It is the number from which a number is subtracted.
The minus sign (−) is the symbol used in subtraction.
The subtrahend is 3. It is the number subtracted or taken away from the minuend.
The equal sign (=) is used to show the answer.
The difference is the answer in subtraction.


University: {{owner.profile.university}}
{{#if validToken}}Contact person: {{/if}} {{owner.profile.firstName}} {{owner.profile.lastName}}
_id is not set
Please enter the passwordyour contact person gave you.


Home
(current)
About
Modal title
×
...
Shawls
kurti
SHAWL
SHAWL
KURTI
Hurmuch Taka
PKR 12,900
Sizes: 1 XS,1 S, 1 M, 1L
Product Code: 012
Hurmuch Taka
PKR 12,900
Sizes: 1 XS,1 S, 1 M, 1L
Product Code: 012
Hurmuch Taka
PKR 12,900
Sizes: 1 XS,1 S, 1 M, 1L
Product Code: 012


Hi this is a sample application built in Angular 6.0.0 (latest).
This small application uses few of the fundamental concepts of angular and is fully responsive.
I have tried to cover the following things
The left or top section (in small devices) is the main-content-area. The right or bottom(in small devices) is the notification-area.
The main-content-area shows a component which consumes Notifications Service which is responsible for showing the remarks in the notification-area
Please click here to Proceed


About Smoker
Smoker is a biannual event hosted by the Alpha Epsilon of Phi Kappa Sigma Educational Society. It is one of the oldest events hosted at Illinois Institute of Technology campus. All 21+ brothers and alumni are welcome to join our upcoming smoker!
Next Smoker is planned for November 12th & 13th, 2021


I am a User Experience Designer with a focus on prototyping and interaction design. I earned a degree in Digital Media & Design with a concentration in Web & Interactive Media working on projects in both design and development.
Last summer, I worked as a User Experience Design Intern at Fidelity Investments working on an agile design team crafting everything from concept designs and prototypes to usability tests and final deliverables.
This summer I am working at Apple's Engineering Technology Camp, helping to inspire high school juniors and seniors to interact with and advance the technological field.
I design to help people be productive, not get addicted to the experiences I create. Creating products that are intuitive and focused around someone's needs is more important to me than awesome technology.
Speaking with actual users is the best way to understand the problem. I enjoy sitting down and talking directly with people to find out how I can be of the best use.
Below are some of the projects I have worked on over the past few years. These projects include UX design, prototypes, web design, motion graphics and more.
I've created a case study for each project going through my process from the initial concept, the teams I worked with and the final products.