SIGACTION
Section: Linux Programmer's Manual (2)
Updated: 2014-04-27
Index
Return to Main Contents
NAME
sigaction - examine and change a signal action
SYNOPSIS
#include <signal.h>
int sigaction(int signum, const struct sigaction *act,
struct sigaction *oldact);
Feature Test Macro Requirements for glibc (see
feature_test_macros(7)):
sigaction():
_POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE
siginfo_t:
_POSIX_C_SOURCE >= 199309L
DESCRIPTION
The
sigaction()
system call is used to change the action taken by a process on
receipt of a specific signal.
(See
signal(7)
for an overview of signals.)
signum
specifies the signal and can be any valid signal except
SIGKILL
and
SIGSTOP.
If
act
is non-NULL, the new action for signal
signum
is installed from
act.
If
oldact
is non-NULL, the previous action is saved in
oldact.
The
sigaction
structure is defined as something like:
struct sigaction {
void (*sa_handler)(int);
void (*sa_sigaction)(int, siginfo_t *, void *);
sigset_t sa_mask;
int sa_flags;
void (*sa_restorer)(void);
};
On some architectures a union is involved: do not assign to both
sa_handler
and
sa_sigaction.
The
sa_restorer
element is obsolete and should not be used.
POSIX does not specify a
sa_restorer
element.
sa_handler
specifies the action to be associated with
signum
and may be
SIG_DFL
for the default action,
SIG_IGN
to ignore this signal, or a pointer to a signal handling function.
This function receives the signal number as its only argument.
If
SA_SIGINFO
is specified in
sa_flags,
then
sa_sigaction
(instead of
sa_handler)
specifies the signal-handling function for
signum.
This function receives the signal number as its first argument, a
pointer to a
siginfo_t
as its second argument and a pointer to a
ucontext_t
(cast to void *) as its third argument.
(Commonly, the handler function doesn't make any use of the third argument.
See
getcontext(3)
for further information about
ucontext_t.)
sa_mask
specifies a mask of signals which should be blocked
(i.e., added to the signal mask of the thread in which
the signal handler is invoked)
during execution of the signal handler.
In addition, the signal which triggered the handler
will be blocked, unless the
SA_NODEFER
flag is used.
sa_flags
specifies a set of flags which modify the behavior of the signal.
It is formed by the bitwise OR of zero or more of the following:
-
- SA_NOCLDSTOP
-
If
signum
is
SIGCHLD,
do not receive notification when child processes stop (i.e., when they
receive one of
SIGSTOP, SIGTSTP, SIGTTIN,
or
SIGTTOU)
or resume (i.e., they receive
SIGCONT)
(see
wait(2)).
This flag is meaningful only when establishing a handler for
SIGCHLD.
- SA_NOCLDWAIT (since Linux 2.6)
-
If
signum
is
SIGCHLD,
do not transform children into zombies when they terminate.
See also
waitpid(2).
This flag is meaningful only when establishing a handler for
SIGCHLD,
or when setting that signal's disposition to
SIG_DFL.
If the
SA_NOCLDWAIT
flag is set when establishing a handler for
SIGCHLD,
POSIX.1 leaves it unspecified whether a
SIGCHLD
signal is generated when a child process terminates.
On Linux, a
SIGCHLD
signal is generated in this case;
on some other implementations, it is not.
- SA_NODEFER
-
Do not prevent the signal from being received from within its own signal
handler.
This flag is meaningful only when establishing a signal handler.
SA_NOMASK
is an obsolete, nonstandard synonym for this flag.
- SA_ONSTACK
-
Call the signal handler on an alternate signal stack provided by
sigaltstack(2).
If an alternate stack is not available, the default stack will be used.
This flag is meaningful only when establishing a signal handler.
- SA_RESETHAND
-
Restore the signal action to the default upon entry to the signal handler.
This flag is meaningful only when establishing a signal handler.
SA_ONESHOT
is an obsolete, nonstandard synonym for this flag.
- SA_RESTART
-
Provide behavior compatible with BSD signal semantics by making certain
system calls restartable across signals.
This flag is meaningful only when establishing a signal handler.
See
signal(7)
for a discussion of system call restarting.
- SA_SIGINFO (since Linux 2.2)
-
The signal handler takes three arguments, not one.
In this case,
sa_sigaction
should be set instead of
sa_handler.
This flag is meaningful only when establishing a signal handler.
The
siginfo_t
argument to
sa_sigaction
is a struct with the following elements:
siginfo_t {
int si_signo; /* Signal number */
int si_errno; /* An errno value */
int si_code; /* Signal code */
int si_trapno; /* Trap number that caused
hardware-generated signal
(unused on most architectures) */
pid_t si_pid; /* Sending process ID */
uid_t si_uid; /* Real user ID of sending process */
int si_status; /* Exit value or signal */
clock_t si_utime; /* User time consumed */
clock_t si_stime; /* System time consumed */
sigval_t si_value; /* Signal value */
int si_int; /* POSIX.1b signal */
void *si_ptr; /* POSIX.1b signal */
int si_overrun; /* Timer overrun count; POSIX.1b timers */
int si_timerid; /* Timer ID; POSIX.1b timers */
void *si_addr; /* Memory location which caused fault */
long si_band; /* Band event (was int in
glibc 2.3.2 and earlier) */
int si_fd; /* File descriptor */
short si_addr_lsb; /* Least significant bit of address
(since Linux 2.6.32) */
}
si_signo, si_errno and si_code
are defined for all signals.
(si_errno
is generally unused on Linux.)
The rest of the struct may be a union, so that one should
read only the fields that are meaningful for the given signal:
- *
-
Signals sent with
kill(2)
and
sigqueue(3)
fill in
si_pid and si_uid.
In addition, signals sent with
sigqueue(3)
fill in
si_int and si_ptr
with the values specified by the sender of the signal;
see
sigqueue(3)
for more details.
- *
-
Signals sent by POSIX.1b timers (since Linux 2.6) fill in
si_overrun
and
si_timerid.
The
si_timerid
field is an internal ID used by the kernel to identify
the timer; it is not the same as the timer ID returned by
timer_create(2).
The
si_overrun
field is the timer overrun count;
this is the same information as is obtained by a call to
timer_getoverrun(2).
These fields are nonstandard Linux extensions.
- *
-
Signals sent for message queue notification (see the description of
SIGEV_SIGNAL
in
mq_notify(3))
fill in
si_int/si_ptr,
with the
sigev_value
supplied to
mq_notify(3);
si_pid,
with the process ID of the message sender; and
si_uid,
with the real user ID of the message sender.
- *
-
SIGCHLD
fills in
si_pid, si_uid, si_status, si_utime, and si_stime,
providing information about the child.
The
si_pid
field is the process ID of the child;
si_uid
is the child's real user ID.
The
si_status
field contains the exit status of the child (if
si_code
is
CLD_EXITED),
or the signal number that caused the process to change state.
The
si_utime
and
si_stime
contain the user and system CPU time used by the child process;
these fields do not include the times used by waited-for children (unlike
getrusage(2)
and
times(2)).
In kernels up to 2.6, and since 2.6.27, these fields report
CPU time in units of
sysconf(_SC_CLK_TCK).
In 2.6 kernels before 2.6.27,
a bug meant that these fields reported time in units
of the (configurable) system jiffy (see
time(7)).
- *
-
SIGILL,
SIGFPE,
SIGSEGV,
SIGBUS,
and
SIGTRAP
fill in
si_addr
with the address of the fault.
On some architectures,
these signals also fill in the
si_trapno
field.
Some suberrors of
SIGBUS,
in particular
BUS_MCEERR_AO
and
BUS_MCEERR_AR,
also fill in
si_addr_lsb.
This field indicates the least significant bit of the reported address
and therefore the extent of the corruption.
For example, if a full page was corrupted,
si_addr_lsb
contains
log2(sysconf(_SC_PAGESIZE)).
BUS_MCERR_*
and
si_addr_lsb
are Linux-specific extensions.
- *
-
SIGIO/SIGPOLL
(the two names are synonyms on Linux)
fills in
si_band and si_fd.
The
si_band
event is a bit mask containing the same values as are filled in the
revents
field by
poll(2).
The
si_fd
field indicates the file descriptor for which the I/O event occurred.
si_code
is a value (not a bit mask)
indicating why this signal was sent.
The following list shows the values which can be placed in
si_code
for any signal, along with reason that the signal was generated.
-
- SI_USER
-
kill(2)
- SI_KERNEL
-
Sent by the kernel.
- SI_QUEUE
-
sigqueue(3)
- SI_TIMER
-
POSIX timer expired
- SI_MESGQ
-
POSIX message queue state changed (since Linux 2.6.6); see
mq_notify(3)
- SI_ASYNCIO
-
AIO completed
- SI_SIGIO
-
Queued
SIGIO
(only in kernels up to Linux 2.2; from Linux 2.4 onward
SIGIO/SIGPOLL
fills in
si_code
as described below).
- SI_TKILL
-
tkill(2)
or
tgkill(2)
(since Linux 2.4.19)
The following values can be placed in
si_code
for a
SIGILL
signal:
-
- ILL_ILLOPC
-
illegal opcode
- ILL_ILLOPN
-
illegal operand
- ILL_ILLADR
-
illegal addressing mode
- ILL_ILLTRP
-
illegal trap
- ILL_PRVOPC
-
privileged opcode
- ILL_PRVREG
-
privileged register
- ILL_COPROC
-
coprocessor error
- ILL_BADSTK
-
internal stack error
The following values can be placed in
si_code
for a
SIGFPE
signal:
-
- FPE_INTDIV
-
integer divide by zero
- FPE_INTOVF
-
integer overflow
- FPE_FLTDIV
-
floating-point divide by zero
- FPE_FLTOVF
-
floating-point overflow
- FPE_FLTUND
-
floating-point underflow
- FPE_FLTRES
-
floating-point inexact result
- FPE_FLTINV
-
floating-point invalid operation
- FPE_FLTSUB
-
subscript out of range
The following values can be placed in
si_code
for a
SIGSEGV
signal:
-
- SEGV_MAPERR
-
address not mapped to object
- SEGV_ACCERR
-
invalid permissions for mapped object
The following values can be placed in
si_code
for a
SIGBUS
signal:
-
- BUS_ADRALN
-
invalid address alignment
- BUS_ADRERR
-
nonexistent physical address
- BUS_OBJERR
-
object-specific hardware error
- BUS_MCEERR_AR (since Linux 2.6.32)
-
Hardware memory error consumed on a machine check; action required.
- BUS_MCEERR_AO (since Linux 2.6.32)
-
Hardware memory error detected in process but not consumed; action optional.
The following values can be placed in
si_code
for a
SIGTRAP
signal:
-
- TRAP_BRKPT
-
process breakpoint
- TRAP_TRACE
-
process trace trap
- TRAP_BRANCH (since Linux 2.4)
-
process taken branch trap
- TRAP_HWBKPT (since Linux 2.4)
-
hardware breakpoint/watchpoint
The following values can be placed in
si_code
for a
SIGCHLD
signal:
-
- CLD_EXITED
-
child has exited
- CLD_KILLED
-
child was killed
- CLD_DUMPED
-
child terminated abnormally
- CLD_TRAPPED
-
traced child has trapped
- CLD_STOPPED
-
child has stopped
- CLD_CONTINUED
-
stopped child has continued (since Linux 2.6.9)
The following values can be placed in
si_code
for a
SIGIO/SIGPOLL
signal:
-
- POLL_IN
-
data input available
- POLL_OUT
-
output buffers available
- POLL_MSG
-
input message available
- POLL_ERR
-
I/O error
- POLL_PRI
-
high priority input available
- POLL_HUP
-
device disconnected
RETURN VALUE
sigaction()
returns 0 on success; on error, -1 is returned, and
errno
is set to indicate the error.
ERRORS
- EFAULT
-
act or oldact
points to memory which is not a valid part of the process address space.
- EINVAL
-
An invalid signal was specified.
This will also be generated if an attempt
is made to change the action for
SIGKILL or SIGSTOP,
which cannot be caught or ignored.
CONFORMING TO
POSIX.1-2001, SVr4.
NOTES
A child created via
fork(2)
inherits a copy of its parent's signal dispositions.
During an
execve(2),
the dispositions of handled signals are reset to the default;
the dispositions of ignored signals are left unchanged.
According to POSIX, the behavior of a process is undefined after it
ignores a
SIGFPE,
SIGILL,
or
SIGSEGV
signal that was not generated by
kill(2)
or
raise(3).
Integer division by zero has undefined result.
On some architectures it will generate a
SIGFPE
signal.
(Also dividing the most negative integer by -1 may generate
SIGFPE.)
Ignoring this signal might lead to an endless loop.
POSIX.1-1990 disallowed setting the action for
SIGCHLD
to
SIG_IGN.
POSIX.1-2001 allows this possibility, so that ignoring
SIGCHLD
can be used to prevent the creation of zombies (see
wait(2)).
Nevertheless, the historical BSD and System V behaviors for ignoring
SIGCHLD
differ, so that the only completely portable method of ensuring that
terminated children do not become zombies is to catch the
SIGCHLD
signal and perform a
wait(2)
or similar.
POSIX.1-1990 specified only
SA_NOCLDSTOP.
POSIX.1-2001 added
SA_NOCLDWAIT,
SA_RESETHAND,
SA_NODEFER,
and
SA_SIGINFO.
Use of these latter values in
sa_flags
may be less portable in applications intended for older
UNIX implementations.
The
SA_RESETHAND
flag is compatible with the SVr4 flag of the same name.
The
SA_NODEFER
flag is compatible with the SVr4 flag of the same name under kernels
1.3.9 and newer.
On older kernels the Linux implementation
allowed the receipt of any signal, not just the one we are installing
(effectively overriding any
sa_mask
settings).
sigaction()
can be called with a NULL second argument to query the current signal
handler.
It can also be used to check whether a given signal is valid for
the current machine by calling it with NULL second and third arguments.
It is not possible to block
SIGKILL or SIGSTOP
(by specifying them in
sa_mask).
Attempts to do so are silently ignored.
See
sigsetops(3)
for details on manipulating signal sets.
See
signal(7)
for a list of the async-signal-safe functions that can be
safely called inside from inside a signal handler.
Undocumented
Before the introduction of
SA_SIGINFO
it was also possible to get some additional information,
namely by using a
sa_handler
with second argument of type
struct sigcontext.
See the relevant Linux kernel sources for details.
This use is obsolete now.
BUGS
In kernels up to and including 2.6.13, specifying
SA_NODEFER
in
sa_flags
prevents not only the delivered signal from being masked during
execution of the handler, but also the signals specified in
sa_mask.
This bug was fixed in kernel 2.6.14.
EXAMPLE
See
mprotect(2).
SEE ALSO
kill(1),
kill(2),
killpg(2),
pause(2),
restart_syscall(2),
sigaltstack(2),
signal(2),
signalfd(2),
sigpending(2),
sigprocmask(2),
sigsuspend(2),
wait(2),
raise(3),
siginterrupt(3),
sigqueue(3),
sigsetops(3),
sigvec(3),
core(5),
signal(7)
Index
- NAME
-
- SYNOPSIS
-
- DESCRIPTION
-
- RETURN VALUE
-
- ERRORS
-
- CONFORMING TO
-
- NOTES
-
- Undocumented
-
- BUGS
-
- EXAMPLE
-
- SEE ALSO
-
This document was created by
man2html,
using the manual pages.
Time: 02:54:45 GMT, September 18, 2014


What will be printed by this code?
public static void main(String [] args){ int number = 6; int secondNumber = changeNumber (number); System.out.print(number + " " + secondNumber); } public static int changeNumber(int number){ number = 12; return number; }
The variable number is set to 6, then a second number is set to the result of "changeNumber" where 6 is passed as a parameter.


---
title: "Schedule"
slug: schedule
output:
blogdown::html_page:
toc: false
---
This page contains all of the following resources for each class meeting:
-
Content materials contains suggested readings, more details about assignments, math appendices, and other helpful resources. I suggest you view these before each class.
-
Slides are “Xaringan” presentations in html that can be opened in any browser (You can find a downloadable PDF in each respective content page)
-
Practice problems we work on together in class to prepare for homeworks and exams
-
Assignments are listed with due dates
Please note that the lesson numbers, topics, and titles (e.g. 1.1) are my design, and do not match up with the textbook!
Relevant materials, if applicable will be posted before class meets and become colored links.
{{% schedule %}}


What Is It?
Funtime 1.1 is a small and easy to use CSS freamwork that can help you rapidly develop sites that look beautiful at any size, be it a 17" laptop screen or an iPhone.
Please check out base.css file for more awesome stuff.
Grid showcase
You only need to copy and paste following classes.
Buttons
You also can use flaty style buttons. Mark up is realy simple.
Check out four different sizes.
You can display your button how block element.
Forms
Check out simply and fast to use forms.


Experiments in Reading
I’ve never watched Battlestar Galactica, so I don’t really know what the particular fuzz in the Portlandia sketch below is all about. However, I’ve been in Doug’s (Fred Armisen) and Claire’s (Carrie Brownstein) shoes––I know too well the feeling of wanting to watch just one more episode of__________________. As a matter of fact, in a totally meta experience I watched this episode of Portlandia during a binge watching weekend a few years ago.
[embed]https://youtu.be/yYjLrJRuMnY[/embed]
The scene above and its follow up highlight (hyperbolically as per the show’s satiric tone) the feeling of loss and dejection that are so hard to keep at bay when suddenly exiting a fictional world we have been inhabiting for a while. The experience is surely not one exclusive to TV series, and many of us will have memories of binge reading long novels as kids as well as in later years. I recall spending three blurry days madly turning each of the 600 pages in the Spanish edition of Roberto Bolaño’s Savage Detectives about a decade ago, and more recently, a couple of days with Chimamanda Adichie’s Americanah and two or three frantic hours devouring Maggie Nelson’s Bluets. I also distinctly recall physically missing the presence of the characters and the narrative voices each time, and finding everything but those worlds utterly boring for a short while afterwards. This form and level of immersion has been thematized not just in Portlandia, obviously, but also in countless metafictions and explored in many kinds of studies ranging from cognitive criticism and neuroscience to, again, metafiction and others. I myself wrote a bit about itand Miguel de Unamuno’s Niebla a couple of years ago.
The general consensus of why this happens (cognitively speaking) is that we use the exact same mental mechanisms to deal with both fictional worlds and the real ones (whatever that might mean metaphysically). Getting immersed in a fictional world puts fiction and fact on the same undiscriminated stand. Richard Gerrig sees this kind of mental immersion as moving from the actual immediate surroundings and relocating in the fictional world.
An important consideration is that immersion (or binge watching) lasts only as long as there is more to read, more to watch—a continuous supply of input from the fiction that can be put on top of our immediate surroundings. The dimensions of the fictional world depends, of course, on the limits of the work (they all end at some point), the boundaries of its distribution systems, and the way the reader/viewer actually handles and mediates the work. Thus, it is crucial to think about, at least, two material aspects of the works: 1) The fact that fictional or literary worlds are not made up of air, and thus our engagement with—and mediation of—them is governed by the limitations or affordances of the artifact that embodies them; and 2) The media configuration of each fiction/each work generates its specific (reading or watching) conditions: episodic, continuous, etc.
Coming back to Portlandia, Doug and Claire have the whole season in DVD’s. The kind of immersion they go through is only possible due to the fact that they mediate and handle their engagement with the fictional world stored in them. Although it’s not showed on the screen, we assume they obtain subsequent seasons of Battlestar Galactica to keep them going for days. Other than the fact that there are no more episodes to watch, the only real impediment to their binge watching is a power outage: an invisible infrastructure that sustains their immersion. The work and its distribution systems (including the infrastructure that supports it) imposes the physicality of the medium above the existence of the fictional world. This is true, or at least similar, for most long novels. As long as we hold the entire book in our hands (or have the entire file in an e-reader) we can go on binge reading. In fact, we could binge read any print or e-book. There is very little in the specific material reading conditions imposed by the medium that would prevent us from it (in the case of the e-reader, power would be one).
A very different experience for Doug and Claire (and me when I first watched this episode) would have been to watch the series episode by episode as they were released by the network. A very different experience would also be to read the first part of Savage Detectives episodically following the dates of the diary entries. In the first case, Doug and Claire’s experience would be mediated by the distribution of the work (let’s leave aside the economic model that shapes this for now), whereas in the second case, it is only suggested but not imposed by the composition of the work.
I think this is an extremely intriguing phenomenon in the current media ecology. Each device and each work have a temporality embedded that may or may not be a part of the a work’s meaning making mechanisms, but that are definitely a part of the way each reader handles and mediates their reading (binge, episodic, fragmentary, hypermediated, etc.). Some works and distribution systems impose certain specific reading conditions, but others might just suggest it. In any case, exploring the various possibilities is worth a try.
In order to carry out a little experiment in reading mediation, I waited a few months to start reading Amaranth Borsuk and Andy Fitch’s As We Know, the daybook of a student spanning from April 30^th^ to July 1^st^. On April 30^th^ I read the very first entry and as of today, I have read four entries. Fighting the urge to binge read just one more day (two more pages), I’m thinking through time-based reading: a notion I more easily recognize and theorize in electronic works where, as Rita Raley has it, reading and the boundaries of a digital text are delineated by “the period in which both the reader-user and the system are performing” (The Digital Loop: Feedback and Recurrence). As We Know is even a more particular case because it is a poetry collection but one that moves temporally, and although I can’t be sure yet, narratively, I think.
[caption id=”attachment_770” align=”aligncenter” width=”640”]{.wp-image-770 .size-full width=”640” height=”274”} Borsuk and Fitch’s As We Know, May 3rd.[/caption]
Even though As We Know does not impose materially this kind of episodic reading condition, it invites and evokes it. The work certainly conjures a very particular reading and it collapses the separate temporalities of both authors (Fitch 2007 and Borsuk 2013) A reading like the one I’m doing is a deliberate way to relocate the days contained in As We Know in my days, to blend the temporal referents of both and run them synchronously. That way, if a change in the original distribution conditions of Battlestar Galactica and Portlandia modify the conditions in which they can be watched and the immersive effect they have, the question I’ll be thinking through until July 1^st^ is how does a speculative handling of the time frames in As We Know can shape the reading conditions embedded in the print book?


|
SA-PCB
Annealing-basedPCBplacementtool
|
Public Member Functions | |
| GridBasedPlacer (kicadPcbDataBase &db) | |
| void | test_hplacer_flow () |
| kicadPcbDataBase & | test_placer_flow () |
| kicadPcbDataBase & | getDb () |
| double | get_total_cost () |
| double | get_wirelength_cost () |
| double | get_overlap_cost () |
| double | get_temperature () |
| void | set_overlap_weight (double _cst) |
| void | set_wirelength_weight (double _cst) |
| void | set_two_sided (bool _2sided) |
| void | set_initial_move_radius (double _eps) |
| void | set_rtree (bool _rt) |
| void | set_lam (bool _lam) |
| void | set_lamtemp_update (double _coef) |
| void | set_num_iterations (int iter) |
| void | set_iterations_moves (int iter) |
| void | set_initial_temperature (double tmp) |
| double | h_cellDensity () |
| void | h_initialize_params (map< int, vector< Module * > > &netToCell) |
| void | h_validate_move (Module *node, double rx, double ry) |
| double | h_cost (map< int, vector< Module * > > &netToCell, int temp_debug=0) |
| double | h_cost_partial (vector< Module * > &nodes, map< int, vector< Module * > > &netToCell) |
| double | h_cell_overlap () |
| double | h_wirelength (map< int, vector< Module * > > &netToCell) |
| double | h_cell_overlap_partial (vector< Module * > &nodes) |
| double | h_wirelength_partial (vector< Module * > &nodes, map< int, vector< Module * > > &netToCell) |
| double | h_rudy (map< int, vector< Module * > > &netToCell) |
| float | h_annealer (map< int, vector< Module * > > &netToCell, string initial_pl, int level=0) |
| double | h_initialize_temperature (double &Temperature, map< int, vector< Module * > > &netToCell) |
| double | h_initiate_move (double current_cost, map< int, vector< Module * > > &netToCell) |
| void | h_random_placement (int xmin, int xmax, int ymin, int ymax, Module &n) |
| void | h_random_initial_placement () |
| bool | h_check_move (double prevCost, double newCost, double &Temperature) |
| vector< Module * >::iterator | h_random_node () |
Public Attributes | |
| kicadPcbDataBase & | mDb |
| float GridBasedPlacer::h_annealer | ( | map< int, vector< Module * > > & | netToCell, |
| string | initial_pl, | ||
| int | level = 0 |
||
| ) |
h_annealer fmain loop for sa algorithm
annealer main loop for sa algorithm
| double GridBasedPlacer::h_cell_overlap | ( | ) |
h_cell_overlap Compute sum squared overlap for all components
cell_overlap Compute sum squared overlap for all components
| double GridBasedPlacer::h_cell_overlap_partial | ( | vector< Module * > & | nodes | ) |
h_cell_overlap_partial Compute sum squared overlap for select components
cell_overlap_partial Compute sum squared overlap for select components
| double GridBasedPlacer::h_cellDensity | ( | ) |
h_rudy Computes a routability score
rudy Computes a routability score
| bool GridBasedPlacer::h_check_move | ( | double | prevCost, |
| double | newCost, | ||
| double & | Temperature | ||
| ) |
h_check_move either accept or reject the move based on current & previous temperature & cost
check_move either accept or reject the move based on current & previous temperature & cost
| void GridBasedPlacer::h_random_initial_placement | ( | ) |
h_initial_placement Randomly place and orient all movable components in the board area
initial_placement Randomly place and orient all movable components in the board area
| vector< Module * >::iterator GridBasedPlacer::h_random_node | ( | ) |
h_random_node Select random node from set of nodes
random_node Select random node from set of nodes
| void GridBasedPlacer::h_random_placement | ( | int | xmin, |
| int | xmax, | ||
| int | ymin, | ||
| int | ymax, | ||
| Module & | n | ||
| ) |
hannealer main loop for hierarchical sa algorithm h_random_placement Randomly place and orient a single component within a bounded region
random_placement Randomly place and orient a single component within a bounded region
| double GridBasedPlacer::h_rudy | ( | map< int, vector< Module * > > & | netToCell | ) |
h_rudy Computes a routability score
rudy Computes a routability score
| void GridBasedPlacer::h_validate_move | ( | Module * | node, |
| double | rx, | ||
| double | ry | ||
| ) |
h_validate_move validates a shift, project within board boundary
validate_move validates a shift, project within board boundary
| double GridBasedPlacer::h_wirelength | ( | map< int, vector< Module * > > & | netToCell | ) |
h_wirelength Computes HPWL for all nets
wirelength Computes HPWL for all nets
| double GridBasedPlacer::h_wirelength_partial | ( | vector< Module * > & | nodes, |
| map< int, vector< Module * > > & | netToCell | ||
| ) |
h_wireLength_partial Compute HPWL for select nets
wireLength_partial Compute HPWL for select nets


What is Project Breakpoint?
Project Breakpoint is a brand I created a long time ago. It is not a business, I do not try to make money off of it. It's a name for me to slap on my web content and call it mine.
Project Breakpoint is a brand I created a long time ago. It is not a business, I do not try to make money off of it. It's a name for me to slap on my web content and call it mine.
My name is Jonathan Kuhl and I am a web developer. I started learning web development back in the days of HTML4 when I was in high school. I also learned some game programming with 3d GameStudio and their C-Script language. I didn't stay with it and that is something I'll regret the rest of my life, because there is a gap in my experience between HTML4, and when I picked up HTML5 again in 2017.
I went to college first for Aviation Flight Operations and then for Air Traffic Control. This plan didn't pan out so I switched gears in 2017 towards web and software development. Most of the things on this site are resources that I've used to advance my knowledge.
I have put my focus in JavaScript and web development as well as React, Angular and Vue. I'm focusing on Front End, though I have interest in Node.js, Express, and Mongo. I also know some SQL. Beyond web development, I know Python and Swift.
Outside of programming, I like to write. I have a few unpublished novels that are half-developed, that I work on now and then. I usually participate in NaNoWriMo, if you're a writer, check it out. I like to write sci-fi and fantasy.
Professionally, I'm an NCO in the United States Air Force Reserves at Westover ARB. I've also held several jobs in the civilian sector. I was a lift operator for Sunday River, Maine, a ramp agent for JetBlue and United at Portland International, in Maine, and most recently, a relationship manager for Barclays.


Channing Tatum and Jenna Dewan’s divorce finalised
Channing Tatum and Jenna Dewan are officially free from each other as a judge has finalised their divorce almost two years after their split.
The former couple, who married in 2009 three years after meeting on the set of Step Up, announced their split in April 2018.
It’s now reported that a judge has granted their request to legally separate while they discuss custody agreements and a property settlement. Channing and Jenna recently filed papers asking for the divorce so that they have the option to settle down with their new partners.
According to TMZ, documents filed by Jenna’s lawyer Samantha Spector indicate the divorce judgement was announced on Tuesday.
The former spouses now have to work out a custody agreement for their six-year-old daughter Everly whom they are currently co-parenting.
Jenna, 38, was the first to file for the divorce.
Both Channing, 39, and Jenna have moved on with other people – the Magic Mike actor is currently dating British singer Jessie J, while his ex-wife is in a relationship wit Shameless actor Steve Kazee, and is currently pregnant with their first child.
The divorce has come at the right time for Jenna, who reportedly wants to marry Steve, 43.
Advertisement Advertisement
A source told E! News: ‘Jenna plans to marry Steve and is so in love with him. They have had many long and open talks about that and it’s definitely the plan.
‘What matters most though is that she and Steve are fully committed and so excited to have a baby and grow their family. She knows they will be engaged and married soon enough.’
Jenna opened up about her split from Channing in her new wellness book, explaining: ‘I’d come to realise the dynamic I was in wasn’t serving me nor was it serving my daughter.
‘First and foremost I had to accept the realisation this isn’t working and had moved into hurting. The public saw Channing and I in this idealised romanticised light. This made things difficult for me because I like being as honest and real as I can.’
Got a showbiz story?
If you've got a story, video or pictures get in touch with the Metro.co.uk Entertainment team by emailing us<EMAIL_ADDRESS>calling 020 3615 2145 or by visiting our Submit Stuff page - we'd love to hear from you.


This document is a report of the results of a meeting of a group of W3C
Members involved in XML and
RDF to advance the general
understanding of a unified approach to the expression of Web data models.
This document is one response to the Web data architecture discussed
in "Web Architecture:
Describing and Exchanging Data".
This document is a W3C Note made available by the World Wide Web Consortium.
Public comments may be directed to the
RDF comments list
(archive)
or to the
XML Schema comments list
(archive).
Publication of a W3C Note does not imply endorsement by the entire W3C
Membership. A list of current W3C technical reports and publications,
including Working Drafts and Notes, can be found at http://www.w3.org/TR.
This section represents the status of this document at the time this
version was published. It will become outdated if and when a new
version is published. The latest
status
is maintained at the W3C.
Contents
- Introduction
- Background
- Observations and Recommendations
- Conclusions
- Signatories
1. Introduction
A group consisting of W3C Member representatives and W3C staff
involved in the
XML and
RDF activities
met
[members only]
on August 26 and 27 to discuss the architectural
relationship between the schema work being undertaken within these two
activities. The goals of this meeting were to articulate a vision of
this relationship for the Web community, to feed input into the
XML Schema
Working Group
and other W3C activities in support of this
vision, and to resolve issues raised in the Member review of the
RDF Schema
Proposed Recommendation concerning overlap with XML work.
2. Background
The group discussed a wide range of relevant issues which have in
common the goal of supporting the exchange of data on the Web:
-
XML
has defined a transfer syntax for tree-structured documents;
-
Many data-oriented applications are being defined which build
their own data structures on
top of an XML document layer, effectively using XML documents as a
transfer mechanism for structured data;
-
RDF
is a W3C recommendation which already employs this layered
approach. RDF is a member of the Entity-Relationship modelling
family in which data structured as directed labelled graphs
can be exchanged via XML documents using a specific XML grammar;
-
It is a goal to facilitate the use of RDF mechanisms to access
the information contained in a broad range of XML documents,
including those that were not initially structured according
to the RDF 1.0 layering.
As the expressive facilities available in the XML family, which
includes RDF, become richer we need an understanding of how these
facilities relate to similar mechanisms available within other
formalisms that have adopted XML as their transfer syntax.
3. Observations and Recommendations
This group reached consensus on the following observations and recommendations:
-
The XML data model is the
XML Information Set
being specified by the XML Information Set
Working Group.
Other data models exist, both
generic and application-specific.
RDF is an example of one such generic data model.
The XML Schema and RDF Schema
languages are separate languages based on different data
models and do not need to be merged into a single comprehensive
language.
-
An XML Schema schema document will be able to hold declarations for
validating instance documents.
It should also be able to hold declarations for mapping from instance
document XML infosets to application-oriented data structures.
-
For evolvability and interoperability, the
XML Schema specification should provide an extension mechanism
allowing for
the augmentation of XML Schema schemas with additional material.
At a minimum, XML Schema should permit elements from other
namespaces to be included in schema documents. This extension mechanism
should also permit individual extensions to be marked 'mandatory',
meaning that a document instance cannot be deemed 'schema valid'
if the processing required by a marked extension cannot be performed.
-
The extension mechanism should be appropriate for use to incorporate
declarations ("mapping declarations") to aid the construction
of application-oriented data structures (e.g. ones implementing
the RDF model) as part of the schema-validation and XML infoset
construction process. This facility should not be exclusive to
RDF, but should also be useable to guide the construction of data
structures conforming to other data models, e.g.
UML.
-
Such mapping declarations should ideally also be useable by other
schema processors to map in the other direction, i.e. from
application-oriented data structures to XML infosets.
-
Many schema languages and query languages are or could be layered on top
of the XML foundation. RDF Schema is one such language. It is
appropriate that some mechanisms will apply to both layers and some will
only apply to one or the other.
-
XML Schema does not need to be the sole provider of support for
layering application data structures on XML.
XSLT, with a
proposed extension mechanism,
could be used for specifying mappings from XML document
instances to application data structures - including RDF graphs.
The reversibility of mappings specified with XSLT or similar
transformation languages is an issue.
-
A new simplified XML transfer syntax for RDF and an API for
accessing RDF data models should be produced. The
RDF 1.0 transfer
syntax remains a W3C Recommendation and applications are free to
continue to use it. It is not a requirement that XML Schema be able
to validate conformance to the full grammar of RDF 1.0 syntax
(e.g. equivalence of elements and attributes).
-
XML Schema type hierarchies and RDF type hierarchies are not the same
and need not be unified; in particular, it is too soon to tell if
RDF schemas can leverage XML Schema archetypes. However the atomic
data types, notably URIref, should be shared and work needs to be
done to support this.
4. Conclusions
The attendees understand that the XML Schema Working Group is presently
addressing some of these topics in the context of its existing
Requirements Document.
We trust that the consensus developed at this
meeting will help the XML Schema Working Group prioritize features for XML
Schema 1.0 and will also help the W3C Director while considering the next
steps for RDF Schema.
5. Signatories
David Beech, Oracle Corp.
Gabe Beged-Dov, Rogue Wave Software
Tim Berners-Lee, W3C
Dan Brickley, University of Bristol
Allen Brown, Microsoft
Peter Chen, Bootstrap Alliance
David Cleary, Progress Software
Ron Daniel, DATAFUSION
Andrew Eisenberg, Progress Software
David Epstein, IBM
George Feinberg, Object Design
R.V. Guha (unable to attend but endorsing this communiqué)
Ora Lassila, Nokia
Eve Maler, ArborText, Inc.
Ashok Malhotra, IBM
Murray Maloney, Commerce One
Noah Mendelsohn, Lotus
Eric Miller, OCLC
Wei Song, SISU
Ralph Swick, W3C
Henry Thompson, University of Edinburgh
$Date: 1999/10/08 18:21:06 $
Ralph R. Swick
<EMAIL_ADDRESS>and
Henry S. Thompson,
<EMAIL_ADDRESS>rapporteurs
Revision History:
1999-09-13T19:54 published
1999-09-13T20:35 correct Daniel affiliation
1999-09-15T14:34 add a signature
1999-09-15T14:40 add document id to the document itself
1999-09-20T13:19 update Status to direct comments to public archives
1999-10-07T17:25 add abstract, table of contents, update status


A Deep Dive into Rescalable State in Apache Flink
July 4, 2017 -Apache Flink 1.2.0, released in February 2017, introduced support for rescalable state. This post provides a detailed overview of stateful stream processing and rescalable state in Flink.
An Intro to Stateful Stream Processing #
At a high level, we can consider state in stream processing as memory in operators that remembers information about past input and can be used to influence the processing of future input.
In contrast, operators in stateless stream processing only consider their current inputs, without further context and knowledge about the past. A simple example to illustrate this difference: let us consider a source stream that emits events with schema e = {event_id:int, event_value:int}
. Our goal is, for each event, to extract and output the event_value
. We can easily achieve this with a simple source-map-sink pipeline, where the map function extracts the event_value
from the event and emits it downstream to an outputting sink. This is an instance of stateless stream processing.
But what if we want to modify our job to output the event_value
only if it is larger than the value from the previous event? In this case, our map function obviously needs some way to remember the event_value
from a past event — and so this is an instance of stateful stream processing.
This example should demonstrate that state is a fundamental, enabling concept in stream processing that is required for a majority of interesting use cases.
State in Apache Flink #
Apache Flink is a massively parallel distributed system that allows stateful stream processing at large scale. For scalability, a Flink job is logically decomposed into a graph of operators, and the execution of each operator is physically decomposed into multiple parallel operator instances. Conceptually, each parallel operator instance in Flink is an independent task that can be scheduled on its own machine in a network-connected cluster of shared-nothing machines.
For high throughput and low latency in this setting, network communications among tasks must be minimized. In Flink, network communication for stream processing only happens along the logical edges in the job’s operator graph (vertically), so that the stream data can be transferred from upstream to downstream operators.
However, there is no communication between the parallel instances of an operator (horizontally). To avoid such network communication, data locality is a key principle in Flink and strongly affects how state is stored and accessed.
For the sake of data locality, all state data in Flink is always bound to the task that runs the corresponding parallel operator instance and is co-located on the same machine that runs the task.
Through this design, all state data for a task is local, and no network communication between tasks is required for state access. Avoiding this kind of traffic is crucial for the scalability of a massively parallel distributed system like Flink.
For Flink’s stateful stream processing, we differentiate between two different types of state: operator state and keyed state. Operator state is scoped per parallel instance of an operator (sub-task), and keyed state can be thought of as “operator state that has been partitioned, or sharded, with exactly one state-partition per key”. We could have easily implemented our previous example as operator state: all events that are routed through the operator instance can influence its value.
Rescaling Stateful Stream Processing Jobs #
Changing the parallelism (that is, changing the number of parallel subtasks that perform work for an operator) in stateless streaming is very easy. It requires only starting or stopping parallel instances of stateless operators and dis-/connecting them to/from their upstream and downstream operators as shown in Figure 1A.
On the other hand, changing the parallelism of stateful operators is much more involved because we must also (i) redistribute the previous operator state in a (ii) consistent, (iii) meaningful way. Remember that in Flink’s shared-nothing architecture, all state is local to the task that runs the owning parallel operator instance, and there is no communication between parallel operator instances at job runtime.
However, there is already one mechanism in Flink that allows the exchange of operator state between tasks, in a consistent way, with exactly-once guarantees — Flink’s checkpointing!
You can see detail about Flink’s checkpoints in the documentation. In a nutshell, a checkpoint is triggered when a checkpoint coordinator injects a special event (a so-called checkpoint barrier) into a stream.
Checkpoint barriers flow downstream with the event stream from sources to sinks, and whenever an operator instance receives a barrier, the operator instance immediately snapshots its current state to a distributed storage system, e.g. HDFS.
On restore, the new tasks for the job (which potentially run on different machines now) can again pick up the state data from the distributed storage system.
We can piggyback rescaling of stateful jobs on checkpointing, as shown in Figure 1B. First, a checkpoint is triggered and sent to a distributed storage system. Next, the job is restarted with a changed parallelism and can access a consistent snapshot of all previous state from the distributed storage. While this solves (i) redistribution of a (ii) consistent state across machines there is still one problem: without a clear 1:1 relationship between previous state and new parallel operator instances, how can we assign the state in a (iii) meaningful way?
We could again assign the state from previous map_1
and map_2
to the new map_1
and map_2
. But this would leave map_3
with empty state. Depending on the type of state and concrete semantics of the job, this naive approach could lead to anything from inefficiency to incorrect results.
In the following section, we’ll explain how we solved the problem of efficient, meaningful state reassignment in Flink. Each of Flink state’s two flavours, operator state and keyed state, requires a different approach to state assignment.
Reassigning Operator State When Rescaling #
First, we’ll discuss how state reassignment in rescaling works for operator state. A common real-world use-case of operator state in Flink is to maintain the current offsets for Kafka partitions in Kafka sources. Each Kafka source instance would maintain <PartitionID, Offset>
pairs – one pair for each Kafka partition that the source is reading–as operator state. How would we redistribute this operator state in case of rescaling? Ideally, we would like to reassign all <PartitionID, Offset>
pairs from the checkpoint in round robin across all parallel operator instances after the rescaling.
As a user, we are aware of the “meaning” of Kafka partition offsets, and we know that we can treat them as independent, redistributable units of state. The problem of how we can we share this domain-specific knowledge with Flink remains.
Figure 2A illustrates the previous interface for checkpointing operator state in Flink. On snapshot, each operator instance returned an object that represented its complete state. In the case of a Kafka source, this object was a list of partition offsets.
This snapshot object was then written to the distributed store. On restore, the object was read from distributed storage and passed to the operator instance as a parameter to the restore function.
This approach was problematic for rescaling: how could Flink decompose the operator state into meaningful, redistributable partitions? Even though the Kafka source was actually always a list of partition offsets, the previously-returned state object was a black box to Flink and therefore could not be redistributed.
As a generalized approach to solve this black box problem, we slightly modified the checkpointing interface, called ListCheckpointed
. Figure 2B shows the new checkpointing interface, which returns and receives a list of state partitions. Introducing a list instead of a single object makes the meaningful partitioning of state explicit: each item in the list still remains a black box to Flink, but is considered an atomic, independently re-distributable part of the operator state.
Our approach provides a simple API with which implementing operators can encode domain-specific knowledge about how to partition and merge units of state. With our new checkpointing interface, the Kafka source makes individual partition offsets explicit, and state reassignment becomes as easy as splitting and merging lists.
public class FlinkKafkaConsumer<T> extends RichParallelSourceFunction<T> implements CheckpointedFunction {
// ...
private transient ListState<Tuple2<KafkaTopicPartition, Long>> offsetsOperatorState;
@Override
public void initializeState(FunctionInitializationContext context) throws Exception {
OperatorStateStore stateStore = context.getOperatorStateStore();
// register the state with the backend
this.offsetsOperatorState = stateStore.getSerializableListState("kafka-offsets");
// if the job was restarted, we set the restored offsets
if (context.isRestored()) {
for (Tuple2<KafkaTopicPartition, Long> kafkaOffset : offsetsOperatorState.get()) {
// ... restore logic
}
}
}
@Override
public void snapshotState(FunctionSnapshotContext context) throws Exception {
this.offsetsOperatorState.clear();
// write the partition offsets to the list of operator states
for (Map.Entry<KafkaTopicPartition, Long> partition : this.subscribedPartitionOffsets.entrySet()) {
this.offsetsOperatorState.add(Tuple2.of(partition.getKey(), partition.getValue()));
}
}
// ...
}
Reassigning Keyed State When Rescaling #
The second flavour of state in Flink is keyed state. In contrast to operator state, keyed state is scoped by key, where the key is extracted from each stream event.
To illustrate how keyed state differs from operator state, let’s use the following example. Assume we have a stream of events, where each event has the schema {customer_id:int, value:int}
. We have already learned that we can use operator state to compute and emit the running sum of values for all customers.
Now assume we want to slightly modify our goal and compute a running sum of values for each individual customer_id
. This is a use case from keyed state, as one aggregated state must be maintained for each unique key in the stream.
Note that keyed state is only available for keyed streams, which are created through the keyBy()
operation in Flink. The keyBy()
operation (i) specifies how to extract a key from each event and (ii) ensures that all events with the same key are always processed by the same parallel operator instance. As a result, all keyed state is transitively also bound to one parallel operator instance, because for each key, exactly one operator instance is responsible. This mapping from key to operator is deterministically computed through hash partitioning on the key.
We can see that keyed state has one clear advantage over operator state when it comes to rescaling: we can easily figure out how to correctly split and redistribute the state across parallel operator instances. State reassignment simply follows the partitioning of the keyed stream. After rescaling, the state for each key must be assigned to the operator instance that is now responsible for that key, as determined by the hash partitioning of the keyed stream.
While this automatically solves the problem of logically remapping the state to sub-tasks after rescaling, there is one more practical problem left to solve: how can we efficiently transfer the state to the subtasks’ local backends?
When we’re not rescaling, each subtask can simply read the whole state as written to the checkpoint by a previous instance in one sequential read.
When rescaling, however, this is no longer possible – the state for each subtask is now potentially scattered across the files written by all subtasks (think about what happens if you change the parallelism in hash(key) mod parallelism
). We have illustrated this problem in Figure 3A. In this example, we show how keys are shuffled when rescaling from parallelism 3 to 4 for a key space of 0, 20, using identity as hash function to keep it easy to follow.
A naive approach might be to read all the previous subtask state from the checkpoint in all sub-tasks and filter out the matching keys for each sub-task. While this approach can benefit from a sequential read pattern, each subtask potentially reads a large fraction of irrelevant state data, and the distributed file system receives a huge number of parallel read requests.
Another approach could be to build an index that tracks the location of the state for each key in the checkpoint. With this approach, all sub-tasks could locate and read the matching keys very selectively. This approach would avoid reading irrelevant data, but it has two major downsides. A materialized index for all keys, i.e. a key-to-read-offset mapping, can potentially grow very large. Furthermore, this approach can also introduce a huge amount of random I/O (when seeking to the data for individual keys, see Figure 3A, which typically entails very bad performance in distributed file systems.
Flink’s approach sits in between those two extremes by introducing key-groups as the atomic unit of state assignment. How does this work? The number of key-groups must be determined before the job is started and (currently) cannot be changed after the fact. As key-groups are the atomic unit of state assignment, this also means that the number of key-groups is the upper limit for parallelism. In a nutshell, key-groups give us a way to trade between flexibility in rescaling (by setting an upper limit for parallelism) and the maximum overhead involved in indexing and restoring the state.
We assign key-groups to subtasks as ranges. This makes the reads on restore not only sequential within each key-group, but often also across multiple key-groups. An additional benefit: this also keeps the metadata of key-group-to-subtask assignments very small. We do not maintain explicit lists of key-groups because it is sufficient to track the range boundaries.
We have illustrated rescaling from parallelism 3 to 4 with 10 key-groups in Figure 3B. As we can see, introducing key-groups and assigning them as ranges greatly improves the access pattern over the naive approach. Equation 2 and 3 in Figure 3B also details how we compute key-groups and the range assignment.
Wrapping Up #
Thanks for staying with us, and we hope you now have a clear idea of how rescalable state works in Apache Flink and how to make use of rescaling in real-world scenarios.
Flink 1.3.0, which was released earlier this month, adds more tooling for state management and fault tolerance in Flink, including incremental checkpoints. And the community is exploring features such as…
• State replication
• State that isn’t bound to the lifecycle of a Flink job
• Automatic rescaling (with no savepoints required)
…for Flink 1.4.0 and beyond.
If you’d like to learn more, we recommend starting with the Apache Flink documentation.
This is an excerpt from a post that originally appeared on the data Artisans blog. If you’d like to read the original post in its entirety, you can find it here (external link).


Working With Groups
A group is a (permanent or temporary) collection of related files or entities. Groups can contain any entity, instance, or combination of entities and instances.
You can use groups to track your progress on files from a specific project, save the full or partial results from a lengthy or sophisticated query, or understand relationships throughout an application or between multiple applications.
You can create and maintain groups by accessing the Group Manager through the Tools > Group Manager menu or the Group button in the Browser or Minibrowser. The Group Manager offers options that allow you to administer your groups, such as displaying or adding members, as well as perform set operations, such as viewing intersections and unions.
The Group Manager contains the following menus:
• Group provides administrative operations, including Create, Rename, Delete, Save, Print, Refresh, and Close.
• Elements allows you to Add, Remove, or Replace members (selected entities) to and from a group.
• Operator provides group operations, such as calculating and viewing group intersections and unions.
• Browse enables you to display all instances of entities contained in the group using an instances view, the main Browser, or the Minibrowser.
Group administration, performed through the Group menu of the Group Manager, allows you to create, rename, save, and delete groups.


Back Step 2b of 7
What is your appeal about?
You will find this information on either the original notice letter or review conclusion letter from HMRC.
Back Step 2b of 7
You will find this information on either the original notice letter or review conclusion letter from HMRC.


| html-dependencies {shinyWidgets} | R Documentation |
These functions are used internally to load dependencies for widgets. Not all of them are exported. Below are the ones needed for package fresh.
html_dependency_awesome() html_dependency_bttn() html_dependency_pretty() html_dependency_bsswitch() html_dependency_sweetalert2( theme = c("sweetalert2", "minimal", "dark", "bootstrap-4", "material-ui", "bulma", "borderless") )
theme |
SweetAlert theme to use. |
an htmlDependency
.
# Use in UI or tags function library(shiny) fluidPage( html_dependency_awesome() )


http://action.vday.org/site/R?i=405haQxLLz1GyDJYIIQPIQ
http://action.vday.org/site/R?i=24r_4HxIVtCm2yRvnqcgeA
http://action.vday.org/site/R?i=DhOZrBgbTOShuH4Ac1BNHA
http://action.vday.org/site/R?i=A69Ia6NHsZea8BYskJu7oA
UPDATE from City of Joy - Third Class Graduates!
V-Day Congo & City of Joy Director Christine Schuler Deschryver
shares with us news from City of Joy ( http://action.vday.org/site/R?i=pN9kncNWxe2Hvn5dfOmbhw )
and third class of graduates:
It is hard to put into words what the graduation yesterday was like -
it is just beyond words, the transformation of the girls and the
children is so radical. Many people attended, most of them from civil
society. Dr. Mukwege also came with lots of his visitors and I don’t
remember seeing him so proud and happy. He did an amazing speech
glorifying our work, and the girls.
Girls were radiant and extremely proud to show everything they learned
at City of Joy. Theatre and songs were used. Some of my favorite
Congolese actors here surprised me by coming and played the role of a
wife coming back home after being raped, healed at Panzi hospital and
trained at City Of Joy. It was just excellent.
Let me thank all of you for your support to make this happen. As I
told Eve, my strength here is my friendship with her and all your
love. It is more and more difficult to work here - problems coming
from everywhere, challenges everyday. We have to go on knowing we are
doing our best, trying to bring brighter days in the darkness of DR
Congo. You cannot change the world without love.
Social workers left this morning for new recruitment and we will start
our new session on May 2nd. A lot of preparation work to do before the
new group arrives.
Blessings and gratitude to all of you,
Christine Schuler Deschryver
V-Day Congo & City of Joy Director
RISING Blog Series Continued
http://action.vday.org/site/R?i=A7bjBVqnYY9ut_IWkxvqSQ
ONE BILLION RISING
by Purva Panday Cullman, Programs & Development Director
One Billion Rising was a unique experience for me. In the months
leading up to it I was part of the team planning and executing some of
the events and projects that helped build momentum for the campaign -
from our Africa Summit in Nairobi to the NYC Break The Chains flashmob
and video shoot, to helping to bring on diverse partners like the
Guerrilla Girls and the National Domestic Workers Alliance.
 The
hash tag faded in comparison to.
CONTINUE reading >
http://action.vday.org/site/R?i=Nw8o74e4d3p94bwwal1WFQ
http://action.vday.org/site/R?i=rzkUukEwkeiH1sn9ARGgGg
NYC RISING
by Rachel P. Goldstein, Regional Coordinator
One billion women and girls are raped, abused, or beaten in their
lifetime. That statistic was the driving force behind the efforts of
myself and my team as we passionately took on Eve Ensler and her One
Billion Rising campaign to stop this senselessness.
CONTINUE reading >
http://action.vday.org/site/R?i=HRySfzlprkr_tnp6Y0Yl_w
http://action.vday.org/site/R?i=PERvSpEyFOO1SuvjosqOxQ
http://action.vday.org/site/R?i=H9tlUSqdNRbUswVoVXj4Yg
http://action.vday.org/site/R?i=vXNmFATPv75BioxDbDTdfQ
http://action.vday.org/site/R?i=9Sm30M5wAnryYAESyKAJcA
http://action.vday.org/site/R?i=w6AVcazvmG7mWhqXmFqzMQ
unsubscribe
http://action.vday.org/site/CO?i=iLdzVSBM8xmyRMnhfVcuNfR0jERMAFuQ&cid=1062
Powered By Convio


Sub Plea Request Form
Campus:
Select Location
IUB
IUPUI
Location: (select all that apply)
CIB
LC
IMU
ICTC
CC
Shift Position: (select all that apply)
Phones/Chat/Email
Walk-in
Crimson Card
Carry-in
SA/Dispatcher/Project
Shift Start:
Shift End:
Username: (Check the box if you are a supervisor)
Comments:


Take a snapshot of the current video stream
Click on the Start WebCam button.
Start WebCam
Stop Webcam
Take Snapshot
Screenshots :


Books
The number after the book name stands for the year in which the book was
written in. All books are put in their respective category and are sorted
from oldest to newest. Emojis before the books show if the book is free or
not.
Contents
Algorithms
Architecture
Art
Autobiography
Awareness
Basic Income
Biographies
Biology
Business
Category theory
Chemistry
Compilers
Computational complexity
Computer graphics
Computer networking
Computer science
Computer Systems
Creativity
Cybernetics
Cryptography
Cryptocurrencies
Data Science
Databases
Design
The Best Interface Is No Interface: The Simple Path to Brilliant
Technology ## Drugs
Economics
Engineering
Evolution
Environment
Fiction
Adventure
Comedy
Fantasy
Fantasy series
Short Stories
Thriller
Film Making
Finance
Fitness
Functional programming
Future
Game Development
Graphic design
History
Alternative history
Investing
Kubernetes
Leadership
Logic
Machine learning
Management
Math
Memoirs
Mindset
Minimalism
Music production
Neuroscience
Non Fiction
Nutrition
Operating Systems
iOS
Linux
MacOS
Philosophy
Physics
Poetry
Politics
Programming interviews
Programming language design
Programming languages
Assembly
C
C++
D
Go
Clojure
Haskell
Java
JavaScript
Lisp
OCaml
Perl
Prolog
Purescript
Python
R
ReasonML
Ruby
Rust
Scala
Smalltalk
Swift
TypeScript
Agda
Programming
Psychedelics
Psychology
Quantum physics
Regular Expressions
Reinforcement learning
Reverse engineering
Science
Scifi
SciFi Series
Security
Sleep
Society
Spirituality
Startups
Statistics
Strategy
Text editors
Vim
Type theory
Unix
Version control
Git
Visualization
Writing
Web Development
CSS
Node
React
Redux
Webpack
Web design
Other


Preparation time
less than 30 mins
Cooking time
10 to 30 mins
Serves
Serves 4
Dietary
Make chocolate fondants extra indulgent with homemade caramel and chocolate sauce.
Preheat the oven to 220C/200C Fan/Gas 7. Grease 4 dariole (circular) moulds with butter.
For the fondants, melt the butter and chocolate in a bowl over a bain-marie, making sure the bowl doesn't touch the water. Leave to cool for 1 minute.
Meanwhile, whisk the eggs and sugar until they have doubled in size and are pale in colour. Pour the cooled chocolate mixture over the egg mixture (if you do this when it is too hot it will scramble the eggs). Sift in the flour, then carefully fold it in.
Quarter-fill the dariole moulds with the chocolate mixture. Drop a chocolate in each pot, then spoon the remaining chocolate mixture over the top, leaving a gap as they will rise. Bake for 5–6 minutes.
Meanwhile, for the caramel sauce, melt the butter in a medium saucepan and add the sugar. Cook until the sugar has dissolved. Add the cream and cook until you have a thick, glossy sauce.
For the chocolate sauce, bring 100ml/3½fl oz water to the boil in a medium saucepan. Add the chocolate and whisk until smooth. Add the butter and whisk to combine.
Drizzle the caramel and chocolate sauces around the fondants on individual dessert plates. Serve with the ice cream and chocolate mint.


Dear friend, I know you might have received letters like this from the internet and it came to you as a joke or game, but this is real and legal of which I need your urgent response to. I am Barrister ALEXANDER AFADIA a Solicitor. I am the Personal Attorney to Mr. Adams Kielar a national of your country who was an expartriate contractor in the Oil industry. On the 21st of April 2000, my client, his wife and their three children were involved in a car accident along Sagamu - Lagos express road. Unfortunately they all lost their lives in the event of the accident. Since then, I have made several enquiries to your Embassy to locate any of my clients extended relatives but this was unsuccessful. After several unsuccessful attempts, I decided to trace his relatives over the Internet to locate any member of his family but to no avail, hence I contacted you. I contacted you to assist in repartrating the money and property left behind by my client before they get confiscated or declared unserviceable by the Bank where this huge deposits were lodged. Particularly, the Bank where the deceased had an account valued at about US$35.5M. (thirty-five Million, Five Hundred Thousand United Stated Dollars) has issued me a notice to provide the next of kin or have the account confiscated. Since I have been unsuccesfull in locating the the relatives for over three years now, I seek your consent to present you as the next of kin of the deceased since you are from the same country so that the proceeds of this account valued at US$35.5M. can be paid to you and then we can share the money between us. 60% to me and 30% to you,while 10% should be for expenses and tax as your government may require. I have all necessary legal documents that can be used to back up any claim we may make. All I require is your honest co-operation to enable us see this deal through. I guarantee that this will be executed under a legitimate arrangement that will protect you from any breach of the law. Please reply immediately if you are interested to enable us discuss further. Yours faithfully, ALEXANDER AFADIA Esq. ____________________________________________________________ Charle con sus amigos online usando CHAT 123 http://www.123.com/sp/chat/section.php?id_section=329


Season :
Fetch Games
Game :
Name
Color
Category light
Category dark
200 pts
100 pts
0 pts
min
max
LIGHT
DARK
PB
SCORE
TIME
LIGHT
DARK
Display PB and category:
LIGHT
DARK
BOTH
HIDE
Chrono


This Is Me By Keala Settle The Greatest Showman Ensemble On Amazon Music Amazon Com
Pasek Paul This Is Me From The Greatest Showman Arr Mac Huff Sheet Music Pdf Notes Chords Film Tv Score 2 Part Choir Download Printable Sku 197938
This Is Me Justin Paul Choir Cd
J Lo This Is Me Cd Cd Covers Cover Century Over 500 000 Album Art Covers For Free
This Is Me From The Greatest Showman Hal Leonard Online
Charlee This Is Me 2010 Cd Discogs
Pasek Paul This Is Me From The Greatest Showman Arr Audrey Snyder Sheet Music Pdf Notes Chords Film Tv Score 2 Part Choir Download Printable Sku 403233
This Is Me From The Greatest Showman Satb Choir Arranged By Mac Huff Youtube
Melissa Etheridge Official Site
Cd Bouke This Is Me Shopelvismatters
Jennifer Lopez This Is Me Then Thecdexchange Com Music
Ayaka This Is Me Ayaka 10th Anniversary Best 3cds Japan Cd Akco 90045 Amazon Com Music
Jennifer Lopez This Is Me Then Cd Album De Jennifer Lopez This Is Me Then Cd Album Cd Chez Soul13 Ref 119445485
This Is Me Monrose Song Wikipedia
Jennifer Lopez This Is Me Then 2002 Cd Discogs
Audrey Snyder This Is Me From The Greatest Showman Singers Com
Cd Bouke This Is Me Shopelvismatters
Melissa Etheridge This Is M E Digi Spv Recordings Cd Grooves Land Playthek
Fyc 2017 Cd Promo Single This Is Me Greatest Showman Keala Settle Song Oscar Fox 8 99 Picclick
This Is Me Justin Paul Sheet Music For Mixed Choir
Jennifer Lopez This Is Me Then Made In Japan Obi Cd Epic 2002 Eicp 170 For Sale Online Ebay
Randy Travis This Is Me Amazon Com Music
Jennifer Lopez This Is Me Then Cd Album De Jennifer Lopez This Is Me Then Cd Album Cd Chez Soul13 Ref 119445485
Jennifer Lopez This Is Me Then Set Of Three Handbills Taiwanese Promo Handbill 529219
Jennifer Lopez This Is Me Then Cd Vinyl Pharmacy
Kierra Kiki Sheard This Is Me Gospel Cd 2006 Ebay
Signed Heather Peace This Is Me Cd Unavailable To Buy Elsewhere 306416475
Skylar Stecker This Is Me Cd Amoeba Music
This Is Me 絢香 Yama Chanのラベル工房
This Is Me Instrumental Karaoke Full Hq Download Youtube
Jennifer Lopez 2002 Album This Is Me Then Piled Music Cd Cases Stock Photo Alamy
Sealed Cd Jennifer Lopez This Is Me Then 2002 Epic Vinylbay777


Performing a bootstrap analysis with qtl2pleio
requires first sampling a (bivariate) phenotype from the inferred bivariate normal distribution, then a two-dimensional, two-QTL QTL scan over the defined scan region. Often, one wants to include more than 100 markers in a scan region. Each two-dimensional scan can take tens of minutes with a single core. Thus, performing a bootstrap analysis with, say, 1000 bootstrap samples is prohibitively time-consuming on most computers. For this reason, we used a high-throughput computing cluster at the University of Wisconsin-Madison (where qtl2pleio
was developed). The UW-Madison Center for High-Throughput Computing (CHTC) is available to all UW-Madison researchers. While we recognize that qtl2pleio
users may not have access to the CHTC, we anticipate that some will have access to computing clusters. Hopefully this vignette can be adapted to your needs.
We placed on github a repository that contains the results from our bootstrap analysis of the Recla data.
Here is the repository’s url: https://github.com/fboehm/qtl2pleio-manuscript-chtc/
Within this repo are three subdirectories. We’ll examine in detail the “Recla-bootstrap” subdirectory.
Within this directory, we created four subdirectories:
The Github repository also contains a fifth subdirectory, squid
and a sixth subdirectory results
, that are included for completeness. In practice, files in squid
were in a distinct directory. We describe it below.
Rscript
The Rscript
subdirectory contains a file, boot-Recla-10-22.R
that contains R code for our bootstrap analysis.
fn <- file.path("https://raw.githubusercontent.com",
"fboehm/qtl2pleio-manuscript/master/chtc",
"Recla-bootstrap/Rscript/boot-Recla-10-22.R"
)
foo <- readLines(fn)
Here we display the contents of our boot-Recla-10-22.R
file.
##
pleio_peak_index <- 788
##
library(qtl2pleio)
library(stringr)
library(dplyr)
library(readr)
args <- R.utils::commandArgs(trailingOnly = TRUE, asValues = TRUE)
# translate command line args
print(args)
print(args$argname)
(proc_num <- as.numeric(args$argname))
(run_num <- as.numeric(args$run_num))
(nboot_per_job <- args$nboot_per_job) # think 1 boot per job
(nsnp <- as.integer(args$nsnp))
(s1 <- as.integer(args$s1))
###############
library(qtl2)
recla <- readRDS("data/recla.rds")
# make sex a covariate for use in pvl_scan
recla[[6]][ , 1, drop = FALSE] -> sex
sex <- sex == "female"
# insert pseudomarkers
insert_pseudomarkers(recla, step = 0.1) -> pseudomap
## ------------------------------------------------------------------------
## ------------------------------------------------------------------------
pp <- readRDS("data/recla-aprobs-chr8.rds")
## ------------------------------------------------------------------------
kinship <- readRDS("data/recla-kinship.rds")
## ------------------------------------------------------------------------
recla$pheno -> ph
log(ph) -> lph
apply(FUN = broman::winsorize, X = lph, MARGIN = 2) -> wlph
## ------------------------------------------------------------------------
phe <- wlph[, c(10, 22)]
gm <- pseudomap$`8`
k <- kinship[[8]]
## ------------------------------------------------------------------------
library(qtl2pleio)
###############
# simulate a phenotype
X1 <- pp[ , , pleio_peak_index]
cbind(X1, unlist(sex)) -> Xpre
## remove subjects with missing values of phenotype
is.na(phe[ , 1]) | is.na(phe[ , 2]) -> missing_indic
phe_nona <- phe[!missing_indic, ]
Xpre_nona <- Xpre[!missing_indic, ]
k_nona <- k[!missing_indic, !missing_indic]
##
gemma2::stagger_mats(Xpre_nona, Xpre_nona) -> X
set.seed(proc_num)
calc_covs(pheno = phe_nona, kinship = k_nona) -> cc_out
(cc_out$Vg -> Vg)
(cc_out$Ve -> Ve)
# calculate Sigma
calc_Sigma(Vg = Vg, Ve = Ve, K = k_nona) -> Sigma
solve(Sigma) -> Sigma_inv
# calc Bhat
B <- calc_Bhat(X = X, Sigma_inv = Sigma_inv, Y = phe_nona)
# Start loop
lrt <- numeric()
for (i in 1:nboot_per_job){
sim1(X = X, B = B, Vg = Vg, Ve = Ve, kinship = k_nona) -> foo
matrix(foo, ncol = 2, byrow = FALSE) -> Ysim
rownames(Ysim) <- rownames(phe_nona)
colnames(Ysim) <- c("t1", "t2")
scan_pvl(probs = pp[!missing_indic, , ], pheno = Ysim, covariates = sex[!missing_indic, , drop = FALSE], kinship = k_nona, start_snp1 = s1, n_snp = nsnp) -> loglik
# in above call, s1 & nsnp come from command line args
calc_lrt_tib(loglik) -> lrt[i]
}
fn_out <- paste0("recla-boot-run", run_num, "_", proc_num, ".txt")
write.table(lrt, fn_out)
q("no")
data
The data subdirectory contains three rds files, one for each of the three input components.
shell_scripts
We examine only the file that is needed for the Recla analysis, boot-Recla-10-22.sh
.
Here is the contents of the file.
#!/bin/bash
# untar your R installation
tar -xzf R13.tar.gz
tar -xzf SLIBS.tar.gz
# make sure the script will use your R installation
export PATH=$(pwd)/R/bin:$PATH
export LD_LIBRARY_PATH=$(pwd)/SS:$LD_LIBRARY_PATH
# run R, with the name of your R script
R CMD BATCH '--args argname='$1' nsnp='$2' s1='$3' nboot_per_job='$4' run_num='$5'' Rscript/boot-Recla-10-22.R 'boot400_run'$5'-'$1'.Rout'
We need to unzip the R installation, which we’ve named R13.tar.gz, and SLIBS file on the remote computer where the actual computing will occur. Following that, and needed adjustments to the paths, we execute R. Note that we have, in this file, specified the variable values by numbers, like $1
for argname
. The values assigned to each of these is specified in the “submit” file.
submit_files
The HTCondor “submit” file provides instructions for controlling the interaction with the high-throughput resources. Below is the text in the submit file boot-Recla-10-22.sub
# hello-chtc.sub
# My very first HTCondor submit file
s1=650
# start scan at this SNP index value
nsnp=350
# length of scan in number of SNPs
# which run in the experimental design?
run_num=561
#
nboot_per_job=1
# for almost all jobs), the desired name of the HTCondor log file,
# and the desired name of the standard error file.
# Wherever you see $(Cluster), HTCondor will insert the queue number
# assigned to this set of jobs at the time of submission.
universe = vanilla
log = boot-$(Process)-run$(run_num).log
error = boot-$(Process)-run$(run_num).err
#
# Specify your executable (single binary or a script that runs several
# commands), arguments, and a files for HTCondor to store standard
# output (or "screen output").
# $(Process) will be a integer number for each job, starting with "0"
# and increasing for the relevant number of jobs.
executable = ../shell_scripts/boot-Recla-10-22.sh
arguments = $(Process) $(nsnp) $(s1) $(nboot_per_job) $(run_num)
output = boot-$(Process)-run$(run_num).out
#
# Specify that HTCondor should transfer files to and from the
# computer where each job runs. The last of these lines *would* be
when_to_transfer_output = ON_EXIT
transfer_input_files = ../data,../Rscript,../shell_scripts,http://proxy.chtc.wisc.edu/SQUID/fjboehm/R13.tar.gz,http://proxy.chtc.wisc.edu/SQUID/SLIBS.tar.gz
#
# Tell HTCondor what amount of compute resources
# each job will need on the computer where it runs.
request_cpus = 1
request_memory = 3GB
request_disk = 1GB
#
requirements = (OpSysMajorVer == 6) || (OpSysMajorVer == 7)
# which computer grids to use:
+WantFlocking = true
+WantGlideIn = true
# Tell HTCondor to run instances of our job:
queue 1000
The ordering of the arguments on in the line that starts with arguments =
dictates the numbers that are assigned to each argument. These numbers are used in the shell script, above.
SQUID
The UW-Madison CHTC provides for each user disk space on a web proxy. More information about SQUID
is available online.
In practice, we placed files containing founder allele dosages (for chromosomes of interest) and our (compressed) R installation on SQUID
.
We followed the usual procedure for submitting R jobs with the CHTC. To submit the file boot-Recla-10-22.sub
, we first changed into its directory. We then typed
By using this command from within the submit_files
subdirectory, we ensure that our outputted files are returned to the submit_files
subdirectory. We then manually moved the outputted results files to the results
subdirectory.
We found that up to ten percent of jobs would initially fail and require re-submission. There are a variety of reasons that may explain the need for re-submission. Because of this need, we include in the git repository the file boot-Recla-10-22-fix.sub
, which gives the code that we used for resubmission. The file bad-jobs-run561
gives the ids of the jobs that failed the initial runs.
## ─ Session info ───────────────────────────────────────────────────────────────
## setting value
## version R version 4.0.3 (2020-10-10)
## os Ubuntu 20.10
## system x86_64, linux-gnu
## ui X11
## language (EN)
## collate C
## ctype en_US.UTF-8
## tz America/New_York
## date 2020-12-01
##
## ─ Packages ───────────────────────────────────────────────────────────────────
## package * version date lib source
## assertthat 0.2.1 2019-03-21 [3] CRAN (R 4.0.0)
## callr 3.5.1 2020-10-13 [3] CRAN (R 4.0.3)
## cli 2.2.0 2020-11-20 [3] CRAN (R 4.0.3)
## crayon <IP_ADDRESS>00 2020-10-22 [3] Github (r-lib/crayon@6b3f0c6)
## desc 1.2.0 2018-05-01 [3] CRAN (R 4.0.0)
## devtools 2.3.2 2020-09-18 [3] CRAN (R 4.0.3)
## digest 0.6.27 2020-10-24 [3] CRAN (R 4.0.3)
## ellipsis 0.3.1 2020-05-15 [3] CRAN (R 4.0.0)
## evaluate 0.14 2019-05-28 [3] CRAN (R 4.0.0)
## fansi 0.4.1 2020-01-08 [3] CRAN (R 4.0.0)
## fs 1.5.0 2020-07-31 [3] CRAN (R 4.0.3)
## glue 1.4.2 2020-08-27 [3] CRAN (R 4.0.2)
## htmltools 0.5.0 2020-06-16 [3] CRAN (R 4.0.0)
## knitr 1.30 2020-09-22 [3] CRAN (R 4.0.3)
## magrittr 2.0.1 2020-11-17 [3] CRAN (R 4.0.3)
## memoise 1.1.0 2017-04-21 [3] CRAN (R 4.0.0)
## pkgbuild 1.1.0 2020-07-13 [3] CRAN (R 4.0.2)
## pkgload 1.1.0 2020-05-29 [3] CRAN (R 4.0.0)
## prettyunits 1.1.1 2020-01-24 [3] CRAN (R 4.0.0)
## processx 3.4.4 2020-09-03 [3] CRAN (R 4.0.3)
## ps 1.4.0 2020-10-07 [3] CRAN (R 4.0.3)
## R6 2.5.0 2020-10-28 [3] CRAN (R 4.0.3)
## remotes 2.2.0 2020-07-21 [3] CRAN (R 4.0.3)
## rlang 0.4.9 2020-11-26 [3] CRAN (R 4.0.3)
## rmarkdown 2.5 2020-10-21 [3] CRAN (R 4.0.3)
## rprojroot 2.0.2 2020-11-15 [3] CRAN (R 4.0.3)
## sessioninfo 1.1.1 2018-11-05 [3] CRAN (R 4.0.0)
## stringi 1.5.3 2020-09-09 [3] CRAN (R 4.0.2)
## stringr 1.4.0 2019-02-10 [3] CRAN (R 4.0.0)
## testthat 3.0.0 2020-10-31 [3] CRAN (R 4.0.3)
## usethis 1.6.3 2020-09-17 [3] CRAN (R 4.0.3)
## withr 2.3.0 2020-09-22 [3] CRAN (R 4.0.3)
## xfun 0.19 2020-10-30 [3] CRAN (R 4.0.3)
## yaml 2.2.1 2020-02-01 [3] CRAN (R 4.0.0)
##
## [1] /tmp/RtmpbYyM8o/Rinst8229dd84ff4f
## [2] /tmp/RtmpQ3N82V/temp_libpath803da596e6e5d
## [3] /home/fred/R/x86_64-pc-linux-gnu-library/4.0
## [4] /usr/local/lib/R/site-library
## [5] /usr/lib/R/site-library
## [6] /usr/lib/R/library


lucee.Component cbmongodb.models.BaseDocumentService
Core MongoDB Document Service
| Property Summary | ||||
|---|---|---|---|---|
| type | property | default | serializable | required |
any
|
_default_document
The container for the default document. |
true
|
false
|
|
any
|
_document
package container for the active document entity. |
true
|
false
|
|
any
|
_existing
package container for the loaded document before modifications. |
true
|
false
|
|
any
|
_id
The id of the loaded document. |
true
|
false
|
|
any
|
_indexes
The array which holds the ensured indexes.
|
true
|
false
|
|
any
|
_map
The schema map which will be persisted for validation and typing. |
true
|
false
|
|
any
|
_validation
Validation structure.
|
true
|
false
|
|
any
|
appSettings
The Coldbox Application Setttings Structure. |
true
|
false
|
|
any
|
collection
This key is maintained for backward compatibility but is marked as deprecated.
|
default
|
true
|
false
|
any
|
db
The database client w/o a specified collection. |
true
|
false
|
|
any
|
dbInstance
The instatiated database collection to perform operations on. |
true
|
false
|
|
any
|
logbox
The LogBox Logger for this Entity.
|
true
|
false
|
|
any
|
MongoClient
The MongoDB Client.
|
true
|
false
|
|
any
|
MongoUtil
The Mongo Utilities Library.
|
true
|
false
|
|
any
|
wirebox
The Application Wirebox IOC Instance.
|
true
|
false
|
| Constructor Summary | |
|---|---|
|
init()
Constructor. |
| Method Summary | |
|---|---|
any
|
applyIndex(any prop, [any properties='[runtime expression]'])
Create and apply our indexes. |
void
|
criteria([struct criteria])
UTILS ***************************************. |
any
|
delete(any _id)
Deletes a document by ID. |
any
|
detect()
Evaluate our properties for the default document. |
any
|
evict()
Evicts the document entity and clears the query arguments. |
any
|
get(any _id, [any returnInstance='true'])
Load a record by _id. |
string
|
get_default_document()
get: The container for the default document. |
string
|
get_document()
get: package container for the active document entity. |
string
|
get_existing()
get: package container for the loaded document before modifications. |
string
|
get_id()
get: The id of the loaded document. |
string
|
get_indexes()
get: The array which holds the ensured indexes. |
string
|
get_map()
get: The schema map which will be persisted for validation and typing. |
string
|
get_validation()
get: Validation structure. |
string
|
getAppSettings()
get: The Coldbox Application Setttings Structure. |
string
|
getCollection()
get: This key is maintained for backward compatibility but is marked as deprecated. |
any
|
getCollectionObject()
Returns the Mongo. |
string
|
getDb()
get: The database client w/o a specified collection. |
string
|
getDbInstance()
get: The instatiated database collection to perform operations on. |
any
|
getIndexInfo()
|
string
|
getLogbox()
get: The LogBox Logger for this Entity. |
string
|
getMongoClient()
get: The MongoDB Client. |
string
|
getMongoUtil()
get: The Mongo Utilities Library. |
any
|
getPropertyDefault([any prop])
Returns the default property value. |
string
|
getWirebox()
get: The Application Wirebox IOC Instance. |
any
|
indexExists(any name)
Returns whether the index exists. |
any
|
indexOrder(any prop)
Returns the index sort option. |
any
|
load(any _id, [any returnInstance='true'])
Alias for get(). |
any
|
locate([string key])
Helper function to locate deeply nested document items. |
numeric
|
mapOrder(any order)
The SQL to Mongo translated ordering statements. |
any
|
populate(struct document)
Populate the document object with a structure. |
any
|
reset()
reset the document state. |
any
|
set(any key, any value)
Sets a document property. |
any
|
set_default_document(any _default_document)
set: The container for the default document. |
any
|
set_document(any _document)
set: package container for the active document entity. |
any
|
set_existing(any _existing)
set: package container for the loaded document before modifications. |
any
|
set_id(any _id)
set: The id of the loaded document. |
any
|
set_indexes(any _indexes)
set: The array which holds the ensured indexes. |
any
|
set_map(any _map)
set: The schema map which will be persisted for validation and typing. |
any
|
set_validation(any _validation)
set: Validation structure. |
any
|
setAppSettings(any appSettings)
set: The Coldbox Application Setttings Structure. |
any
|
setCollection(any collection)
set: This key is maintained for backward compatibility but is marked as deprecated. |
any
|
setDb(any db)
set: The database client w/o a specified collection. |
any
|
setDbInstance(any dbInstance)
set: The instatiated database collection to perform operations on. |
any
|
setLogbox(any logbox)
set: The LogBox Logger for this Entity. |
any
|
setMongoClient(any MongoClient)
set: The MongoDB Client. |
any
|
setMongoUtil(any MongoUtil)
set: The Mongo Utilities Library. |
any
|
setWirebox(any wirebox)
set: The Application Wirebox IOC Instance. |
any
|
toGeoJSON([array coordinates], [string type='Point'])
Handles correct formatting of geoJSON objects. |
any
|
toMongo(any arg)
facade for Mongo. |
any
|
toMongoDocument(struct arg)
facade for Mongo. |
| Methods inherited from class lucee.Component |
|---|
| None |
| Constructor Detail |
|---|
Constructor
| Property Detail |
|---|
The container for the default document
required
- falseserializable
- truepackage container for the active document entity
required
- falseserializable
- truepackage container for the loaded document before modifications
required
- falseserializable
- trueThe id of the loaded document
required
- falseserializable
- trueThe array which holds the ensured indexes.
required
- falseexample
- property name="myfield" schema=true index=true;serializable
- trueThe schema map which will be persisted for validation and typing
required
- falseserializable
- trueValidation structure
required
- falseexample
- property name="myfield" schema=true validate="string";serializable
- trueThe Coldbox Application Setttings Structure
required
- falseserializable
- trueThis key is maintained for backward compatibility but is marked as deprecated. You should use the component attribute method to declare your collection name.
required
- falsedeprecated
- trueserializable
- trueThe database client w/o a specified collection
required
- falseserializable
- trueThe instatiated database collection to perform operations on
required
- falseserializable
- trueThe LogBox Logger for this Entity
required
- falseinject
- logbox:logger:{this}serializable
- trueThe MongoDB Client
required
- falseinject
- MongoClient@cbmongodbserializable
- trueThe Mongo Utilities Library
required
- falseinject
- MongoUtil@cbmongodbserializable
- trueThe Application Wirebox IOC Instance
required
- falseinject
- wireboxserializable
- true| Method Detail |
|---|
Create and apply our indexes
prop
properties
UTILS ***************************************
criteria
Deletes a document by ID
_id
Evaluate our properties for the default document
Evicts the document entity and clears the query arguments
Load a record by _id
_id
returnInstance
get: The container for the default document
get: package container for the active document entity
get: package container for the loaded document before modifications
get: The id of the loaded document
get: The array which holds the ensured indexes.
get: The schema map which will be persisted for validation and typing
get: Validation structure
get: The Coldbox Application Setttings Structure
get: This key is maintained for backward compatibility but is marked as deprecated. You should use the component attribute method to declare your collection name.
Returns the Mongo.Collection object for advanced operations facade for getDBInstance()
get: The database client w/o a specified collection
get: The instatiated database collection to perform operations on
get: The LogBox Logger for this Entity
get: The MongoDB Client
get: The Mongo Utilities Library
Returns the default property value Used to populate the document defaults
prop
get: The Application Wirebox IOC Instance
Returns whether the index exists
name
Returns the index sort option
prop
Alias for get()
_id
returnInstance
Helper function to locate deeply nested document items
key
The SQL to Mongo translated ordering statements
order
Populate the document object with a structure
document
reset the document state
Sets a document property
key
value
set: The container for the default document
_default_document
set: package container for the active document entity
_document
set: package container for the loaded document before modifications
_existing
set: The id of the loaded document
_id
set: The array which holds the ensured indexes.
_indexes
set: The schema map which will be persisted for validation and typing
_map
set: Validation structure
_validation
set: The Coldbox Application Setttings Structure
appSettings
set: This key is maintained for backward compatibility but is marked as deprecated. You should use the component attribute method to declare your collection name.
collection
set: The database client w/o a specified collection
db
set: The instatiated database collection to perform operations on
dbInstance
set: The LogBox Logger for this Entity
logbox
set: The MongoDB Client
MongoClient
set: The Mongo Utilities Library
MongoUtil
set: The Application Wirebox IOC Instance
wirebox
Handles correct formatting of geoJSON objects
coordinates
type
facade for Mongo.Util.toMongo
arg
facade for Mongo.Util.toMongoDocument
arg


{% extends "splunkdj:base_with_app_bar.html" %} {% load splunkmvc %} {% load splunk_wftoolkit %} {% block title %}Complex Dashboard with Drilldown - Web Framework Toolkit{% endblock title %} {% block css %} {% endblock css %} {% block content %}
This dashboard displays airline data for a selected city, and demonstrates drilldown actions, events, and token binding. When you select a different city, all the searches on this page are updated to display data for it.
Select a carrier to view details:


Click a button to show results. Click a second for comparison next to the first (buggish-but useful).
Relaxation parameters and results of single-point calculation are here :
https://github.com/djeanner/mnova_fullnoe/blob/master/examples/web/results.txt
Click a button to show results. Click a second for comparison next to the first (buggish-but useful).
Last called


--- title: Textbook error 101 -- A low p-value for the full model does not mean that the model is a good predictor of the response author: Jeff Walker date: '2018-09-11' slug: a-low-p-value-for-the-full-model-does-not-mean-that-the-model-is-a-good-predictor-of-the-response categories: - stats 101 tags: - regression - model-averaged predictions - p-values ---
On page 606, of Lock et al “Statistics: Unlocking the Power of Data”, the authors state in item D “The p-value from the ANOVA table is 0.000 so the model as a whole is effective at predicting grade point average.” Ah no.
library(data.table)
library(mvtnorm)
rho <- 0.5
n <- 10^5
Sigma <- diag(2)
Sigma[1,2] <- Sigma[2,1] <- rho
X <- rmvnorm(n, mean=c(0,0), sigma=Sigma)
colnames(X) <- c("X1", "X2")
beta <- c(0.01, -0.02)
y <- X%*%beta + rnorm(n)
fit <- lm(y ~ X)
summary(fit)
##
## Call:
## lm(formula = y ~ X)
##
## Residuals:
## Min 1Q Median 3Q Max
## -3.9651 -0.6744 0.0001 0.6698 4.3915
##
## Coefficients:
## Estimate Std. Error t value Pr(>|t|)
## (Intercept) -0.006111 0.003164 -1.932 0.0534 .
## XX1 0.006337 0.003644 1.739 0.0820 .
## XX2 -0.021513 0.003658 -5.881 4.09e-09 ***
## ---
## Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
##
## Residual standard error: 1 on 99997 degrees of freedom
## Multiple R-squared: 0.0003649, Adjusted R-squared: 0.0003449
## F-statistic: 18.25 on 2 and 99997 DF, p-value: 1.191e-08
A p-value is not a measure of the predictive capacity of a model because the p-value is a function of 1) signal, 2) noise (unmodeled error), and 3) sample size while predictive capacity is a function of the signal:noise ratio. If the signal:noise ratio is tiny, the predictive capacity is small but the p-value can be tiny if the sample size is large.


>
14 year old programmer who is learning html
Hi, my name is Alex, I am an incoming 9th grader who is learning to code in html.
Bottom 4%


Page not working yet!
Please be patient as technicians are working hard to make the page functional.
Take me back to the Home Page
In the mean time, please enjoy this funny cat photo.
https://www.pinterest.ca/pin/339388521916878635/


My Todo App
✕
+
Projects
Name:
Create project
+
To-do List
Title:
Details:
Due Date:
Priority
Low
Normal
High
Submit


HTML Version
Irirs
Title
App
Edit
Connect
New
Open
Import
Export
New
Open
Save
Save As
Text
Open
Save
Save As
Save
Open
Save
Save As
Save
Save
Open
Save
Save As
Save
Save
Save
Save
Save As
Save
Save
Content Goes Here


In January 2010, Yale’s Center for Media and Instructional Innovation conducted a survey of mobile devices used to access Classes*v2, the University’s learning management system built on the open-source Sakai platform. The results of this survey and a series of related discussions prompted further development, and in 2011 the Classes*v2 team completed an alpha version of a mobile web interface. A decision was made to open it up to a select group of pilot participants during the Spring 2012 semester. Our goal was to gather student and faculty feedback to inform ongoing development efforts. With no formal usability training, but plenty of gritty do-it-yourself determination, the team set about conducting a large-scale usability study.
The process of selecting and gathering feedback from the pilot participants was a multi-phased approach:
Upon logging into Classes*v2, a message invited interested users to apply to be part of the pilot.
Pilot applications simply required the user’s identity as well as which Classes*v2 tools they used regularly. Since the alpha version of the mobile web interface only worked with some tools, the team wanted to ensure a good fit between these parameters and the usage habits of potential pilot participants.
We sent accepted pilot participants an introductory email:
“Thanks for your interest in the Classes*v2 mobile pilot. As a first step in optimizing Classes*v2 for mobile devices, we invite your feedback on an alpha release, which includes views of several key tools.
To access the mobile view, please visit https://the.alpha.url
We’ll be sending you a quick survey in several weeks to learn about your experience. Your input on what works, what’s missing, and what needs to be tweaked will be incredibly helpful as we continue building the mobile view.
We appreciate your participation in the alpha pilot and look forward to your feedback.”
After the month-long pilot period ended, we sent participants a survey about their experience. Out of 648 participants, 220 (34%) responded to the survey.
“Thank you for your participation in the pilot of the Classes*v2 mobile alpha. Please take a few minutes to complete a quick survey on your experience with the pilot. We’re grateful for the feedback, and confident that it will help us further develop and improve the interface.”
(The final survey was individualized for tracking responses.)
Here are the results of the survey, if you’re curious. Included are some lessons learned and signposts that we used to prioritize development efforts.


The OCI8AutoRecover class enhances the OCI8 driver with auto-recover and reset functionality. If a call to exec fails, and autocommit is turned on (ie., we’re not in the middle of a longer transaction), it will automatically reconnect and try again. If autocommit is turned off, this would be dangerous (as the earlier part of the implied transaction may have failed silently if the connection died) — so instead the connection is marked as dead, to be reconnected on it’s next use.
| LOST_CONNECTION_ERROR_CODES | = | [ 28, 1012, 3113, 3114 ] |
| ORA-00028: your session has been killed ORA-01012: not logged on ORA-03113: end-of-file on communication channel ORA-03114: not connected to ORACLE |
| [RW] | active |
[ show source ]
# File vendor/rails/activerecord/lib/active_record/connection_adapters/oracle_adapter.rb, line 594 594: def initialize(config, factory = OracleConnectionFactory.new) 595: @active = true 596: @username, @password, @database = config[:username], config[:password], config[:database] 597: @factory = factory 598: @connection = @factory.new_connection @username, @password, @database 599: super @connection 600: end
Adds auto-recovery functionality.
[ show source ]
# File vendor/rails/activerecord/lib/active_record/connection_adapters/oracle_adapter.rb, line 635 635: def exec(sql, *bindvars) 636: should_retry = self.class.auto_retry? && autocommit? 637: 638: begin 639: @connection.exec(sql, *bindvars) 640: rescue OCIException => e 641: raise unless LOST_CONNECTION_ERROR_CODES.include?(e.code) 642: @active = false 643: raise unless should_retry 644: should_retry = false 645: reset! rescue nil 646: retry 647: end 648: end
Checks connection, returns true if active. Note that ping actively checks the connection, while active? simply returns the last known state.
[ show source ]
# File vendor/rails/activerecord/lib/active_record/connection_adapters/oracle_adapter.rb, line 605 605: def ping 606: @connection.exec("select 1 from dual") { |r| nil } 607: @active = true 608: rescue 609: @active = false 610: raise 611: end
Resets connection, by logging off and creating a new connection.
[ show source ]
# File vendor/rails/activerecord/lib/active_record/connection_adapters/oracle_adapter.rb, line 614 614: def reset! 615: logoff rescue nil 616: begin 617: @connection = @factory.new_connection @username, @password, @database 618: __setobj__ @connection 619: @active = true 620: rescue 621: @active = false 622: raise 623: end 624: end


The StandardDeviationExecutionModel
seeks to fill orders when the price is more than 2 standard deviations lower than the average price over a trailing period. The intent is to find dips in the market to place trades. In strongly trending markets, this procedure can result in delayed trade placement since it might be a while before the next price spike or dip.
SetExecution(new StandardDeviationExecutionModel());
self.SetExecution(StandardDeviationExecutionModel())
The following table describes the arguments the model accepts:
| Argument | Data Type | Description | Default Value |
|---|---|---|---|
period |
decimal float |
Period of the standard deviation indicator | 60 |
deviations |
int |
The number of deviations away from the mean before submitting an order | 2 |
resolution |
Resolution |
The resolution of the STD and SMA indicators | Resolution.Minute |
To view the implementation of this model, see the LEAN GitHub repositoryLEAN GitHub repository.