PERLSYN
Section: Perl Programmers Reference Guide (1)Updated: 2009-08-22
Index Return to Main Contents
NAME
perlsyn - Perl syntaxDESCRIPTION
A Perl program consists of a sequence of declarations and statements which run from the top to the bottom. Loops, subroutines and other control structures allow you to jump around within the code.Perl is a free-form language, you can format and indent it however you like. Whitespace mostly serves to separate tokens, unlike languages like Python where it is an important part of the syntax.
Many of Perl's syntactic elements are optional. Rather than requiring you to put parentheses around every function call and declare every variable, you can often leave such explicit elements off and Perl will figure out what you meant. This is known as Do What I Mean, abbreviated DWIM. It allows programmers to be lazy and to code in a style with which they are comfortable.
Perl borrows syntax and concepts from many languages: awk, sed, C, Bourne Shell, Smalltalk, Lisp and even English. Other languages have borrowed syntax from Perl, particularly its regular expression extensions. So if you have programmed in another language you will see familiar pieces in Perl. They often work the same, but see perltrap for information about how they differ.
Declarations
The only things you need to declare in Perl are report formats and subroutines (and sometimes not even subroutines). A variable holds the undefined value ("undef") until it has been assigned a defined value, which is anything other than "undef". When used as a number, "undef" is treated as 0; when used as a string, it is treated as the empty string, ""; and when used as a reference that isn't being assigned to, it is treated as an error. If you enable warnings, you'll be notified of an uninitialized value whenever you treat "undef" as a string or a number. Well, usually. Boolean contexts, such as:
my $a; if ($a) {}
are exempt from warnings (because they care about truth rather than definedness). Operators such as "++", "--", "+=", "-=", and ".=", that operate on undefined left values such as:
my $a; $a++;
are also always exempt from such warnings.
A declaration can be put anywhere a statement can, but has no effect on the execution of the primary sequence of statements---declarations all take effect at compile time. Typically all the declarations are put at the beginning or the end of the script. However, if you're using lexically-scoped private variables created with "my()", you'll have to make sure your format or subroutine definition is within the same block scope as the my if you expect to be able to access those private variables.
Declaring a subroutine allows a subroutine name to be used as if it were a list operator from that point forward in the program. You can declare a subroutine without defining it by saying "sub name", thus:
sub myname; $me = myname $0 or die "can't get myname";
Note that myname() functions as a list operator, not as a unary operator; so be careful to use "or" instead of "||" in this case. However, if you were to declare the subroutine as "sub myname ($)", then "myname" would function as a unary operator, so either "or" or "||" would work.
Subroutines declarations can also be loaded up with the "require" statement or both loaded and imported into your namespace with a "use" statement. See perlmod for details on this.
A statement sequence may contain declarations of lexically-scoped variables, but apart from declaring a variable name, the declaration acts like an ordinary statement, and is elaborated within the sequence of statements as if it were an ordinary statement. That means it actually has both compile-time and run-time effects.
Comments
Text from a "#" character until the end of the line is a comment, and is ignored. Exceptions include "#" inside a string or regular expression.Simple Statements
The only kind of simple statement is an expression evaluated for its side effects. Every simple statement must be terminated with a semicolon, unless it is the final statement in a block, in which case the semicolon is optional. (A semicolon is still encouraged if the block takes up more than one line, because you may eventually add another line.) Note that there are some operators like "eval {}" and "do {}" that look like compound statements, but aren't (they're just TERMs in an expression), and thus need an explicit termination if used as the last item in a statement.Truth and Falsehood
The number 0, the strings '0' and '', the empty list "()", and "undef" are all false in a boolean context. All other values are true. Negation of a true value by "!" or "not" returns a special false value. When evaluated as a string it is treated as '', but as a number, it is treated as 0.Statement Modifiers
Any simple statement may optionally be followed by a SINGLE modifier, just before the terminating semicolon (or block ending). The possible modifiers are:
if EXPR unless EXPR while EXPR until EXPR foreach LIST
The "EXPR" following the modifier is referred to as the ``condition''. Its truth or falsehood determines how the modifier will behave.
"if" executes the statement once if and only if the condition is true. "unless" is the opposite, it executes the statement unless the condition is true (i.e., if the condition is false).
print "Basset hounds got long ears" if length $ear >= 10; go_outside() and play() unless $is_raining;
The "foreach" modifier is an iterator: it executes the statement once for each item in the LIST (with $_ aliased to each item in turn).
print "Hello $_!\n" foreach qw(world Dolly nurse);
"while" repeats the statement while the condition is true. "until" does the opposite, it repeats the statement until the condition is true (or while the condition is false):
# Both of these count from 0 to 10. print $i++ while $i <= 10; print $j++ until $j > 10;
The "while" and "until" modifiers have the usual ""while" loop" semantics (conditional evaluated first), except when applied to a "do"-BLOCK (or to the deprecated "do"-SUBROUTINE statement), in which case the block executes once before the conditional is evaluated. This is so that you can write loops like:
do { $line = <STDIN>; ... } until $line eq ".\n";
See ``do'' in perlfunc. Note also that the loop control statements described later will NOT work in this construct, because modifiers don't take loop labels. Sorry. You can always put another block inside of it (for "next") or around it (for "last") to do that sort of thing. For "next", just double the braces:
do {{ next if $x == $y; # do something here }} until $x++ > $z;
For "last", you have to be more elaborate:
LOOP: { do { last if $x = $y**2; # do something here } while $x++ <= $z; }
NOTE: The behaviour of a "my" statement modified with a statement modifier conditional or loop construct (e.g. "my $x if ...") is undefined. The value of the "my" variable may be "undef", any previously assigned value, or possibly anything else. Don't rely on it. Future versions of perl might do something different from the version of perl you try it out on. Here be dragons.
Compound Statements
In Perl, a sequence of statements that defines a scope is called a block. Sometimes a block is delimited by the file containing it (in the case of a required file, or the program as a whole), and sometimes a block is delimited by the extent of a string (in the case of an eval).But generally, a block is delimited by curly brackets, also known as braces. We will call this syntactic construct a BLOCK.
The following compound statements may be used to control flow:
if (EXPR) BLOCK if (EXPR) BLOCK else BLOCK if (EXPR) BLOCK elsif (EXPR) BLOCK ... else BLOCK LABEL while (EXPR) BLOCK LABEL while (EXPR) BLOCK continue BLOCK LABEL until (EXPR) BLOCK LABEL until (EXPR) BLOCK continue BLOCK LABEL for (EXPR; EXPR; EXPR) BLOCK LABEL foreach VAR (LIST) BLOCK LABEL foreach VAR (LIST) BLOCK continue BLOCK LABEL BLOCK continue BLOCK
Note that, unlike C and Pascal, these are defined in terms of BLOCKs, not statements. This means that the curly brackets are required--no dangling statements allowed. If you want to write conditionals without curly brackets there are several other ways to do it. The following all do the same thing:
if (!open(FOO)) { die "Can't open $FOO: $!"; } die "Can't open $FOO: $!" unless open(FOO); open(FOO) or die "Can't open $FOO: $!"; # FOO or bust! open(FOO) ? 'hi mom' : die "Can't open $FOO: $!"; # a bit exotic, that last one
The "if" statement is straightforward. Because BLOCKs are always bounded by curly brackets, there is never any ambiguity about which "if" an "else" goes with. If you use "unless" in place of "if", the sense of the test is reversed.
The "while" statement executes the block as long as the expression is true. The "until" statement executes the block as long as the expression is false. The LABEL is optional, and if present, consists of an identifier followed by a colon. The LABEL identifies the loop for the loop control statements "next", "last", and "redo". If the LABEL is omitted, the loop control statement refers to the innermost enclosing loop. This may include dynamically looking back your call-stack at run time to find the LABEL. Such desperate behavior triggers a warning if you use the "use warnings" pragma or the -w flag.
If there is a "continue" BLOCK, it is always executed just before the conditional is about to be evaluated again. Thus it can be used to increment a loop variable, even when the loop has been continued via the "next" statement.
Loop Control
The "next" command starts the next iteration of the loop:
LINE: while (<STDIN>) { next LINE if /^#/; # discard comments ... }
The "last" command immediately exits the loop in question. The "continue" block, if any, is not executed:
LINE: while (<STDIN>) { last LINE if /^$/; # exit when done with header ... }
The "redo" command restarts the loop block without evaluating the conditional again. The "continue" block, if any, is not executed. This command is normally used by programs that want to lie to themselves about what was just input.
For example, when processing a file like /etc/termcap. If your input lines might end in backslashes to indicate continuation, you want to skip ahead and get the next record.
while (<>) { chomp; if (s/\\$//) { $_ .= <>; redo unless eof(); } # now process $_ }
which is Perl short-hand for the more explicitly written version:
LINE: while (defined($line = <ARGV>)) { chomp($line); if ($line =~ s/\\$//) { $line .= <ARGV>; redo LINE unless eof(); # not eof(ARGV)! } # now process $line }
Note that if there were a "continue" block on the above code, it would get executed only on lines discarded by the regex (since redo skips the continue block). A continue block is often used to reset line counters or "?pat?" one-time matches:
# inspired by :1,$g/fred/s//WILMA/ while (<>) { ?(fred)? && s//WILMA $1 WILMA/; ?(barney)? && s//BETTY $1 BETTY/; ?(homer)? && s//MARGE $1 MARGE/; } continue { print "$ARGV $.: $_"; close ARGV if eof(); # reset $. reset if eof(); # reset ?pat? }
If the word "while" is replaced by the word "until", the sense of the test is reversed, but the conditional is still tested before the first iteration.
The loop control statements don't work in an "if" or "unless", since they aren't loops. You can double the braces to make them such, though.
if (/pattern/) {{ last if /fred/; next if /barney/; # same effect as "last", but doesn't document as well # do something here }}
This is caused by the fact that a block by itself acts as a loop that executes once, see ``Basic BLOCKs''.
The form "while/if BLOCK BLOCK", available in Perl 4, is no longer available. Replace any occurrence of "if BLOCK" by "if (do BLOCK)".
For Loops
Perl's C-style "for" loop works like the corresponding "while" loop; that means that this:
for ($i = 1; $i < 10; $i++) { ... }
is the same as this:
$i = 1; while ($i < 10) { ... } continue { $i++; }
There is one minor difference: if variables are declared with "my" in the initialization section of the "for", the lexical scope of those variables is exactly the "for" loop (the body of the loop and the control sections).
Besides the normal array index looping, "for" can lend itself to many other interesting applications. Here's one that avoids the problem you get into if you explicitly test for end-of-file on an interactive file descriptor causing your program to appear to hang.
$on_a_tty = -t STDIN && -t STDOUT; sub prompt { print "yes? " if $on_a_tty } for ( prompt(); <STDIN>; prompt() ) { # do something }
Using "readline" (or the operator form, "<EXPR>") as the conditional of a "for" loop is shorthand for the following. This behaviour is the same as a "while" loop conditional.
for ( prompt(); defined( $_ = <STDIN> ); prompt() ) { # do something }
Foreach Loops
The "foreach" loop iterates over a normal list value and sets the variable VAR to be each element of the list in turn. If the variable is preceded with the keyword "my", then it is lexically scoped, and is therefore visible only within the loop. Otherwise, the variable is implicitly local to the loop and regains its former value upon exiting the loop. If the variable was previously declared with "my", it uses that variable instead of the global one, but it's still localized to the loop. This implicit localisation occurs only in a "foreach" loop.The "foreach" keyword is actually a synonym for the "for" keyword, so you can use "foreach" for readability or "for" for brevity. (Or because the Bourne shell is more familiar to you than csh, so writing "for" comes more naturally.) If VAR is omitted, $_ is set to each value.
If any element of LIST is an lvalue, you can modify it by modifying VAR inside the loop. Conversely, if any element of LIST is NOT an lvalue, any attempt to modify that element will fail. In other words, the "foreach" loop index variable is an implicit alias for each item in the list that you're looping over.
If any part of LIST is an array, "foreach" will get very confused if you add or remove elements within the loop body, for example with "splice". So don't do that.
"foreach" probably won't do what you expect if VAR is a tied or other special variable. Don't do that either.
Examples:
for (@ary) { s/foo/bar/ } for my $elem (@elements) { $elem *= 2; } for $count (10,9,8,7,6,5,4,3,2,1,'BOOM') { print $count, "\n"; sleep(1); } for (1..15) { print "Merry Christmas\n"; } foreach $item (split(/:[\\\n:]*/, $ENV{TERMCAP})) { print "Item: $item\n"; }
Here's how a C programmer might code up a particular algorithm in Perl:
for (my $i = 0; $i < @ary1; $i++) { for (my $j = 0; $j < @ary2; $j++) { if ($ary1[$i] > $ary2[$j]) { last; # can't go to outer :-( } $ary1[$i] += $ary2[$j]; } # this is where that last takes me }
Whereas here's how a Perl programmer more comfortable with the idiom might do it:
OUTER: for my $wid (@ary1) { INNER: for my $jet (@ary2) { next OUTER if $wid > $jet; $wid += $jet; } }
See how much easier this is? It's cleaner, safer, and faster. It's cleaner because it's less noisy. It's safer because if code gets added between the inner and outer loops later on, the new code won't be accidentally executed. The "next" explicitly iterates the other loop rather than merely terminating the inner one. And it's faster because Perl executes a "foreach" statement more rapidly than it would the equivalent "for" loop.
Basic BLOCKs
A BLOCK by itself (labeled or not) is semantically equivalent to a loop that executes once. Thus you can use any of the loop control statements in it to leave or restart the block. (Note that this is NOT true in "eval{}", "sub{}", or contrary to popular belief "do{}" blocks, which do NOT count as loops.) The "continue" block is optional.The BLOCK construct can be used to emulate case structures.
SWITCH: { if (/^abc/) { $abc = 1; last SWITCH; } if (/^def/) { $def = 1; last SWITCH; } if (/^xyz/) { $xyz = 1; last SWITCH; } $nothing = 1; }
Such constructs are quite frequently used, because older versions of Perl had no official "switch" statement.
Switch statements
Starting from Perl 5.10, you can say
use feature "switch";
which enables a switch feature that is closely based on the Perl 6 proposal.
The keywords "given" and "when" are analogous to "switch" and "case" in other languages, so the code above could be written as
given($_) { when (/^abc/) { $abc = 1; } when (/^def/) { $def = 1; } when (/^xyz/) { $xyz = 1; } default { $nothing = 1; } }
This construct is very flexible and powerful. For example:
use feature ":5.10"; given($foo) { when (undef) { say '$foo is undefined'; } when ("foo") { say '$foo is the string "foo"'; } when ([1,3,5,7,9]) { say '$foo is an odd digit'; continue; # Fall through } when ($_ < 100) { say '$foo is numerically less than 100'; } when (\&complicated_check) { say 'a complicated check for $foo is true'; } default { die q(I don't know what to do with $foo); } }
"given(EXPR)" will assign the value of EXPR to $_ within the lexical scope of the block, so it's similar to
do { my $_ = EXPR; ... }
except that the block is automatically broken out of by a successful "when" or an explicit "break".
Most of the power comes from implicit smart matching:
when($foo)
is exactly equivalent to
when($_ ~~ $foo)
Most of the time, "when(EXPR)" is treated as an implicit smart match of $_, i.e. "$_ ~~ EXPR". (See ``Smart matching in detail'' for more information on smart matching.) But when EXPR is one of the below exceptional cases, it is used directly as a boolean:
- *
- a subroutine or method call
- *
- a regular expression match, i.e. "/REGEX/" or "$foo =~ /REGEX/", or a negated regular expression match ("!/REGEX/" or "$foo !~ /REGEX/").
- *
- a comparison such as "$_ < 10" or "$x eq "abc"" (or of course "$_ ~~ $c")
- *
- "defined(...)", "exists(...)", or "eof(...)"
- *
- a negated expression "!(...)" or "not (...)", or a logical exclusive-or "(...) xor (...)".
- *
- a filetest operator, with the exception of "-s", "-M", "-A", and "-C", that return numerical values, not boolean ones.
- *
- the ".." and "..." flip-flop operators.
In those cases the value of EXPR is used directly as a boolean.
Furthermore:
- *
- If EXPR is "... && ..." or "... and ...", the test is applied recursively to both arguments. If both arguments pass the test, then the argument is treated as boolean.
- *
- If EXPR is "... || ...", "... // ..." or "... or ...", the test is applied recursively to the first argument.
These rules look complicated, but usually they will do what you want. For example you could write:
when (/^\d+$/ && $_ < 75) { ... }
Another useful shortcut is that, if you use a literal array or hash as the argument to "given", it is turned into a reference. So "given(@foo)" is the same as "given(\@foo)", for example.
"default" behaves exactly like "when(1 == 1)", which is to say that it always matches.
You can use the "break" keyword to break out of the enclosing "given" block. Every "when" block is implicitly ended with a "break".
You can use the "continue" keyword to fall through from one case to the next:
given($foo) { when (/x/) { say '$foo contains an x'; continue } when (/y/) { say '$foo contains a y' } default { say '$foo does not contain a y' } }
Instead of using "given()", you can use a "foreach()" loop. For example, here's one way to count how many times a particular string occurs in an array:
my $count = 0; for (@array) { when ("foo") { ++$count } } print "\@array contains $count copies of 'foo'\n";
On exit from the "when" block, there is an implicit "next". You can override that with an explicit "last" if you're only interested in the first match.
This doesn't work if you explicitly specify a loop variable, as in "for $item (@array)". You have to use the default variable $_. (You can use "for my $_ (@array)".)
The behaviour of a smart match depends on what type of thing its arguments are. The behaviour is determined by the following table: the first row that applies determines the match behaviour (which is thus mostly determined by the type of the right operand). Note that the smart match implicitly dereferences any non-blessed hash or array ref, so the ``Hash'' and ``Array'' entries apply in those cases. (For blessed references, the ``Object'' entries apply.)
Note that the ``Matching Code'' column is not always an exact rendition. For example, the smart match operator short-circuits whenever possible, but "grep" does not.
$a $b Type of Match Implied Matching Code ====== ===== ===================== ============= Any undef undefined !defined $a Any Object invokes ~~ overloading on $object, or dies Hash CodeRef sub truth for each key[1] !grep { !$b->($_) } keys %$a Array CodeRef sub truth for each elt[1] !grep { !$b->($_) } @$a Any CodeRef scalar sub truth $b->($a) Hash Hash hash keys identical (every key is found in both hashes) Array Hash hash slice existence grep { exists $b->{$_} } @$a Regex Hash hash key grep grep /$a/, keys %$b undef Hash always false (undef can't be a key) Any Hash hash entry existence exists $b->{$a} Hash Array hash slice existence grep { exists $a->{$_} } @$b Array Array arrays are comparable[2] Regex Array array grep grep /$a/, @$b undef Array array contains undef grep !defined, @$b Any Array match against an array element[3] grep $a ~~ $_, @$b Hash Regex hash key grep grep /$b/, keys %$a Array Regex array grep grep /$b/, @$a Any Regex pattern match $a =~ /$b/ Object Any invokes ~~ overloading on $object, or falls back: Any Num numeric equality $a == $b Num numish[4] numeric equality $a == $b undef Any undefined !defined($b) Any Any string equality $a eq $b 1 - empty hashes or arrays will match. 2 - that is, each element smart-matches the element of same index in the other array. [3] 3 - If a circular reference is found, we fall back to referential equality. 4 - either a real number, or a string that looks like a number
Custom matching via overloading
You can change the way that an object is matched by overloading the "~~" operator. This may alter the usual smart match semantics.
It should be noted that "~~" will refuse to work on objects that don't overload it (in order to avoid relying on the object's underlying structure).
Note also that smart match's matching rules take precedence over overloading, so if $obj has smart match overloading, then
$obj ~~ X
will not automatically invoke the overload method with X as an argument; instead the table above is consulted as normal, and based in the type of X, overloading may or may not be invoked.
See overload.
The Perl 5 smart match and "given"/"when" constructs are not absolutely identical to their Perl 6 analogues. The most visible difference is that, in Perl 5, parentheses are required around the argument to "given()" and "when()". Parentheses in Perl 6 are always optional in a control construct such as "if()", "while()", or "when()"; they can't be made optional in Perl 5 without a great deal of potential confusion, because Perl 5 would parse the expression
given $foo { ... }
as though the argument to "given" were an element of the hash %foo, interpreting the braces as hash-element syntax.
The table of smart matches is not identical to that proposed by the Perl 6 specification, mainly due to the differences between Perl 6's and Perl 5's data models.
In Perl 6, "when()" will always do an implicit smart match with its argument, whilst it is convenient in Perl 5 to suppress this implicit smart match in certain situations, as documented above. (The difference is largely because Perl 5 does not, even internally, have a boolean type.)
Goto
Although not for the faint of heart, Perl does support a "goto" statement. There are three forms: "goto"-LABEL, "goto"-EXPR, and "goto"-&NAME. A loop's LABEL is not actually a valid target for a "goto"; it's just the name of the loop.The "goto"-LABEL form finds the statement labeled with LABEL and resumes execution there. It may not be used to go into any construct that requires initialization, such as a subroutine or a "foreach" loop. It also can't be used to go into a construct that is optimized away. It can be used to go almost anywhere else within the dynamic scope, including out of subroutines, but it's usually better to use some other construct such as "last" or "die". The author of Perl has never felt the need to use this form of "goto" (in Perl, that is---C is another matter).
The "goto"-EXPR form expects a label name, whose scope will be resolved dynamically. This allows for computed "goto"s per FORTRAN, but isn't necessarily recommended if you're optimizing for maintainability:
goto(("FOO", "BAR", "GLARCH")[$i]);
The "goto"-&NAME form is highly magical, and substitutes a call to the named subroutine for the currently running subroutine. This is used by "AUTOLOAD()" subroutines that wish to load another subroutine and then pretend that the other subroutine had been called in the first place (except that any modifications to @_ in the current subroutine are propagated to the other subroutine.) After the "goto", not even "caller()" will be able to tell that this routine was called first.
In almost all cases like this, it's usually a far, far better idea to use the structured control flow mechanisms of "next", "last", or "redo" instead of resorting to a "goto". For certain applications, the catch and throw pair of "eval{}" and die() for exception processing can also be a prudent approach.
PODs: Embedded Documentation
Perl has a mechanism for intermixing documentation with source code. While it's expecting the beginning of a new statement, if the compiler encounters a line that begins with an equal sign and a word, like this
=head1 Here There Be Pods!
Then that text and all remaining text up through and including a line beginning with "=cut" will be ignored. The format of the intervening text is described in perlpod.
This allows you to intermix your source code and your documentation text freely, as in
=item snazzle($) The snazzle() function will behave in the most spectacular form that you can possibly imagine, not even excepting cybernetic pyrotechnics. =cut back to the compiler, nuff of this pod stuff! sub snazzle($) { my $thingie = shift; ......... }
Note that pod translators should look at only paragraphs beginning with a pod directive (it makes parsing easier), whereas the compiler actually knows to look for pod escapes even in the middle of a paragraph. This means that the following secret stuff will be ignored by both the compiler and the translators.
$a=3; =secret stuff warn "Neither POD nor CODE!?" =cut back print "got $a\n";
You probably shouldn't rely upon the "warn()" being podded out forever. Not all pod translators are well-behaved in this regard, and perhaps the compiler will become pickier.
One may also use pod directives to quickly comment out a section of code.
Plain Old Comments (Not!)
Perl can process line directives, much like the C preprocessor. Using this, one can control Perl's idea of filenames and line numbers in error or warning messages (especially for strings that are processed with "eval()"). The syntax for this mechanism is the same as for most C preprocessors: it matches the regular expression
# example: '# line 42 "new_filename.plx"' /^\# \s* line \s+ (\d+) \s* (?:\s("?)([^"]+)\2)? \s* $/x
with $1 being the line number for the next line, and $3 being the optional filename (specified with or without quotes).
There is a fairly obvious gotcha included with the line directive: Debuggers and profilers will only show the last source line to appear at a particular line number in a given file. Care should be taken not to cause line number collisions in code you'd like to debug later.
Here are some examples that you should be able to type into your command shell:
% perl # line 200 "bzzzt" # the `#' on the previous line must be the first char on line die 'foo'; __END__ foo at bzzzt line 201. % perl # line 200 "bzzzt" eval qq[\n#line 2001 ""\ndie 'foo']; print $@; __END__ foo at - line 2001. % perl eval qq[\n#line 200 "foo bar"\ndie 'foo']; print $@; __END__ foo at foo bar line 200. % perl # line 345 "goop" eval "\n#line " . __LINE__ . ' "' . __FILE__ ."\"\ndie 'foo'"; print $@; __END__ foo at goop line 345.
Index
This document was created by man2html, using the manual pages.
Time: 05:29:08 GMT, December 24, 2015


Dasboard
(current)
Purchase
Purchase
Reporting
Master Data
Quotation
Purchase order
Received note
Return order
Quotation report
Purchase order report
Received note report
Return order report
Purchase Summary report
Received Summary report
Vat Setting
Purchase type
Sale
Sale
Reporting
Master Data
Requisition
Invoice order
Return order
Credit note
Debit note
Requisition report
Invoice report
Return order report
Credit note report
Debit note report
Invoice Summary
Vat Setting
Invoice type
Logistics
Logistics
Reporting
Master Data
ส่งสินค้า
รายการค้างส่ง
รายการส่งสินค้า
รายการค้างส่ง
Summary
Type Transport
Warehouse
Warehouse
Reporting
Master Data
Stocking
Reserve Stock
Incoming
Outing
Check Stock (Audit stock)
Stocking Report
Reserve Stock Report
Incoming Report
Outing Report
Check Stock (Audit stock)
Type Stock
Accounting
Accounting
Reporting
Master Data
ชำระเงิน
เรียกเก็บเงิน
รับเงิน
ต้นทุนสินค้า
Employee Salary
Invoice
Outstanding
Cost Item
Employee Salary
Bank
DueDate Settings
Type Tranfer
Human Resource
Manager Employees
Reporting
Standard Settings
Master Data
Employee
Salary
Salary Report
Employee Report
Out of work
Salary Default
Bonus Default
OT Settings
Payroll Deduction Settings
Position
Date Settings
General Data
Partner Data
Main Data
Properties data product
Customer
Supplier
Group of customer
Product
Other
Color product
Unit product
Group product
Size product
Type product
Admin
User Manage
Data Manage
Systems
Users Management
User Role
Backup Data
Restore Data
Setting Scheduler
Logs Status
Logs Systems
Monitoring
Application Information
Version : 0.0.1
12
Notification 1
Notification 2
Notification 3
Profile
Change password
History
Logut
You are here :
Dashbaord
Dashbaord
Print
Summary Invoices
Summary purchase orders
Recently Invoices
Recently Activities
Receiving purchase Orders
Invoice waiting transfer
Payment orders


Step 1 Step 2 Step 3 Step 4
We start with a basic layout and some sample content for which we want to create a tour.
Click here to startYou can use the html data attribute to setup each tour step

 ...

Some text
No! More is coming soon!
© 2012-2013 by Small Improvements


Road traffic safety is a major societal issue costing up to 4% of a country's GNP, while
traffic crashes are said to become the fifth leading cause of death by 2030. The 2017
European Commission Fact sheet shows how the United Kingdom is a leader in road safety with 27
fatalities per millions of inhabitants while France stands slightly above average with 57. What’s
more, the United Kingdom provides their traffic reports from 2005 to 2015. While it is well known
that the majority of road accidents happens while commuting, can the figures prove it ? Therefore,
our goal is to extract information from the UK dataset to put common road safety beliefs into
perspectives whether it is about driving conditions or the likelihood of being a casualty.
If you wish to know more about the technical details of our work, check our Github repo here.
Once you dive in this dataset, you soon realize that there are a lot of interesting leads: specific places and accidents, hypotheses on drivers or vehicles to check … Yet, time is the limit. Therefore, after getting familiar with the datasets and the road safety situation in the United Kingdom, we decided to focus on studying the correlation between our features and the number of casualties. In doing so, we encountered several interesting outliers that we decided to investigate to get to the bottom of the story. Finally, we provide some indications to justify well-known car insurance bonuses.
In order to visualize the repartition of road accidents in the UK, we plot a sample of the accidents on a map. We were looking for specific trends or localization that would appear as more accident-prone than others.
Most accidents seem to be located within cities or their urban areas, especially around London. There are also many accidents on the roads between major cities, for instance the area between Manchester, Liverpool and Preston in the North of England. Consequently, a deeper analysis of the distribution of accidents in rural or urban areas was necessary. Actually, according to our data 40% of accidents happen in rural areas. Moreover, this value has not changed significantly for the last 10 years: this trend is constant over time.
As expected, the number of casualties has decreased linearly over the years except for a bump in 2014. What is even more interesting is when we compare this evolution, to the evolution of the traffic itself which increased by more than 5% over the same period. It shows that this significant decrease over time is not due to lower traffic but to policies and technical upgrades made to the vehicles! Road safety policies are working!
One last thing to look at from a global viewpoint is the repartition of casualties from 2004 to 2016:
The first observation is that passengers make for around 25% of the accident casualties,
with a majority of them being car passengers rather than coach ones. Moreover, pedestrians
represent more than 10% of the casualties, which is a very significant part as they can only
be impacted in specific circumstances in urban areas: they are almost always the victims rather than
the person causing the accident. Finally, casualties still mainly concern drivers and riders: people
who are allegedly responsible for taking every possible steps in order to avoid accidents. It could be
explained in two ways: the high proportion of people taking their car alone, to commute for instance,
and the increasing part of bike riders having road accidents.
Despite this context, the government has still taken no action to make wearing helmets compulsory
for bike users.
Who has never been stuck in traffic? One could imagine that a reduced pace rhymes with less accidents? Or on the opposite, more cars on the road entails more accidents? We used our data to demonstrate the second proposition. While the trend looks alike for week days there is a huge difference with week-ends.
Rush hours are blatant at 8am and around 5pm, plus it is interesting to notice that
the peak lasts longer in the afternoon: are people tired and thus less alert ? While on week-ends,
people seem to be moving around lunch and tea time (do not forget we are talking about UK!).
In order to understand whether accidents related to commuting are due to traffic jams or just to the
increase of drivers on the road, we compared rush hour in urban and rural areas during week days and
week-ends.
As one can see, rush hours are still seeable in rural areas even though they are less
pronounced than for urban areas. What is interesting is that the difference between rural and urban
areas decrease on Sunday: are people going to the countryside on Sunday ?
On the whole, reducing the number of vehicles involved in rush hours could led to a significant
decrease of the number of accidents: commuting at odd hours (10am - 8pm for instance) is safer than
commuting “like everyone else”.
"Which features have the bigger correlation coefficient with the number of accidents?" That’s the kind of question road safety experts must ask themselves everyday, in order to build efficient road safety actions.
Once we set aside the number of vehicles involved, the two most significant features are the type of the area (i.e. whether it is urban or rural) and the type of the road. The correlation between the number of casualties and these features was far above its correlation with the light conditions or the weather which are almost negligible unlike what people usually think! That’s quite surprising, thus we decided to dig deeper to understand and maybe explain this cliché.
The common knowledge says that driving when the weather is poor is more dangerous. Therefore, we tried to spot a difference in the number of accidents when the weather is poor or not. The problem is we do not know how often the weather is bad and therefore we do not have any proper normalization. For that reason we plotted the average number of casualties per accident given many different weather condition:
But that plot showed that there isn’t much difference between different weather conditions. The second step was to find the most dangerous locations in the UK and to compute the frequencies of accidents when the weather is bad at these dangerous locations:
The plot show that there is mostly no difference across these different locations, telling us that they are not more dangerous when the weather is bad. However there is a clear outlier that merits further work. It corresponds to the location (51.498, -0.497) which we checked on Google Maps:
And the funny thing is that we discovered that this location was indeed particularly dangerous and that during bad weather it could be particularly difficult for a car on the right lane to be able to enter the road… So, act up UK!
Every driver has to be covered by a car insurance of which fares are a very sensitive topics,
depending on age, experience and even gender. Bonuses are supposed to depend on established facts
enabling the computation of the likelihood of having a car accident. For instance, some insurances
offer bonuses for female driver: to what extent can our data support this advantage?
From 2005 to 2015, data shows that female drivers almost have half as much car accident than male
drivers, justifying a bonuses for car insurance companies. Yet, we can not conclude that it is safer
to drive for women, because the difference in the number of accident could be explained by a
difference in the number of driver: yet, are men driving twice as much as women?
Is there any other features which could be taken into account to propose bonuses to client? We investigated the other features provided in the dataset and came to the following conclusions:
In a nutshell, this data is highly valuable for insurance companies because it helps computing the likelihood of car accident for a driver depending on several characteristics. Combined with the frequency of insured drivers it can build a relevant overview of at-risk-drivers. One also has to notice that combining such data can be quite intrusive for insured persons and goes against the concept of sympathy behind insurance.
The goal of this study was to aggregate and understand data on road accidents in the leading country
for road safety in Europe: the United Kingdom. By feeding our datasets into the Big Data blackbox,
we gained insights and highlighted trends with some surprises.
Choosing among the endless leads provided by the data has been a challenge. Yet, the biggest
challenge encountered has been the lack of information on traffic itself which forced us into
thinking
differently and come up with innovative baselines.
Finally, studying road accidents has been a very interesting and challenging topic illustrating how
data science has a highly positive and concrete impact on policies and government decisions.


GeoPattern
This is a JavaScript port of jasonlong/geo_pattern with a live preview page and is derived from the background generator originally used for GitHub Guides.
Usage
Web
Include the minified script. jQuery is optional.
<script src="js/jquery.min.js"></script> <!-- optional -->
<script src="js/geopattern.min.js"></script>
Use either the GeoPattern
browser global or the jQuery plugin:
// Use the global...
var pattern = GeoPattern.generate('GitHub');
$('#geopattern').css('background-image', pattern.toDataUrl());
// ...or the plugin
$('#geopattern').geopattern('GitHub');
For backwards compatibility with the script on the Guides, the source hash for generation can be supplied with a data-title-sha
attribute on the element. If the attribute exists, the generator will ignore the input string and use the supplied hash.
View geopattern.html
for a complete example.
Node.js
npm install geopattern
After requiring geopattern
, the API is identical to the browser version, minus the jQuery plugin.
var GeoPattern = require('geopattern');
var pattern = GeoPattern.generate('GitHub');
pattern.toDataUrl(); // url("data:image/svg+xml;...
API
GeoPattern.generate(string, options)
Returns a newly-generated, tiling SVG Pattern.
-
string
Will be hashed using the SHA1 algorithm, and the resulting hash will be used as the seed for generation. -
options.color
Specify an exact background color. This is a CSS hexadecimal color value. -
options.baseColor
Controls the relative background color of the generated image. The color is not identical to that used in the pattern because the hue is rotated by the generator. This is a CSS hexadecimal color value, which defaults to#933c3c
. -
options.generator
Determines the pattern. All of the original patterns are available in this port, and their names are camelCased.
Pattern.color
Gets the pattern’s background color as a hexadecimal string.
GeoPattern.generate('GitHub').color // => "#455e8a"
Pattern.toString() and Pattern.toSvg()
Gets the SVG string representing the pattern.
Pattern.toBase64()
Gets the SVG as a Base64-encoded string.
Pattern.toDataUri()
Gets the pattern as a data URI, i.e. data:image/svg+xml;base64,PHN2ZyB...
.
Pattern.toDataUrl()
Gets the pattern as a data URL suitable for use as a CSS background-image
, i.e. url("data:image/svg+xml;base64,PHN2ZyB...")
.
License
Licensed under the terms of the MIT License, the full text of which can be read in LICENSE.


CrimPapers
Articles published on 28 July 2020
On 28 July 2020, 11 new articles were published in 10 journals.
From Probabilities to Possibilities: Terrorism Peace Bonds, Pre-Emptive Security, and Modulations of Criminal Law
The Ride Study: Effects of Body‐worn Cameras on Public Perceptions of Police Interactions by Alana Saulnier,
ryan Lahay,
william P. McCarty,
carrie Sanders
Book Review: Undocumented Storytellers: Narrating the Immigrant Rights Movement by Krista M. Perreira
Book Review: Pathogenic Policing: Immigration Enforcement and Health in the U.s. South by Mercedes Valadez
Internalized Messages: the Role of Sexual Violence Normalization on Meaning-Making After Campus Sexual Violence by Laura Sinko, Michelle Munro-Kramer, Terri Conley, Denise Saint Arnault
Covid-19 and Domestic Violence: An Indirect Path to Social and Economic Crisis
Measuring Stalking: the Development and Evaluation of the Stalking Assessment Indices (sai) by Troy E. McEwan, Melanie Simmons, Taryn Clothier, Svenja Senkans
Guilt By Association: Mock Jurors’ Perceptions of Defendants and Victims With Criminal Family Members by Peter O. Rerick, Tyler N. Livingston, Monica K. Miller
Perceptions of the Effectiveness of Security Measures Used At Security Estates: Case Studies From Centurion in the City of Tshwane, Gauteng
“I Will Tell You A Story About Jihad”: Isis’s Propaganda and Narrative Advertising by Anna Kruglova
Public Support For Solitary Confinement: A Randomized Experiment of Belief Updating and Confirmation Bias by Kayla J. Labranche, Ryan M. Labrecque


{% load i18n wagtailadmin_tags %} {% trans "Submit for review" as title_str %} {% include "wagtailadmin/shared/header.html" with title=title_str icon='doc-empty-inverse' %}
{{ err }}
Enter a user name or email address


Form Advanced
Tags Input
Input Tags
Just add data-role="tagsinput"
to your input field to automatically change it to a tags input field.
True multi value
Use a <select multiple />
as your input element for a tags input, to gain true multivalue support.
Instead of a comma separated string, the values will be set in an array. Existing <option />
elements will automatically be set as tags. This makes it also possible to create tags containing a comma.
Switchery
Basic
Add an attribute
data-plugin="switchery" data-color="@colors"
to your input element and it will be converted into switch.
Sizes
Add an attribute
data-size="small",data-size="large"
to your input element and it will be converted into switch.
Secondary color
Add an attribute
data-color="@color" data-secondary-color="@color"
to your input element and it will be converted into switch.
Multiple Select
Default
Use a
<select multiple />
as your input element for a tags input, to gain true multivalue support.
Grouped Options
Use a
<select multiple />
as your input element for a tags input, to gain true multivalue support.
Searchable
Use a
<select multiple />
as your input element for a tags input, to gain true multivalue support.
Select2
Single Select
Multiple Select
Limiting the number of selections
Input Masks
Use the button classes on an <a>
, <button>
, or <input>
element.
Bootstrap-select
The jQuery plugin that brings select elements into the 21st century with intuitive multiselection, searching, and much more. Now with Bootstrap 4 support.
Create your <select>
with the .selectpicker
class.
It also works with option groups:
You can also show the tick icon on single select
with the show-tick
class:
And with multiple selects:
You can limit the number of elements you are allowed to select via the
data-max-option
attribute. It also works for option groups.
You can limit the number of elements you are allowed to select via the
data-max-option
attribute. It also works for option groups.
Add an icon to an option or optgroup with the data-icon
attribute:
You can add a search input by passing data-live-search="true"
attribute:
You can also use the
title
attribute as an alternative to display when the option is
selected:
Using the data-selected-text-format
attribute on a multiple select
you can specify how the selection is displayed.
Add the disabled
attribute to the select to apply the disabled
class.
Bootstrap TouchSpin
You can limit the number of elements you are allowed to select via the
data-max-option
attribute. It also works for option groups.


Onyekuru wants Galatasaray’s return - The Nation Newspaper
Nigeria forward Henry Onyekuru has turned down overtures from Russian giants, CSKA Moscow and Locomotiv Moscow, preferring a loan return to Galatasaray of Turkey.
Onyekuru has struggled for regular playing time at French Ligue 1 club, Monaco this season following his summer arrival from Everton.
The versatile forward has made four league appearances for the principality club and is down the pecking order with the trio of Wissam Ben Yedder, Islam Slimani and Gelson Martin coach Leonardo Jardim’s preferred choices in attack.
Monaco are reportedly willing to allow the former Anderlecht striker leave on loan for a fee around 2.5m Euros.
“I will return to my old team (Galatasaray) without thinking. I don’t want to go to Russia ,” he said.


Saving much time by finding the match one using our algorithm that we designed
Palm House
Medan, Kesanaan
We are not asking for any fee from both party (landlord or even buyer)
We take care every single thing that buyer need to complete beforehand
We help buyer to find the place without hassle and helping them with paperwork
We help landlord to register their license to goverment in order want to sell


Former musician, stay-at-home dad and recent graduate of UPenn Full Stack Bootcamp. Proficient in HTML, CSS, Javascript, Git, Bootstrap, NodeJS, MySQL, Sequelize, Express, Logic Pro X, Pixelmator playing the banjo and much more. Self-learned front end web development for one year prior to bootcamp for a deeper understanding. Has bachelors in English from Temple University.


Dynamic Plugins
Starting with 2020.1 release, the ability to install, update and uninstall plugins without restarting the IDE is available in the IntelliJ Platform. During plugin development, this also allows avoiding restarts of the IDE Development Instance after every code change.
For a plugin to support this, all restrictions listed below must be met. To verify a plugin locally, run Plugin DevKit | Plugin descriptor | Plugin.xml dynamic plugin verification
inspection on all plugin descriptor files (required plugin.xml
as well as any additional files).
For plugins hosted on the JetBrains plugin repository the built-in Plugin Verifier will run these checks automatically.
No use of Components
No Components must be used; existing ones must be migrated to services, extensions or listeners.
Action Group requires ID
All <group>
s must declare a unique id
.
Use only dynamic Extensions
All extensions, whether defined in the platform itself or coming from other plugins, must be marked as dynamic (see next paragraph).
Mark Extension Points as dynamic
All extension points provided by the plugin must adhere to specific usage rules and then be declared ready for dynamic use explicitly.
Configurables depending on Extension Points
Any Configurable
which depends on dynamic extension points must implement Configurable.WithEpDependencies
.
No use of service overrides
Application, project and module services declared with overrides="true"
are not allowed.
Plugin Load/Unload Events
Register com.intellij.ide.plugins.DynamicPluginListener
listener to receive updates on plugin load/unload events.


Our Sponsors...
( PS: Click on the logos to check out their websites and to get 250 bonus gold once every 6 hours )


When Walaa posted a picture on social media that spoke out against violence in his hometown of Jairoud, Syria, it earned him three months of violent detention. He fled the country with his family through Turkey and into Greece, where they now live in a refugee camp near the Macedonian border.
Though the Internet played a role in his flight from Syria, connectivity has played a crucial role in helping him rebuild his life in Greece. While living in Greek refugee camps, Walaa used YouTube to learn English, and his language skills are now so good that hes served as a community advocate and translator. He says hes far from done: next, he hopes to learn Greek.
As refugees across Europe adapt to new contexts, access to information and education are crucial to help them develop the skills they need. Last fall we encouraged you to donate to a public matching campaign to help refugees access not only basic humanitarian aid, but also resources to create a bridge to their new communities. Since then weve helped the
International Rescue Committee
build an
online information hub
for refugees,
Mercy Corps
develop
Translation Cards
to allow field workers to communicate across languages more easily, partner with
NetHope
to install low-cost WiFi in refugee camps, and support refugee education through
Kiron
, a nonprofit providing refugee-tailored university courses available both online and offline.
In addition to Walaa, weve heard from other refugees who are finding ways to adjust thanks to Internet and education access. For example, Ahmed is an Iraqi computer scientist now living in Berlin. While waiting for his residence permit, he began teaching coding classes at refugee welcome centers as part of
Project Reconnect
, an initiative we launched with NetHope to equip NGOs with Chromebooks. Kashif, who traveled through seven countries from a small Pakistani town to Berlin, is studying online with Kiron and dreams of working as an engineer at NASA.


| Name | Vehicle | Wants to Ride | Allows Rider | Checked-In |
|---|---|---|---|---|
| Your name could be here! | ||||
| {{attendee.userId.userFirstName}} {{attendee.userId.userLastName | hideName}} | {{attendee.vehicleId.vehicleYear}} {{attendee.vehicleId.vehicleMake}} {{attendee.vehicleId.vehicleModel}}, {{attendee.vehicleId.vehicleColor}} |


EazyLend is the first and leading marketplace for borrowing and lending cars serving the Middle East . It's a simple, safe, and rewarding experience for car owners and a quick, interactive, and affordable one for car borrowers.
Subscribe for more details!


Hotel Reservation
Owner Login
Home
View Reservation
View Seating Area
Create Reservation
Edit Reservation
Customer Details
Reservation Code
Name of Customer
Date of Reservation
Time
Number of People
Assign
1
Anna
01/01/2015
06:25
4
Assign Table
2
Anna
01/01/2015
06:25
4
Assign Table
3
Anna
01/01/2015
06:25
4
Assign Table


---
layout: post
authors: ["Justin Kitzes"]
title: Feedback from UC Berkeley
date: 2013-04-16
time: "10:00:00"
tags: ["University of California - Berkeley"]
---
Last weekend we held a bootcamp at the University of California, Berkeley, that was targeted
for environmental scientists and ecologists. We had a great group of attendees (31 registered,
28 at start, and 24 at end) and instructors/helpers, and, as a major bonus, had no major technical or
logistical emergencies to deal with (but see below for some minor ones).
Before the workshop, we had participants fill out a brief pre-workshop survey that we set up
on Google Drive. The idea was to gather some initial impressions that would help us tailor
the workshop content. We learned a few particularly useful tidbits from this exercise. First, about
half the attendees had tried Python before and half had never used it. Second, nearly a third had
used some form of version control before (big surprise), and half of these had used Git. Third, the
most requested topics, by far, were related to importing and manipulating different types of data
and to integrating Python with R and/or ArcGIS.
As for feedback, we once again had the students use the Etherpad
at the end of each day. On the first day, we asked three questions: What was Good, What was Bad, and
What Lingering Questions were left. This last question turned out to be very useful, as the instructors
and helpers dutifully wrote lengthy responses to all of these questions on the morning of the
second day. You can see how this played out on the
raw text archive of the Etherpad. We then repeated the Good and Bad questions at the end of
the second day. Below is the feedback summarized across both days. We asked each attendee to try
hard to come up with a unique comment each day, and to also add +1 to other comments that they agreed
with.
The Good
- Well-structured / Good organization +12
- Very good to have helpers to avoid getting stuck +11
- Self-contained examples and exercises +10 [Ed: We provide "empty" IPython notebooks for live coding and also "complete" versions, with all
the answers, for later reference.]
- Learning about folder stuctures and good workflow habits was incredibly helpful!! +10 [Ed: we capped the workshop with a "reproducible workflow"
lesson that required students to use all the skills they had learned]
- This should be extended to a full-semester course, all 1st-year grad students should have to take it +6
- Pace +5
- Excellent overview of many topics +5
- Interactive +3
- Intro to git - i feel like i have what i need to go for it +3
- Good clear explanations +2
- Etherpad +2
- Great to see what is possible to do with the tools we've learned +2 [Ed: For some inspiration, I showed a bigger project at the end that applied the skills we
taught in a more complex setting.]
- Emphasis on the goals of producing reproducible work efficiently rather than on specific programming skills +2
- Smart, experienced, helpful teachers +2
- It filled in a lot of holes that I had from learning everything on my own +1
- Great to actually set up the SSH for github or bitbucket +1 [Ed: unfortunately, most people had some sort of problem getting this set up -
in the future, we suggest using https in a bootcamp setting.]
- Bash help was really clear
- Places to go for more info were provided
- Understanding the links between the utility of Python and my research
The Bad or Confusing
- Small desks +8 [Ed: We were in a "standard" classroom with individual chairs and attached desks.]
- The bash/unix part was slow and thin, python part was thick and (too) fast +8
- Learning everything on a linux virtual machine on a windows PC is not super efficient in the long run, since i will either be running this on a pc or will learn how to actually use linux +5 [Ed: we steered all Windows users to a Linux VM since the instructors didn't really feel capable of supporting or troubleshooting a Windows stack.]
- Feels like we've spent a lot of time but just scratched the surface of programming in python (might be helpful to also have a step 2, i.e. a next level course some time soon) +3
- Too fast overall +3
- Maybe separate into two weekends or three days? A little bit too intense +3
- Maybe it could be useful to have something read before the workshop so we could all be in a similar level +2
- My brain hurts (eyes too) +1
- The room is kind of cold? Need more coffee? +1
- Hard to process everything at once +1
- Unsure how much I can alter my workflow now... +1
- If you have any issues along the way it is hard to catch back up +1
- By the time we got to testing i was brain dead....would be nice to do that earlier +1
- Not bad, but would be helpful -- a brief tutorial on piping I/O between programs +1
- Some terminology is used that we might not be clear on. not always clear which terms are key to understand and which aren't +1
- Should set up guest additions and shared folders for virtual machines before hand on windows
- More overview of other langs and why/when to use python
- Need more time for exercises
- A good overview of file manipulation operations in bash; covering examples of common workflows would be helpful...
- Too much time spent on troubleshooting installations; perhaps provide pipelines for each person to test their installations prior to arrival?
- The range of abilities is probably frustrating for people on both ends of the spectrum, too slow or too quick
Thanks to instructors Karthik Ram and Geoff Oxberry and helpers Matthew Brett and Jessica Hamrick.


Hey, my name is Carlo a self-taught full-stack developer and designer. I have a Bachelor's degree in Aviation Electronics Technology but I have only truly felt at home as a Web developer. Where I can be creative and figure out my solutions to complex problems.
Anime Quiz App
ReactJS, Material-UI, Node.JS, Express, MongoDB
Developed a full stack application that performs CRUD operations with React for front end, Node JS and Express for the backend to connect and fetch Data on Database
Built the User Interface using Material UI for responsiveness of web pages for both mobile and desktop browsers
Created a Rest API Database model schema using mongoose for storing questions, image URLs and answers
Implemented the Authentication and Authorization for the Rest API that validates if the JSON Web Token of the Logged in User is allowed to perform Create, Update and Delete the questions in Database
CodeOne Piece Manga Reader
ReactJS, Material-UI, Node.JS, Express
Designed the front end using Material-UI for responsiveness of web pages for both mobile and desktop browsers
Built a Back end with Node JS and Express to fetch data from One Piece API using node fetch library
Imported the Axios library to get the data of the API from the back end
Added a feature of previous and next navigation button on Cover page that increases or decreases the page number and displays 10 Covers of Manga Chapters depends on page number
CodeStudent Record System
JavaScript, HTML5, CSS3
Developed a prototype of Student Record System with plain JavaScript and created a Class Constructor Method to make a Student object using User’s given information on the inputs and saved the data to Brower’s LocalStorage
Designed a HTML DOM Table Object to display all the student’s records from the data
Implemented the CRUD operations on student records that was stored on the LocalStorage
Added the Search functionality to filter the student’s list depending on the search query
Code


Version: 1.0.1
PDTides is a simple application that fetch data for tides in Port Dickson, Negeri Sembilan.
The data is taken from http://tides.mobilegeographics.com.
If you have any questions, suggestions, or recommendations, please do not hesitate to contact<EMAIL_ADDRESS>Powered by PortDicksonHub.com


Description pending ...
The module will appear as "Solar System Evolution Sim" in the object tree, under Adler.


Limit values of implementation-specific int type.
const ( MaxInt = int(^uint(0) >> 1) MinInt = -MaxInt - 1 )
A Sparse is a set of int values. Sparse operations (even queries) are not concurrency-safe.
The zero value for Sparse is a valid empty set.
Sparse sets must be copied using the Copy method, not by assigning a Sparse value.
type Sparse struct {
// contains filtered or unexported fields
}
func (s *Sparse) AppendTo(slice []int) []int
AppendTo returns the result of appending the elements of s to slice in order.
func (s *Sparse) BitString() string
BitString returns the set as a string of 1s and 0s denoting the sum of the i'th powers of 2, for each i in s. A radix point, always preceded by a digit, appears if the sum is non-integral.
Examples:
{}.BitString() = "0" {4,5}.BitString() = "110000" {-3}.BitString() = "0.001" {-3,0,4,5}.BitString() = "110001.001"
func (s *Sparse) Clear()
Clear removes all elements from the set s.
func (s *Sparse) Copy(x *Sparse)
Copy sets s to the value of x.
func (s *Sparse) Difference(x, y *Sparse)
Difference sets s to the difference x ∖ y.
func (s *Sparse) DifferenceWith(x *Sparse)
DifferenceWith sets s to the difference s ∖ x.
func (s *Sparse) Equals(t *Sparse) bool
Equals reports whether the sets s and t have the same elements.
func (s *Sparse) GoString() string
GoString returns a string showing the internal representation of the set s.
func (s *Sparse) Has(x int) bool
Has reports whether x is an element of the set s.
func (s *Sparse) Insert(x int) bool
Insert adds x to the set s, and reports whether the set grew.
func (s *Sparse) Intersection(x, y *Sparse)
Intersection sets s to the intersection x ∩ y.
func (s *Sparse) IntersectionWith(x *Sparse)
IntersectionWith sets s to the intersection s ∩ x.
func (s *Sparse) Intersects(x *Sparse) bool
Intersects reports whether s ∩ x ≠ ∅.
func (s *Sparse) IsEmpty() bool
IsEmpty reports whether the set s is empty.
func (s *Sparse) Len() int
Len returns the number of elements in the set s.
func (s *Sparse) LowerBound(x int) int
LowerBound returns the smallest element >= x, or MaxInt if there is no such element.
func (s *Sparse) Max() int
Max returns the maximum element of the set s, or MinInt if s is empty.
func (s *Sparse) Min() int
Min returns the minimum element of the set s, or MaxInt if s is empty.
func (s *Sparse) Remove(x int) bool
Remove removes x from the set s, and reports whether the set shrank.
func (s *Sparse) String() string
String returns a human-readable description of the set s.
func (s *Sparse) SubsetOf(x *Sparse) bool
SubsetOf reports whether s ∖ x = ∅.
func (s *Sparse) SymmetricDifference(x, y *Sparse)
SymmetricDifference sets s to the symmetric difference x ∆ y.
func (s *Sparse) SymmetricDifferenceWith(x *Sparse)
SymmetricDifferenceWith sets s to the symmetric difference s ∆ x.
func (s *Sparse) TakeMin(p *int) bool
If set s is non-empty, TakeMin sets *p to the minimum element of the set s, removes that element from the set and returns true. Otherwise, it returns false and *p is undefined.
This method may be used for iteration over a worklist like so:
var x int for worklist.TakeMin(&x) { use(x) }
func (s *Sparse) Union(x, y *Sparse)
Union sets s to the union x ∪ y.
func (s *Sparse) UnionWith(x *Sparse) bool
UnionWith sets s to the union s ∪ x, and reports whether s grew.


Compose file versions and upgrading
Estimated reading time: 14 minutesThe Compose file is a YAML file defining services, networks, and volumes for a Docker application.
The Compose file formats are now described in these references, specific to each version.
| Reference file | What changed in this version |
|---|---|
| Version 3 (most current, and recommended) | Version 3 updates |
| Version 2 | Version 2 updates |
| Version 1 | Version 1 updates |
The topics below explain the differences among the versions, Docker Engine compatibility, and how to upgrade.
Compatibility matrix
There are several versions of the Compose file format – 1, 2, 2.x, and 3.x
This table shows which Compose file versions support specific Docker releases.
| Compose file format | Docker Engine release |
|---|---|
| 3.7 | 18.06.0+ |
| 3.6 | 18.02.0+ |
| 3.5 | 17.12.0+ |
| 3.4 | 17.09.0+ |
| 3.3 | 17.06.0+ |
| 3.2 | 17.04.0+ |
| 3.1 | 1.13.1+ |
| 3.0 | 1.13.0+ |
| 2.4 | 17.12.0+ |
| 2.3 | 17.06.0+ |
| 2.2 | 1.13.0+ |
| 2.1 | 1.12.0+ |
| 2.0 | 1.10.0+ |
| 1.0 | 1.9.1.+ |
In addition to Compose file format versions shown in the table, the Compose itself is on a release schedule, as shown in Compose releases, but file format versions do not necessarily increment with each release. For example, Compose file format 3.0 was first introduced in Compose release 1.10.0, and versioned gradually in subsequent releases.
Looking for more detail on Docker and Compose compatibility?
We recommend keeping up-to-date with newer releases as much as possible. However, if you are using an older version of Docker and want to determine which Compose release is compatible, refer to the Compose release notes. Each set of release notes gives details on which versions of Docker Engine are supported, along with compatible Compose file format versions. (See also, the discussion in issue #3404.)
For details on versions and how to upgrade, see Versioning and Upgrading.
Versioning
There are currently three versions of the Compose file format:
-
Version 1, the legacy format. This is specified by omitting a
version
key at the root of the YAML. -
Version 2.x. This is specified with a
version: '2'
orversion: '2.1'
, etc., entry at the root of the YAML. -
Version 3.x, the latest and recommended version, designed to be cross-compatible between Compose and the Docker Engine’s swarm mode. This is specified with a
version: '3'
orversion: '3.1'
, etc., entry at the root of the YAML.
v2 and v3 Declaration
Note: When specifying the Compose file version to use, make sure to specify both the major and minor numbers. If no minor version is given,
0
is used by default and not the latest minor version.
The Compatibility Matrix shows Compose file versions mapped to Docker Engine releases.
To move your project to a later version, see the Upgrading section.
Note: If you’re using multiple Compose files or extending services, each file must be of the same version - you cannot, for example, mix version 1 and 2 in a single project.
Several things differ depending on which version you use:
- The structure and permitted configuration keys
- The minimum Docker Engine version you must be running
- Compose’s behaviour with regards to networking
These differences are explained below.
Version 1
Compose files that do not declare a version are considered “version 1”. In those files, all the services are declared at the root of the document.
Version 1 is supported by Compose up to 1.6.x. It will be deprecated in a future Compose release.
Version 1 files cannot declare named volumes, networks or build arguments.
Compose does not take advantage of networking when you
use version 1: every container is placed on the default bridge
network and is
reachable from every other container at its IP address. You need to use
links to enable discovery between containers.
Example:
web:
build: .
ports:
- "5000:5000"
volumes:
- .:/code
links:
- redis
redis:
image: redis
Version 2
Compose files using the version 2 syntax must indicate the version number at
the root of the document. All services
must be declared under the services
key.
Version 2 files are supported by Compose 1.6.0+ and require a Docker Engine of version 1.10.0+.
Named volumes can be declared under the
volumes
key, and networks can be declared
under the networks
key.
By default, every container joins an application-wide default network, and is discoverable at a hostname that’s the same as the service name. This means links are largely unnecessary. For more details, see Networking in Compose.
Note: When specifying the Compose file version to use, make sure to specify both the major and minor numbers. If no minor version is given,
0
is used by default and not the latest minor version. As a result, features added in later versions will not be supported. For example:version: "2"
is equivalent to:
version: "2.0"
Simple example:
version: "2.4"
services:
web:
build: .
ports:
- "5000:5000"
volumes:
- .:/code
redis:
image: redis
A more extended example, defining volumes and networks:
version: "2.4"
services:
web:
build: .
ports:
- "5000:5000"
volumes:
- .:/code
networks:
- front-tier
- back-tier
redis:
image: redis
volumes:
- redis-data:/var/lib/redis
networks:
- back-tier
volumes:
redis-data:
driver: local
networks:
front-tier:
driver: bridge
back-tier:
driver: bridge
Several other options were added to support networking, such as:
-
The
depends_on
option can be used in place of links to indicate dependencies between services and startup order.version: "2.4" services: web: build: . depends_on: - db - redis redis: image: redis db: image: postgres
Variable substitution also was added in Version 2.
Version 2.1
An upgrade of version 2 that introduces new parameters only available with Docker Engine version 1.12.0+. Version 2.1 files are supported by Compose 1.9.0+.
Introduces the following additional parameters:
link_local_ips
isolation
in build configurations and service definitionslabels
for volumes and networksname
for volumesuserns_mode
healthcheck
sysctls
pids_limit
oom_kill_disable
cpu_period
Version 2.2
An upgrade of version 2.1 that introduces new parameters only available with Docker Engine version 1.13.0+. Version 2.2 files are supported by Compose 1.13.0+. This version also allows you to specify default scale numbers inside the service’s configuration.
Introduces the following additional parameters:
Version 2.3
An upgrade of version 2.2 that introduces new parameters only available with Docker Engine version 17.06.0+. Version 2.3 files are supported by Compose 1.16.0+.
Introduces the following additional parameters:
target
,extra_hosts
andshm_size
for build configurationsstart_period
forhealthchecks
- “Long syntax” for volumes
runtime
for service definitionsdevice_cgroup_rules
Version 2.4
An upgrade of version 2.3 that introduces new parameters only available with Docker Engine version 17.12.0+. Version 2.4 files are supported by Compose 1.21.0+.
Introduces the following additional parameters:
platform
for service definitions- Support for extension fields at the root of service, network, and volume definitions
Version 3
Designed to be cross-compatible between Compose and the Docker Engine’s swarm mode, version 3 removes several options and adds several more.
-
Removed:
volume_driver
,volumes_from
,cpu_shares
,cpu_quota
,cpuset
,mem_limit
,memswap_limit
,extends
,group_add
. See the upgrading guide for how to migrate away from these. (For more information onextends
, see Extending services.) -
Added: deploy
Note: When specifying the Compose file version to use, make sure to specify both the major and minor numbers. If no minor version is given,
0
is used by default and not the latest minor version. As a result, features added in later versions will not be supported. For example:version: "3"
is equivalent to:
version: "3.0"
Version 3.3
An upgrade of version 3 that introduces new parameters only available with Docker Engine version 17.06.0+, and higher.
Introduces the following additional parameters:
Version 3.4
An upgrade of version 3 that introduces new parameters. It is only available with Docker Engine version 17.09.0 and higher.
Introduces the following additional parameters:
target
andnetwork
in build configurationsstart_period
forhealthchecks
order
for update configurationsname
for volumes
Version 3.5
An upgrade of version 3 that introduces new parameters. It is only available with Docker Engine version 17.12.0 and higher.
Introduces the following additional parameters:
isolation
in service definitionsname
for networks, secrets and configsshm_size
in build configurations
Version 3.6
An upgrade of version 3 that introduces new parameters. It is only available with Docker Engine version 18.02.0 and higher.
Introduces the following additional parameters:
tmpfs
size fortmpfs
-type mounts
Version 3.7
An upgrade of version 3 that introduces new parameters. It is only available with Docker Engine version 18.06.0 and higher.
Introduces the following additional parameters:
init
in service definitionsrollback_config
in deploy configurations- Support for extension fields at the root of service, network, volume, secret and config definitions
Upgrading
Version 2.x to 3.x
Between versions 2.x and 3.x, the structure of the Compose file is the same, but several options have been removed:
-
volume_driver
: Instead of setting the volume driver on the service, define a volume using the top-levelvolumes
option and specify the driver there.version: "3.7" services: db: image: postgres volumes: - data:/var/lib/postgresql/data volumes: data: driver: mydriver
-
volumes_from
: To share a volume between services, define it using the top-levelvolumes
option and reference it from each service that shares it using the service-levelvolumes
option. -
cpu_shares
,cpu_quota
,cpuset
,mem_limit
,memswap_limit
: These have been replaced by the resources key underdeploy
.deploy
configuration only takes effect when usingdocker stack deploy
, and is ignored bydocker-compose
. extends
: This option has been removed forversion: "3.x"
Compose files. (For more information, see Extending services.)group_add
: This option has been removed forversion: "3.x"
Compose files.pids_limit
: This option has not been introduced inversion: "3.x"
Compose files.link_local_ips
innetworks
: This option has not been introduced inversion: "3.x"
Compose files.
Version 1 to 2.x
In the majority of cases, moving from version 1 to 2 is a very simple process:
- Indent the whole file by one level and put a
services:
key at the top. - Add a
version: '2'
line at the top of the file.
It’s more complicated if you’re using particular configuration features:
-
dockerfile
: This now lives under thebuild
key:build: context: . dockerfile: Dockerfile-alternate
-
log_driver
,log_opt
: These now live under thelogging
key:logging: driver: syslog options: syslog-address: "tcp://<IP_ADDRESS>:123"
-
links
with environment variables: As documented in the environment variables reference, environment variables created by links have been deprecated for some time. In the new Docker network system, they have been removed. You should either connect directly to the appropriate hostname or set the relevant environment variable yourself, using the link hostname:web: links: - db environment: - DB_PORT=tcp://db:5432
-
external_links
: Compose uses Docker networks when running version 2 projects, so links behave slightly differently. In particular, two containers must be connected to at least one network in common in order to communicate, even if explicitly linked together.Either connect the external container to your app’s default network, or connect both the external container and your service’s containers to an external network.
-
net
: This is now replaced by network_mode:net: host -> network_mode: host net: bridge -> network_mode: bridge net: none -> network_mode: none
If you’re using
net: "container:[service name]"
, you must now usenetwork_mode: "service:[service name]"
instead.net: "container:web" -> network_mode: "service:web"
If you’re using
net: "container:[container name/id]"
, the value does not need to change.net: "container:cont-name" -> network_mode: "container:cont-name" net: "container:abc12345" -> network_mode: "container:abc12345"
-
volumes
with named volumes: these must now be explicitly declared in a top-levelvolumes
section of your Compose file. If a service mounts a named volume calleddata
, you must declare adata
volume in your top-levelvolumes
section. The whole file might look like this:version: "2.4" services: db: image: postgres volumes: - data:/var/lib/postgresql/data volumes: data: {}
By default, Compose creates a volume whose name is prefixed with your project name. If you want it to just be called
data
, declare it as external:volumes: data: external: true
Compatibility mode
docker-compose
1.20.0 introduces a new --compatibility
flag designed to
help developers transition to version 3 more easily. When enabled,
docker-compose
reads the deploy
section of each service’s definition and
attempts to translate it into the equivalent version 2 parameter. Currently,
the following deploy keys are translated:
- resources limits and memory reservations
- replicas
- restart_policy
condition
andmax_attempts
All other keys are ignored and produce a warning if present. You can review
the configuration that will be used to deploy by using the --compatibility
flag with the config
command.
Do not use this in production!
We recommend against using
--compatibility
mode in production. Because the resulting configuration is only an approximate using non-Swarm mode properties, it may produce unexpected results.


Visualization Options
-x, –width=N
Set the width in pixels of the output image.
-y, –height=N
Set the height in pixels of the output image.
-P, –path-height=N
The height in pixels for a path.
-X, –path-x-padding=N
The padding in pixels on the x-axis for a path.
-R, –pack-paths
Pack all paths rather than displaying a single path per row.
-L, –link-path-pieces=FLOAT
Show thin links of this relative width to connect path pieces.
-A, –alignment-prefix=STRING
Apply alignment related visual motifs to paths which have this name
prefix. It affects the [-S, –show-strand] and [-d,
–change-darkness] options.
-S, –show-strand
Use red and blue coloring to display forward and reverse alignments.
This parameter can be set in combination with [-A,
–alignment-prefix=STRING].
-z, –color-by-mean-inversion-rate
Change the color respect to the node strandness (black for forward,
red for reverse); in binned mode (-b, –binned-mode), change the
color respect to the mean inversion rate of the path for each bin,
from black (no inversions) to red (bin mean inversion rate equals to
1).
-s, –color-by-prefix
Colors paths by their names looking at the prefix before the given
character C.
Path names visualization Options
-H, –hide-path-names
Hide the path names on the left of the generated image.
-C, –color-path-names-background
Color path names background with the same color as paths
-c, –max-num-of-characters
Maximum number of characters to display for each path name (max 128
characters). The default value is the length of the longest path
name (up to 32 characters).
Binned Mode Options
-b, –binned-mode
The variation graph is binned before its visualization. Each pixel in
the output image will correspond to a bin. For more information about
the binning process, please refer to
odgi
bin.
-w, –bin-width=N
The bin width specifies the size of each bin in the binned mode. If it
is not specified, the bin width is calculated from the width in pixels
of the output image.
-g, –no-gap-links
We divide links into 2 classes:
the links which help to follow complex variations. They need to be
drawn, else one could not follow the sequence of a path.
the links helping to follow simple variations. These links are called
gap-links. Such links solely connecting a path from left to right
may not be relevant to understand a path’s traversal through the
bins. Therefore, when this option is set, the gap-links are not drawn
in binned mode.
-m, –color-by-mean-coverage
Change the color respect to the mean coverage of the path for each
bin, from black (no coverage) to blue (max bin mean coverage in the
entire graph).
Gradient Mode (also known as Position Mode) Options
-d, –change-darkness
Change the color darkness based on nucleotide position in the path.
When it is used in binned mode, the mean inversion rate of the bin
node is considered to set the color gradient starting position: when
this rate is greater than 0.5, the bin is considered inverted, and the
color gradient starts from the right-end of the bin. This parameter
can be set in combination with [-A,
–alignment-prefix=STRING].
-l, –longest-path
Use the longest path length to change the color darkness.
-u, –white-to-black
Change the color darkness from white (for the first nucleotide
position) to black (for the last nucleotide position).


Kuo Zui Shuan is currently a student majoring in English teaching of the Department of Foreign Languages, National Chiayi University, Taiwan. She is interested in English teaching, especially adapting the CLIL method.


Toggle navigation
OneAdvanced
Home
Show Employees
Create Employee
Edit Employees
Delete Employee
Sign In
Login here


--- layout: default title: Home ---
The world is a very puzzling place. If you're not willing to be puzzled, you just become a replica of someone else's mind.
Noam Chomsky
Hi, my name's Kyara. I like technology, art, and being puzzled. Welcome to my corner of the Internet!
I enjoy keeping myself busy, which is a good thing because I work in healthcare and information technology while balancing my studies. When I'm not working, I volunteer through Rotary International and visit new places in Maine. I'm looking forward to continuing my education at the University of Maine's Computer Science program.
For more about who I am and what this site is, visit my About page.


Control Panel
Super Search contains some tools and controls in the ExpressionEngine control panel:
Top Search Keywords
This page displays a list of the Top Search Keywords as well as some information about them.
Search Log
This page displays a list of all recent searches and details about them. The Log Site Searches? preference in the Super Search control panel must be set to Yes in order for this page to show results.
Search Curation
Super Search includes a Search Curation feature, which is designed to allow manual selection of entry results for keyword searches. This would typically be used as supplemental search results to normal search results, similar to how Google displays sponsored results at the top or side of search results pages. Follow the interface steps to use this feature.
Build Search Lexicon
Super Search contains a utility called Build Search Lexicon, which is used to build a combined dataset of all unique terms across your sites, which enables fuzzy searches, search corrections and better search term handling. The first run may take some time, but only needs to run once.
Preferences
This page contains a variety of settings you can adjust to enable/disable search behaviors and features, including cache preferences.
Demo Templates
If you wish to load the demo templates for Super Search, go to this tab. Then just create a prefix name for the sample data such as test_ or super_search_, and click the Install Demo Templates button.


3 Bioconductor Data Structures
Bioconductor promotes the statistical analysis and comprehension of current and emerging high-throughput biological assays. Bioconductor is based on packages written primarily in the R programming language. Bioconductor is committed to open source, collaborative, distributed software development and literate, reproducible research. Most Bioconductor components are distributed as R packages. The functional scope of Bioconductor packages includes the analysis of DNA microarray, sequence, flow, SNP, and other data.
Bioconductor provides several data infrastructures for efficiently managing omic data. See this paper for a global overview. Here we provide a quick introduction for the most commonly used ones. We also recommend to learn how to deal with GenomicRanges which helps to efficiently manage genomic data information.
3.1 SNP Array Data
SNP array data are normally stored in PLINK format (or VCF for NGS data). PLINK data are normally stored in three files .ped, .bim, .fam. The advantage is that SNP data are stored in binary format in the BED file (Homozygous normal 01, Heterozygous 02, Homozygous variant 03, missing 00).
- FAM file: one row per individual - identification information: Family ID, Individual ID Paternal ID, Maternal ID, Sex (1=male; 2=female; other=unknown), Phenotype.
- BIM file: one row per SNP (rs id, chromosome, position, allele 1, allele 2).
- BED file: one row per individual. Genotypes in columns.
Data are easily loaded into R by using read.plink
function
require(snpStats)
snps <- read.plink("data/obesity") # there are three files obesity.fam, obesity.bim, obesity.bed
names(snps)
[1] "genotypes" "fam" "map"
Genotypes is a snpMatrix
object
A SnpMatrix with 2312 rows and 100000 columns
Row names: 100 ... 998
Col names: MitoC3993T ... rs28600179
Annotation is a data.frame
object
chromosome snp.name cM position allele.1 allele.2
MitoC3993T NA MitoC3993T NA 3993 T C
MitoG4821A NA MitoG4821A NA 4821 A G
MitoG6027A NA MitoG6027A NA 6027 A G
MitoT6153C NA MitoT6153C NA 6153 C T
MitoC7275T NA MitoC7275T NA 7275 T C
MitoT9699C NA MitoT9699C NA 9699 C T
3.2 Expression Sets
The ExpressionSet is a fundamental data container in Bioconductor
Description
Biobase
is part of the Bioconductor project and contains standardized data structures to represent genomic data.The
ExpressionSet
class is designed to combine several different sources of information into a single convenient structure.An
ExpressionSet
can be manipulated (e.g., subsetted, copied) conveniently, and is the input or output from many Bioconductor functions.The data in an
ExpressionSet
consists of expression data from microarray experiments, `meta-data’ describing samples in the experiment, annotations and meta-data about the features on the chip and information related to the protocol used for processing each samplePrint
ExpressionSet (storageMode: lockedEnvironment)
assayData: 52580 features, 69 samples
element names: exprs
protocolData: none
phenoData
sampleNames: NA18486 NA18498 ... NA19257 (69 total)
varLabels: num.tech.reps population study gender
varMetadata: labelDescription
featureData
featureNames: ENSG00000000003 ENSG00000000005 ...  NA19239 (29 total)
varLabels: num.tech.reps population study gender
varMetadata: labelDescription
featureData
featureNames: ENSG00000000003 ENSG00000000005 ... LRG_99 (52580 total)
fvarLabels: gene
fvarMetadata: labelDescription
experimentData: use 'experimentData(object)'
Annotation:
Finally, the fData
function gets the probes’ annotation in a data.frame
. Let us first illustrate how to provide an annotation to an ExpressionSet
object
require(Homo.sapiens)
geneSymbols <- rownames(genes)
annot <- select(Homo.sapiens, geneSymbols,
columns=c("TXCHROM", "SYMBOL"), keytype="ENSEMBL")
annotation(pickrell.eset) <- "Homo.sapiens"
fData(pickrell.eset) <- annot
pickrell.eset
ExpressionSet (storageMode: lockedEnvironment)
assayData: 52580 features, 69 samples
element names: exprs
protocolData: none
phenoData
sampleNames: NA18486 NA18498 ... NA19257 (69 total)
varLabels: num.tech.reps population study gender
varMetadata: labelDescription
featureData
featureNames: 1 2 ... 59351 (59351 total)
fvarLabels: ENSEMBL SYMBOL TXCHROM
fvarMetadata: labelDescription
experimentData: use 'experimentData(object)'
Annotation: Homo.sapiens
ENSEMBL SYMBOL TXCHROM
1 ENSG00000000003 TSPAN6 chrX
2 ENSG00000000005 TNMD chrX
3 ENSG00000000419 DPM1 chr20
4 ENSG00000000457 SCYL3 chr1
5 ENSG00000000460 C1orf112 chr1
6 ENSG00000000938 FGR chr1
3.3 Genomic Ranges
The GenomicRanges package serves as the foundation for representing genomic locations within the Bioconductor project.
GRanges()
: genomic coordinates to represent annotations (exons, genes, regulatory marks, …) and data (called peaks, variants, aligned reads)GRangesList()
: genomic coordinates grouped into list elements (e.g., paired-end reads; exons grouped by transcript)
Operations
- intra-range: act on each range independently
- e.g.,
shift()
- e.g.,
- inter-range: act on all ranges in a
GRanges
object orGRangesList
element - e.g.,reduce()
;disjoin()
- between-range: act on two separate
GRanges
orGRangesList
objects - e.g.,findOverlaps()
,nearest()
GRanges object with 3 ranges and 0 metadata columns:
seqnames ranges strand
<Rle> <IRanges> <Rle>
[1] chr1 10-14 +
[2] chr1 20-24 +
[3] chr1 22-26 +
-------
seqinfo: 1 sequence from an unspecified genome; no seqlengths
GRanges object with 3 ranges and 0 metadata columns:
seqnames ranges strand
<Rle> <IRanges> <Rle>
[1] chr1 13-17 +
[2] chr1 23-27 +
[3] chr1 25-29 +
-------
seqinfo: 1 sequence from an unspecified genome; no seqlengths
GRanges object with 1 range and 0 metadata columns:
seqnames ranges strand
<Rle> <IRanges> <Rle>
[1] chr1 10-26 +
-------
seqinfo: 1 sequence from an unspecified genome; no seqlengths
# two Granges: knowing the intervals that overlap with a targeted region
snps <- GRanges("chr1", IRanges(c(11, 17), width=1))
snps
GRanges object with 2 ranges and 0 metadata columns:
seqnames ranges strand
<Rle> <IRanges> <Rle>
[1] chr1 11 *
[2] chr1 17 *
-------
seqinfo: 1 sequence from an unspecified genome; no seqlengths
Hits object with 1 hit and 0 metadata columns:
queryHits subjectHits
<integer> <integer>
[1] 1 1
-------
queryLength: 2 / subjectLength: 3
GRanges object with 1 range and 0 metadata columns:
seqnames ranges strand
<Rle> <IRanges> <Rle>
[1] chr1 10-14 +
-------
seqinfo: 1 sequence from an unspecified genome; no seqlengths
RleList of length 1
$chr1
integer-Rle of length 26 with 6 runs
Lengths: 9 5 5 2 3 2
Values : 0 1 0 1 2 1
[1] 1 0 0
This table shows the common operations of GenomicRanges
3.4 Summarized Experiments
The SummarizedExperiment container encapsulates one or more assays, each represented by a matrix-like object of numeric or other mode. The rows typically represent genomic ranges of interest and the columns represent samples.
Comprehensive data structure that can be used to store expression and methylation data from microarrays or read counts from RNA-seq experiments, among others.
Can contain slots for one or more omic datasets, feature annotation (e.g. genes, transcripts, SNPs, CpGs), individual phenotypes and experimental details, such as laboratory and experimental protocols.
As in an
ExpressionSet
aSummarizedExperiment
, the rows of omic data are features and columns are subjects.Coordinate feature x sample ‘assays’ with row (feature) and column (sample) descriptions.
‘assays’ (similar to ‘exprs’ in
ExpressionSet
objects) can be any matrix-like object, including very large on-disk representations such as HDF5Array‘assays’ are annotated using
GenomicRanges
It is being deprecated
3.5 Ranged Summarized Experiments
SummarizedExperiment
is extended to RangedSummarizedExperiment
, a child class that contains the annotation data of the features in a GenomicRanges
object. An example dataset, stored as a RangedSummarizedExperiment
is available in the airway
package. This data represents an RNA sequencing experiment.
class: RangedSummarizedExperiment
dim: 64102 8
metadata(1): ''
assays(1): counts
rownames(64102): ENSG00000000003 ENSG00000000005 ... LRG_98 LRG_99
rowData names(0):
colnames(8): SRR1039508 SRR1039509 ... SRR1039520 SRR1039521
colData names(9): SampleName cell ... Sample BioSample
- Some aspects of the object are very similar to
ExpressionSet
, although with slightly different names and types.colData
contains phenotype (sample) information, likepData
forExpressionSet
. It returns aDataFrame
instead of a data.frame:
DataFrame with 8 rows and 9 columns
SampleName cell dex albut Run avgLength Experiment Sample BioSample
<factor> <factor> <factor> <factor> <factor> <integer> <factor> <factor> <factor>
SRR1039508 GSM1275862 N61311 untrt untrt SRR1039508 126 SRX384345 SRS508568 SAMN02422669
SRR1039509 GSM1275863 N61311 trt untrt SRR1039509 126 SRX384346 SRS508567 SAMN02422675
SRR1039512 GSM1275866 N052611 untrt untrt SRR1039512 126 SRX384349 SRS508571 SAMN02422678
SRR1039513 GSM1275867 N052611 trt untrt SRR1039513 87 SRX384350 SRS508572 SAMN02422670
SRR1039516 GSM1275870 N080611 untrt untrt SRR1039516 120 SRX384353 SRS508575 SAMN02422682
SRR1039517 GSM1275871 N080611 trt untrt SRR1039517 126 SRX384354 SRS508576 SAMN02422673
SRR1039520 GSM1275874 N061011 untrt untrt SRR1039520 101 SRX384357 SRS508579 SAMN02422683
SRR1039521 GSM1275875 N061011 trt untrt SRR1039521 98 SRX384358 SRS508580 SAMN02422677
- You can still use
$
to get a particular column:
[1] N61311 N61311 N052611 N052611 N080611 N080611 N061011 N061011
Levels: N052611 N061011 N080611 N61311
- The measurement data are accessed by
assay
andassays
. ASummarizedExperiment
can contain multiple measurement matrices (all of the same dimension). You get all of them by assays and you select a particular one byassay(OBJECT, NAME)
where you can see the names when you print the object or by usingassayNames
. In this case there is a single matrix called counts:
[1] "counts"
List of length 1
names(1): counts
SRR1039508 SRR1039509 SRR1039512 SRR1039513 SRR1039516 SRR1039517 SRR1039520 SRR1039521
ENSG00000000003 679 448<PHONE_NUMBER> 1047 770 572
ENSG00000000005 0 0 0 0 0 0 0 0
ENSG00000000419 467 515 621 365 587 799 417 508
ENSG00000000457 260 211 263 164 245 331 233 229
ENSG00000000460 60 55 40 35 78 63 76 60
ENSG00000000938 0 0 2 0 1 0 0 0
- Annotation is a
GenomicRanges
object
GRangesList object of length 64102:
$ENSG00000000003
GRanges object with 17 ranges and 2 metadata columns:
seqnames ranges strand | exon_id exon_name
<Rle> <IRanges> <Rle> | <integer> <character>
[1] X 99883667-99884983 - | 667145 ENSE00001459322
[2] X 99885756-99885863 - | 667146 ENSE00000868868
[3] X 99887482-99887565 - | 667147 ENSE00000401072
[4] X 99887538-99887565 - | 667148 ENSE00001849132
[5] X 99888402-99888536 - | 667149 ENSE00003554016
... ... ... ... . ... ...
[13] X 99890555-99890743 - | 667156 ENSE00003512331
[14] X 99891188-99891686 - | 667158 ENSE00001886883
[15] X 99891605-99891803 - | 667159 ENSE00001855382
[16] X 99891790-99892101 - | 667160 ENSE00001863395
[17] X 99894942-99894988 - | 667161 ENSE00001828996
-------
seqinfo: 722 sequences (1 circular) from an unspecified genome
...
<64101 more elements>
- Subset for only rows (e.g. features) which are in the interval 1 to 1Mb of chromosome 1
class: RangedSummarizedExperiment
dim: 79 8
metadata(1): ''
assays(1): counts
rownames(79): ENSG00000177757 ENSG00000185097 ... ENSG00000272512 ENSG00000273443
rowData names(0):
colnames(8): SRR1039508 SRR1039509 ... SRR1039520 SRR1039521
colData names(9): SampleName cell ... Sample BioSample
3.6 Multi Data Set
MultiDataSet is designed for integrating multi omic datasets.
Designed to encapsulate different types of datasets (including all classes in Bioconductor)
It properly deals with non-complete cases situations
Subsetting is easily performed in both: samples and features (using GenomicRanges)
It allows to: – perform integration analysis with third party packages; – create new methods and functions for omic data integration; – encapsule new unimplemented data from any biological experiment
MultiAssayExperiment is another infrastructure container (created by BioC developers) that can be used to manage multi-omic data