prctl - operations on a process
#include <sys/prctl.h>
int prctl(int option, unsigned long arg2, unsigned long arg3,
unsigned long arg4, unsigned long arg5);
prctl() is called with a first argument describing what to do (with
values defined in <linux/prctl.h>), and further arguments with a
significance depending on the first one. The first argument can be:
- PR_CAP_AMBIENT (since Linux 4.3)
- Reads or changes the ambient capability set of the calling thread,
according to the value of arg2, which must be one of the
following:
- PR_CAP_AMBIENT_RAISE
- The capability specified in arg3 is added to the ambient set. The
specified capability must already be present in both the permitted and the
inheritable sets of the process. This operation is not permitted if the
SECBIT_NO_CAP_AMBIENT_RAISE securebit is set.
- PR_CAP_AMBIENT_LOWER
- The capability specified in arg3 is removed from the ambient
set.
- PR_CAP_AMBIENT_IS_SET
- The prctl() call returns 1 if the capability in arg3 is in
the ambient set and 0 if it is not.
- PR_CAP_AMBIENT_CLEAR_ALL
- All capabilities will be removed from the ambient set. This operation
requires setting arg3 to zero.
- In all of the above operations, arg4 and arg5 must be
specified as 0.
- Higher-level interfaces layered on top of the above operations are
provided in the libcap(3) library in the form of
cap_get_ambient(3), cap_set_ambient(3), and
cap_reset_ambient(3).
- PR_CAPBSET_READ (since Linux 2.6.25)
- Return (as the function result) 1 if the capability specified in
arg2 is in the calling thread's capability bounding set, or 0 if it
is not. (The capability constants are defined in
<linux/capability.h>.) The capability bounding set dictates
whether the process can receive the capability through a file's permitted
capability set on a subsequent call to execve(2).
- If the capability specified in arg2 is not valid, then the call
fails with the error EINVAL.
- A higher-level interface layered on top of this operation is provided in
the libcap(3) library in the form of cap_get_bound(3).
- PR_CAPBSET_DROP (since Linux 2.6.25)
- If the calling thread has the CAP_SETPCAP capability within its
user namespace, then drop the capability specified by arg2 from the
calling thread's capability bounding set. Any children of the calling
thread will inherit the newly reduced bounding set.
- The call fails with the error: EPERM if the calling thread does not
have the CAP_SETPCAP; EINVAL if arg2 does not
represent a valid capability; or EINVAL if file capabilities are
not enabled in the kernel, in which case bounding sets are not
supported.
- A higher-level interface layered on top of this operation is provided in
the libcap(3) library in the form of cap_drop_bound(3).
- PR_SET_CHILD_SUBREAPER (since Linux 3.4)
- If arg2 is nonzero, set the "child subreaper" attribute
of the calling process; if arg2 is zero, unset the attribute.
- A subreaper fulfills the role of init(1) for its descendant
processes. When a process becomes orphaned (i.e., its immediate parent
terminates), then that process will be reparented to the nearest still
living ancestor subreaper. Subsequently, calls to getppid() in the
orphaned process will now return the PID of the subreaper process, and
when the orphan terminates, it is the subreaper process that will receive
a SIGCHLD signal and will be able to wait(2) on the process
to discover its termination status.
- The setting of the "child subreaper" attribute is not inherited
by children created by fork(2) and clone(2). The setting is
preserved across execve(2).
- Establishing a subreaper process is useful in session management
frameworks where a hierarchical group of processes is managed by a
subreaper process that needs to be informed when one of the
processes—for example, a double-forked daemon—terminates
(perhaps so that it can restart that process). Some init(1)
frameworks (e.g., systemd(1)) employ a subreaper process for
similar reasons.
- PR_GET_CHILD_SUBREAPER (since Linux 3.4)
- Return the "child subreaper" setting of the caller, in the
location pointed to by (int *) arg2.
- PR_SET_DUMPABLE (since Linux 2.3.20)
- Set the state of the "dumpable" flag, which determines whether
core dumps are produced for the calling process upon delivery of a signal
whose default behavior is to produce a core dump.
- In kernels up to and including 2.6.12, arg2 must be either 0
(SUID_DUMP_DISABLE, process is not dumpable) or 1
(SUID_DUMP_USER, process is dumpable). Between kernels 2.6.13 and
2.6.17, the value 2 was also permitted, which caused any binary which
normally would not be dumped to be dumped readable by root only; for
security reasons, this feature has been removed. (See also the description
of /proc/sys/fs/suid_dumpable in proc(5).)
- Normally, this flag is set to 1. However, it is reset to the current value
contained in the file /proc/sys/fs/suid_dumpable (which by default
has the value 0), in the following circumstances:
- The process's effective user or group ID is changed.
- The process's filesystem user or group ID is changed (see
credentials(7)).
- The process executes (execve(2)) a set-user-ID or set-group-ID
program, resulting in a change of either the effective user ID or the
effective group ID.
- The process executes (execve(2)) a program that has file
capabilities (see capabilities(7)), but only if the permitted
capabilities gained exceed those already permitted for the process.
- Processes that are not dumpable can not be attached via ptrace(2)
PTRACE_ATTACH; see ptrace(2) for further details.
- If a process is not dumpable, the ownership of files in the process's
/proc/[pid] directory is affected as described in
proc(5).
- PR_GET_DUMPABLE (since Linux 2.3.20)
- Return (as the function result) the current state of the calling process's
dumpable flag.
- PR_SET_ENDIAN (since Linux 2.6.18, PowerPC only)
- Set the endian-ness of the calling process to the value given in
arg2, which should be one of the following: PR_ENDIAN_BIG,
PR_ENDIAN_LITTLE, or PR_ENDIAN_PPC_LITTLE (PowerPC pseudo
little endian).
- PR_GET_ENDIAN (since Linux 2.6.18, PowerPC only)
- Return the endian-ness of the calling process, in the location pointed to
by (int *) arg2.
- PR_SET_FP_MODE (since Linux 4.0, only on MIPS)
- On the MIPS architecture, user-space code can be built using an ABI which
permits linking with code that has more restrictive floating-point (FP)
requirements. For example, user-space code may be built to target the O32
FPXX ABI and linked with code built for either one of the more restrictive
FP32 or FP64 ABIs. When more restrictive code is linked in, the overall
requirement for the process is to use the more restrictive floating-point
mode.
- Because the kernel has no means of knowing in advance which mode the
process should be executed in, and because these restrictions can change
over the lifetime of the process, the PR_SET_FP_MODE operation is
provided to allow control of the floating-point mode from user space.
- The (unsigned int) arg2 argument is a bit mask describing the
floating-point mode used:
- PR_FP_MODE_FR
- When this bit is unset (so called FR=0 or FR0 mode),
the 32 floating-point registers are 32 bits wide, and 64-bit registers are
represented as a pair of registers (even- and odd- numbered, with the
even-numbered register containing the lower 32 bits, and the odd-numbered
register containing the higher 32 bits).
- When this bit is set (on supported hardware), the 32 floating-point
registers are 64 bits wide (so called FR=1 or FR1 mode).
Note that modern MIPS implementations (MIPS R6 and newer) support
FR=1 mode only.
- Applications that use the O32 FP32 ABI can operate only when this bit is
unset (FR=0; or they can be used with FRE enabled, see
below). Applications that use the O32 FP64 ABI (and the O32 FP64A ABI,
which exists to provide the ability to operate with existing FP32 code;
see below) can operate only when this bit is set (FR=1).
Applications that use the O32 FPXX ABI can operate with either FR=0
or FR=1.
- PR_FP_MODE_FRE
- Enable emulation of 32-bit floating-point mode. When this mode is enabled,
it emulates 32-bit floating-point operations by raising a
reserved-instruction exception on every instruction that uses 32-bit
formats and the kernel then handles the instruction in software. (The
problem lies in the discrepancy of handling odd-numbered registers which
are the high 32 bits of 64-bit registers with even numbers in FR=0
mode and the lower 32-bit parts of odd-numbered 64-bit registers in
FR=1 mode.) Enabling this bit is necessary when code with the O32
FP32 ABI should operate with code with compatible the O32 FPXX or O32
FP64A ABIs (which require FR=1 FPU mode) or when it is executed on
newer hardware (MIPS R6 onwards) which lacks FR=0 mode support when
a binary with the FP32 ABI is used.
- Note that this mode makes sense only when the FPU is in 64-bit mode
(FR=1).
- Note that the use of emulation inherently has a significant performance
hit and should be avoided if possible.
- In the N32/N64 ABI, 64-bit floating-point mode is always used, so FPU
emulation is not required and the FPU always operates in FR=1
mode.
- This option is mainly intended for use by the dynamic linker
(ld.so(8)).
- The arguments arg3, arg4, and arg5 are ignored.
- PR_GET_FP_MODE (since Linux 4.0, only on MIPS)
- Return (as the function result) the current floating-point mode (see the
description of PR_SET_FP_MODE for details).
- On success, the call returns a bit mask which represents the current
floating-point mode.
- The arguments arg2, arg3, arg4, and arg5 are
ignored.
- PR_SET_FPEMU (since Linux 2.4.18, 2.5.9, only on ia64)
- Set floating-point emulation control bits to arg2. Pass
PR_FPEMU_NOPRINT to silently emulate floating-point operation
accesses, or PR_FPEMU_SIGFPE to not emulate floating-point
operations and send SIGFPE instead.
- PR_GET_FPEMU (since Linux 2.4.18, 2.5.9, only on ia64)
- Return floating-point emulation control bits, in the location pointed to
by (int *) arg2.
- PR_SET_FPEXC (since Linux 2.4.21, 2.5.32, only on PowerPC)
- Set floating-point exception mode to arg2. Pass
PR_FP_EXC_SW_ENABLE to use FPEXC for FP exception enables,
PR_FP_EXC_DIV for floating-point divide by zero,
PR_FP_EXC_OVF for floating-point overflow, PR_FP_EXC_UND for
floating-point underflow, PR_FP_EXC_RES for floating-point inexact
result, PR_FP_EXC_INV for floating-point invalid operation,
PR_FP_EXC_DISABLED for FP exceptions disabled,
PR_FP_EXC_NONRECOV for async nonrecoverable exception mode,
PR_FP_EXC_ASYNC for async recoverable exception mode,
PR_FP_EXC_PRECISE for precise exception mode.
- PR_GET_FPEXC (since Linux 2.4.21, 2.5.32, only on PowerPC)
- Return floating-point exception mode, in the location pointed to by
(int *) arg2.
- PR_SET_KEEPCAPS (since Linux 2.2.18)
- Set the state of the calling thread's "keep capabilities" flag.
The effect of this flag is described in capabilities(7).
arg2 must be either 0 (clear the flag) or 1 (set the flag). The
"keep capabilities" value will be reset to 0 on subsequent calls
to execve(2).
- PR_GET_KEEPCAPS (since Linux 2.2.18)
- Return (as the function result) the current state of the calling thread's
"keep capabilities" flag. See capabilities(7) for a
description of this flag.
- PR_MCE_KILL (since Linux 2.6.32)
- Set the machine check memory corruption kill policy for the calling
thread. If arg2 is PR_MCE_KILL_CLEAR, clear the thread
memory corruption kill policy and use the system-wide default. (The
system-wide default is defined by
/proc/sys/vm/memory_failure_early_kill; see proc(5).) If
arg2 is PR_MCE_KILL_SET, use a thread-specific memory
corruption kill policy. In this case, arg3 defines whether the
policy is early kill (PR_MCE_KILL_EARLY), late kill
(PR_MCE_KILL_LATE), or the system-wide default
(PR_MCE_KILL_DEFAULT). Early kill means that the thread receives a
SIGBUS signal as soon as hardware memory corruption is detected
inside its address space. In late kill mode, the process is killed only
when it accesses a corrupted page. See sigaction(2) for more
information on the SIGBUS signal. The policy is inherited by
children. The remaining unused prctl() arguments must be zero for
future compatibility.
- PR_MCE_KILL_GET (since Linux 2.6.32)
- Return (as the function result) the current per-process machine check kill
policy. All unused prctl() arguments must be zero.
- PR_SET_MM (since Linux 3.3)
- Modify certain kernel memory map descriptor fields of the calling process.
Usually these fields are set by the kernel and dynamic loader (see
ld.so(8) for more information) and a regular application should not
use this feature. However, there are cases, such as self-modifying
programs, where a program might find it useful to change its own memory
map.
- The calling process must have the CAP_SYS_RESOURCE capability. The
value in arg2 is one of the options below, while arg3
provides a new value for the option. The arg4 and arg5
arguments must be zero if unused.
- Before Linux 3.10, this feature is available only if the kernel is built
with the CONFIG_CHECKPOINT_RESTORE option enabled.
- PR_SET_MM_START_CODE
- Set the address above which the program text can run. The corresponding
memory area must be readable and executable, but not writable or shareable
(see mprotect(2) and mmap(2) for more information).
- PR_SET_MM_END_CODE
- Set the address below which the program text can run. The corresponding
memory area must be readable and executable, but not writable or
shareable.
- PR_SET_MM_START_DATA
- Set the address above which initialized and uninitialized (bss) data are
placed. The corresponding memory area must be readable and writable, but
not executable or shareable.
- PR_SET_MM_END_DATA
- Set the address below which initialized and uninitialized (bss) data are
placed. The corresponding memory area must be readable and writable, but
not executable or shareable.
- PR_SET_MM_START_STACK
- Set the start address of the stack. The corresponding memory area must be
readable and writable.
- PR_SET_MM_START_BRK
- Set the address above which the program heap can be expanded with
brk(2) call. The address must be greater than the ending address of
the current program data segment. In addition, the combined size of the
resulting heap and the size of the data segment can't exceed the
RLIMIT_DATA resource limit (see setrlimit(2)).
- PR_SET_MM_BRK
- Set the current brk(2) value. The requirements for the address are
the same as for the PR_SET_MM_START_BRK option.
The following options are available since Linux 3.5.
- PR_SET_MM_ARG_START
- Set the address above which the program command line is placed.
- PR_SET_MM_ARG_END
- Set the address below which the program command line is placed.
- PR_SET_MM_ENV_START
- Set the address above which the program environment is placed.
- PR_SET_MM_ENV_END
- Set the address below which the program environment is placed.
- The address passed with PR_SET_MM_ARG_START,
PR_SET_MM_ARG_END, PR_SET_MM_ENV_START, and
PR_SET_MM_ENV_END should belong to a process stack area. Thus, the
corresponding memory area must be readable, writable, and (depending on
the kernel configuration) have the MAP_GROWSDOWN attribute set (see
mmap(2)).
- PR_SET_MM_AUXV
- Set a new auxiliary vector. The arg3 argument should provide the
address of the vector. The arg4 is the size of the vector.
- PR_SET_MM_EXE_FILE
- Supersede the /proc/pid/exe symbolic link with a new one pointing
to a new executable file identified by the file descriptor provided in
arg3 argument. The file descriptor should be obtained with a
regular open(2) call.
- To change the symbolic link, one needs to unmap all existing executable
memory areas, including those created by the kernel itself (for example
the kernel usually creates at least one executable memory area for the ELF
.text section).
- In Linux 4.9 and earlier, the PR_SET_MM_EXE_FILE operation can be
performed only once in a process's lifetime; attempting to perform the
operation a second time results in the error EPERM. This
restriction was enforced for security reasons that were subsequently
deemed specious, and the restriction was removed in Linux 4.10 because
some user-space applications needed to perform this operation more than
once.
The following options are available since Linux 3.18.
- PR_SET_MM_MAP
- Provides one-shot access to all the addresses by passing in a struct
prctl_mm_map (as defined in <linux/prctl.h>). The
arg4 argument should provide the size of the struct.
- This feature is available only if the kernel is built with the
CONFIG_CHECKPOINT_RESTORE option enabled.
- PR_SET_MM_MAP_SIZE
- Returns the size of the struct prctl_mm_map the kernel expects.
This allows user space to find a compatible struct. The arg4
argument should be a pointer to an unsigned int.
- This feature is available only if the kernel is built with the
CONFIG_CHECKPOINT_RESTORE option enabled.
- PR_MPX_ENABLE_MANAGEMENT, PR_MPX_DISABLE_MANAGEMENT (since
Linux 3.19)
- Enable or disable kernel management of Memory Protection eXtensions (MPX)
bounds tables. The arg2, arg3, arg4, and arg5
arguments must be zero.
- MPX is a hardware-assisted mechanism for performing bounds checking on
pointers. It consists of a set of registers storing bounds information and
a set of special instruction prefixes that tell the CPU on which
instructions it should do bounds enforcement. There is a limited number of
these registers and when there are more pointers than registers, their
contents must be "spilled" into a set of tables. These tables
are called "bounds tables" and the MPX prctl() operations
control whether the kernel manages their allocation and freeing.
- When management is enabled, the kernel will take over allocation and
freeing of the bounds tables. It does this by trapping the #BR exceptions
that result at first use of missing bounds tables and instead of
delivering the exception to user space, it allocates the table and
populates the bounds directory with the location of the new table. For
freeing, the kernel checks to see if bounds tables are present for memory
which is not allocated, and frees them if so.
- Before enabling MPX management using PR_MPX_ENABLE_MANAGEMENT, the
application must first have allocated a user-space buffer for the bounds
directory and placed the location of that directory in the bndcfgu
register.
- These calls fail if the CPU or kernel does not support MPX. Kernel support
for MPX is enabled via the CONFIG_X86_INTEL_MPX configuration
option. You can check whether the CPU supports MPX by looking for the
'mpx' CPUID bit, like with the following command:
-
cat /proc/cpuinfo | grep ' mpx '
- A thread may not switch in or out of long (64-bit) mode while MPX is
enabled.
- All threads in a process are affected by these calls.
- The child of a fork(2) inherits the state of MPX management. During
execve(2), MPX management is reset to a state as if
PR_MPX_DISABLE_MANAGEMENT had been called.
- For further information on Intel MPX, see the kernel source file
Documentation/x86/intel_mpx.txt.
- PR_SET_NAME (since Linux 2.6.9)
- Set the name of the calling thread, using the value in the location
pointed to by (char *) arg2. The name can be up to 16 bytes
long, including the terminating null byte. (If the length of the string,
including the terminating null byte, exceeds 16 bytes, the string is
silently truncated.) This is the same attribute that can be set via
pthread_setname_np(3) and retrieved using
pthread_getname_np(3). The attribute is likewise accessible via
/proc/self/task/[tid]/comm, where tid is the name of the
calling thread.
- PR_GET_NAME (since Linux 2.6.11)
- Return the name of the calling thread, in the buffer pointed to by
(char *) arg2. The buffer should allow space for up to 16
bytes; the returned string will be null-terminated.
- PR_SET_NO_NEW_PRIVS (since Linux 3.5)
- Set the calling thread's no_new_privs attribute to the value in
arg2. With no_new_privs set to 1, execve(2) promises
not to grant privileges to do anything that could not have been done
without the execve(2) call (for example, rendering the set-user-ID
and set-group-ID mode bits, and file capabilities non-functional). Once
set, this the no_new_privs attribute cannot be unset. The setting
of this attribute is inherited by children created by fork(2) and
clone(2), and preserved across execve(2).
- Since Linux 4.10, the value of a thread's no_new_privs attribute
can be viewed via the NoNewPrivs field in the
/proc/[pid]/status file.
- For more information, see the kernel source file
Documentation/userspace-api/no_new_privs.rst (or
Documentation/prctl/no_new_privs.txt before Linux 4.13). See also
seccomp(2).
- PR_GET_NO_NEW_PRIVS (since Linux 3.5)
- Return (as the function result) the value of the no_new_privs
attribute for the calling thread. A value of 0 indicates the regular
execve(2) behavior. A value of 1 indicates execve(2) will
operate in the privilege-restricting mode described above.
- PR_SET_PDEATHSIG (since Linux 2.1.57)
- Set the parent-death signal of the calling process to arg2 (either
a signal value in the range 1..maxsig, or 0 to clear). This is the signal
that the calling process will get when its parent dies.
- Warning: the "parent" in this case is considered to be
the thread that created this process. In other words, the signal
will be sent when that thread terminates (via, for example,
pthread_exit(3)), rather than after all of the threads in the
parent process terminate.
- The parent-death signal is sent upon subsequent termination of the parent
thread and also upon termination of each subreaper process (see the
description of PR_SET_CHILD_SUBREAPER above) to which the caller is
subsequently reparented. If the parent thread and all ancestor subreapers
have already terminated by the time of the PR_SET_PDEATHSIG
operation, then no parent-death signal is sent to the caller.
- The parent-death signal is process-directed (see signal(7)) and, if
the child installs a handler using the sigaction(2)
SA_SIGINFO flag, the si_pid field of the siginfo_t
argument of the handler contains the PID of the terminating parent
process.
- The parent-death signal setting is cleared for the child of a
fork(2). It is also (since Linux 2.4.36 / 2.6.23) cleared when
executing a set-user-ID or set-group-ID binary, or a binary that has
associated capabilities (see capabilities(7)); otherwise, this
value is preserved across execve(2).
- PR_GET_PDEATHSIG (since Linux 2.3.15)
- Return the current value of the parent process death signal, in the
location pointed to by (int *) arg2.
- PR_SET_PTRACER (since Linux 3.4)
- This is meaningful only when the Yama LSM is enabled and in mode 1
("restricted ptrace", visible via
/proc/sys/kernel/yama/ptrace_scope). When a "ptracer process
ID" is passed in arg2, the caller is declaring that the
ptracer process can ptrace(2) the calling process as if it were a
direct process ancestor. Each PR_SET_PTRACER operation replaces the
previous "ptracer process ID". Employing PR_SET_PTRACER
with arg2 set to 0 clears the caller's "ptracer process
ID". If arg2 is PR_SET_PTRACER_ANY, the ptrace
restrictions introduced by Yama are effectively disabled for the calling
process.
- For further information, see the kernel source file
Documentation/admin-guide/LSM/Yama.rst (or
Documentation/security/Yama.txt before Linux 4.13).
- PR_SET_SECCOMP (since Linux 2.6.23)
- Set the secure computing (seccomp) mode for the calling thread, to limit
the available system calls. The more recent seccomp(2) system call
provides a superset of the functionality of PR_SET_SECCOMP.
- The seccomp mode is selected via arg2. (The seccomp constants are
defined in <linux/seccomp.h>.)
- With arg2 set to SECCOMP_MODE_STRICT, the only system calls
that the thread is permitted to make are read(2), write(2),
_exit(2) (but not exit_group(2)), and sigreturn(2).
Other system calls result in the delivery of a SIGKILL signal.
Strict secure computing mode is useful for number-crunching applications
that may need to execute untrusted byte code, perhaps obtained by reading
from a pipe or socket. This operation is available only if the kernel is
configured with CONFIG_SECCOMP enabled.
- With arg2 set to SECCOMP_MODE_FILTER (since Linux 3.5), the
system calls allowed are defined by a pointer to a Berkeley Packet Filter
passed in arg3. This argument is a pointer to struct
sock_fprog; it can be designed to filter arbitrary system calls and
system call arguments. This mode is available only if the kernel is
configured with CONFIG_SECCOMP_FILTER enabled.
- If SECCOMP_MODE_FILTER filters permit fork(2), then the
seccomp mode is inherited by children created by fork(2); if
execve(2) is permitted, then the seccomp mode is preserved across
execve(2). If the filters permit prctl() calls, then
additional filters can be added; they are run in order until the first
non-allow result is seen.
- For further information, see the kernel source file
Documentation/userspace-api/seccomp_filter.rst (or
Documentation/prctl/seccomp_filter.txt before Linux 4.13).
- PR_GET_SECCOMP (since Linux 2.6.23)
- Return (as the function result) the secure computing mode of the calling
thread. If the caller is not in secure computing mode, this operation
returns 0; if the caller is in strict secure computing mode, then the
prctl() call will cause a SIGKILL signal to be sent to the
process. If the caller is in filter mode, and this system call is allowed
by the seccomp filters, it returns 2; otherwise, the process is killed
with a SIGKILL signal. This operation is available only if the
kernel is configured with CONFIG_SECCOMP enabled.
- Since Linux 3.8, the Seccomp field of the /proc/[pid]/status
file provides a method of obtaining the same information, without the risk
that the process is killed; see proc(5).
- PR_SET_SECUREBITS (since Linux 2.6.26)
- Set the "securebits" flags of the calling thread to the value
supplied in arg2. See capabilities(7).
- PR_GET_SECUREBITS (since Linux 2.6.26)
- Return (as the function result) the "securebits" flags of the
calling thread. See capabilities(7).
- PR_GET_SPECULATION_CTRL (since Linux 4.17)
- Return (as the function result) the state of the speculation misfeature
specified in arg2. Currently, the only permitted value for this
argument is PR_SPEC_STORE_BYPASS (otherwise the call fails with the
error ENODEV).
- The return value uses bits 0-3 with the following meaning:
- PR_SPEC_PRCTL
- Mitigation can be controlled per thread by
PR_SET_SPECULATION_CTRL
- PR_SPEC_ENABLE
- The speculation feature is enabled, mitigation is disabled.
- PR_SPEC_DISABLE
- The speculation feature is disabled, mitigation is enabled
- PR_SPEC_FORCE_DISABLE
- Same as PR_SPEC_DISABLE but cannot be undone.
- If all bits are 0, then the CPU is not affected by the speculation
misfeature.
- If PR_SPEC_PRCTL is set, then per-thread control of the mitigation
is available. If not set, prctl() for the speculation misfeature
will fail.
- The arg3, arg4, and arg5 arguments must be specified
as 0; otherwise the call fails with the error EINVAL.
- PR_SET_SPECULATION_CTRL (since Linux 4.17)
- Sets the state of the speculation misfeature specified in arg2.
Currently, the only permitted value for this argument is
PR_SPEC_STORE_BYPASS (otherwise the call fails with the error
ENODEV). This setting is a per-thread attribute. The arg3
argument is used to hand in the control value, which is one of the
following:
- PR_SPEC_ENABLE
- The speculation feature is enabled, mitigation is disabled.
- PR_SPEC_DISABLE
- The speculation feature is disabled, mitigation is enabled
- PR_SPEC_FORCE_DISABLE
- Same as PR_SPEC_DISABLE but cannot be undone. A subsequent
prctl(..., PR_SPEC_ENABLE) will fail with the error
EPERM.
- Any other value in arg3 will result in the call failing with the
error ERANGE.
- The arg4 and arg5 arguments must be specified as 0;
otherwise the call fails with the error EINVAL.
- The speculation feature can also be controlled by the
spec_store_bypass_disable boot parameter. This parameter may
enforce a read-only policy which will result in the prctl() call
failing with the error ENXIO. For further details, see the kernel
source file Documentation/admin-guide/kernel-parameters.txt.
- PR_SET_THP_DISABLE (since Linux 3.15)
- Set the state of the "THP disable" flag for the calling thread.
If arg2 has a nonzero value, the flag is set, otherwise it is
cleared. Setting this flag provides a method for disabling transparent
huge pages for jobs where the code cannot be modified, and using a malloc
hook with madvise(2) is not an option (i.e., statically allocated
data). The setting of the "THP disable" flag is inherited by a
child created via fork(2) and is preserved across
execve(2).
- PR_TASK_PERF_EVENTS_DISABLE (since Linux 2.6.31)
- Disable all performance counters attached to the calling process,
regardless of whether the counters were created by this process or another
process. Performance counters created by the calling process for other
processes are unaffected. For more information on performance counters,
see the Linux kernel source file tools/perf/design.txt.
- Originally called PR_TASK_PERF_COUNTERS_DISABLE; renamed (retaining
the same numerical value) in Linux 2.6.32.
- PR_TASK_PERF_EVENTS_ENABLE (since Linux 2.6.31)
- The converse of PR_TASK_PERF_EVENTS_DISABLE; enable performance
counters attached to the calling process.
- Originally called PR_TASK_PERF_COUNTERS_ENABLE; renamed in Linux
2.6.32.
- PR_GET_THP_DISABLE (since Linux 3.15)
- Return (as the function result) the current setting of the "THP
disable" flag for the calling thread: either 1, if the flag is set,
or 0, if it is not.
- PR_GET_TID_ADDRESS (since Linux 3.5)
- Return the clear_child_tid address set by set_tid_address(2)
and the clone(2) CLONE_CHILD_CLEARTID flag, in the location
pointed to by (int **) arg2. This feature is
available only if the kernel is built with the
CONFIG_CHECKPOINT_RESTORE option enabled. Note that since the
prctl() system call does not have a compat implementation for the
AMD64 x32 and MIPS n32 ABIs, and the kernel writes out a pointer using the
kernel's pointer size, this operation expects a user-space buffer of 8
(not 4) bytes on these ABIs.
- PR_SET_TIMERSLACK (since Linux 2.6.28)
- Each thread has two associated timer slack values: a "default"
value, and a "current" value. This operation sets the
"current" timer slack value for the calling thread. arg2
is an unsigned long value, then maximum "current" value is
ULONG_MAX and the minimum "current" value is 1. If the
nanosecond value supplied in arg2 is greater than zero, then the
"current" value is set to this value. If arg2 is equal to
zero, the "current" timer slack is reset to the thread's
"default" timer slack value.
- The "current" timer slack is used by the kernel to group timer
expirations for the calling thread that are close to one another; as a
consequence, timer expirations for the thread may be up to the specified
number of nanoseconds late (but will never expire early). Grouping timer
expirations can help reduce system power consumption by minimizing CPU
wake-ups.
- The timer expirations affected by timer slack are those set by
select(2), pselect(2), poll(2), ppoll(2),
epoll_wait(2), epoll_pwait(2), clock_nanosleep(2),
nanosleep(2), and futex(2) (and thus the library functions
implemented via futexes, including pthread_cond_timedwait(3),
pthread_mutex_timedlock(3), pthread_rwlock_timedrdlock(3),
pthread_rwlock_timedwrlock(3), and sem_timedwait(3)).
- Timer slack is not applied to threads that are scheduled under a real-time
scheduling policy (see sched_setscheduler(2)).
- When a new thread is created, the two timer slack values are made the same
as the "current" value of the creating thread. Thereafter, a
thread can adjust its "current" timer slack value via
PR_SET_TIMERSLACK. The "default" value can't be changed.
The timer slack values of init (PID 1), the ancestor of all
processes, are 50,000 nanoseconds (50 microseconds). The timer slack value
is inherited by a child created via fork(2), and is preserved
across execve(2).
- Since Linux 4.6, the "current" timer slack value of any process
can be examined and changed via the file /proc/[pid]/timerslack_ns.
See proc(5).
- PR_GET_TIMERSLACK (since Linux 2.6.28)
- Return (as the function result) the "current" timer slack value
of the calling thread.
- PR_SET_TIMING (since Linux 2.6.0)
- Set whether to use (normal, traditional) statistical process timing or
accurate timestamp-based process timing, by passing
PR_TIMING_STATISTICAL or PR_TIMING_TIMESTAMP to arg2.
PR_TIMING_TIMESTAMP is not currently implemented (attempting to set
this mode will yield the error EINVAL).
- PR_GET_TIMING (since Linux 2.6.0)
- Return (as the function result) which process timing method is currently
in use.
- PR_SET_TSC (since Linux 2.6.26, x86 only)
- Set the state of the flag determining whether the timestamp counter can be
read by the process. Pass PR_TSC_ENABLE to arg2 to allow it
to be read, or PR_TSC_SIGSEGV to generate a SIGSEGV when the
process tries to read the timestamp counter.
- PR_GET_TSC (since Linux 2.6.26, x86 only)
- Return the state of the flag determining whether the timestamp counter can
be read, in the location pointed to by (int *) arg2.
- PR_SET_UNALIGN
- (Only on: ia64, since Linux 2.3.48; parisc, since Linux 2.6.15; PowerPC,
since Linux 2.6.18; Alpha, since Linux 2.6.22; sh, since Linux 2.6.34;
tile, since Linux 3.12) Set unaligned access control bits to arg2.
Pass PR_UNALIGN_NOPRINT to silently fix up unaligned user accesses,
or PR_UNALIGN_SIGBUS to generate SIGBUS on unaligned user
access. Alpha also supports an additional flag with the value of 4 and no
corresponding named constant, which instructs kernel to not fix up
unaligned accesses (it is analogous to providing the UAC_NOFIX flag
in SSI_NVPAIRS operation of the setsysinfo() system call on
Tru64).
- PR_GET_UNALIGN
- (See PR_SET_UNALIGN for information on versions and architectures.)
Return unaligned access control bits, in the location pointed to by
(unsigned int *) arg2.
On success, PR_GET_DUMPABLE, PR_GET_FP_MODE,
PR_GET_KEEPCAPS, PR_GET_NO_NEW_PRIVS, PR_GET_THP_DISABLE,
PR_CAPBSET_READ, PR_GET_TIMING, PR_GET_TIMERSLACK,
PR_GET_SECUREBITS, PR_GET_SPECULATION_CTRL,
PR_MCE_KILL_GET, PR_CAP_AMBIENT+PR_CAP_AMBIENT_IS_SET,
and (if it returns) PR_GET_SECCOMP return the nonnegative values
described above. All other option values return 0 on success. On error,
-1 is returned, and errno is set appropriately.
- EACCES
- option is PR_SET_SECCOMP and arg2 is
SECCOMP_MODE_FILTER, but the process does not have the
CAP_SYS_ADMIN capability or has not set the no_new_privs
attribute (see the discussion of PR_SET_NO_NEW_PRIVS above).
- EACCES
- option is PR_SET_MM, and arg3 is
PR_SET_MM_EXE_FILE, the file is not executable.
- EBADF
- option is PR_SET_MM, arg3 is
PR_SET_MM_EXE_FILE, and the file descriptor passed in arg4
is not valid.
- EBUSY
- option is PR_SET_MM, arg3 is
PR_SET_MM_EXE_FILE, and this the second attempt to change the
/proc/pid/exe symbolic link, which is prohibited.
- EFAULT
- arg2 is an invalid address.
- EFAULT
- option is PR_SET_SECCOMP, arg2 is
SECCOMP_MODE_FILTER, the system was built with
CONFIG_SECCOMP_FILTER, and arg3 is an invalid address.
- EINVAL
- The value of option is not recognized.
- EINVAL
- option is PR_MCE_KILL or PR_MCE_KILL_GET or
PR_SET_MM, and unused prctl() arguments were not specified
as zero.
- EINVAL
- arg2 is not valid value for this option.
- EINVAL
- option is PR_SET_SECCOMP or PR_GET_SECCOMP, and the
kernel was not configured with CONFIG_SECCOMP.
- EINVAL
- option is PR_SET_SECCOMP, arg2 is
SECCOMP_MODE_FILTER, and the kernel was not configured with
CONFIG_SECCOMP_FILTER.
- EINVAL
- option is PR_SET_MM, and one of the following is true
- arg4 or arg5 is nonzero;
- arg3 is greater than TASK_SIZE (the limit on the size of the
user address space for this architecture);
- arg2 is PR_SET_MM_START_CODE, PR_SET_MM_END_CODE,
PR_SET_MM_START_DATA, PR_SET_MM_END_DATA, or
PR_SET_MM_START_STACK, and the permissions of the corresponding
memory area are not as required;
- arg2 is PR_SET_MM_START_BRK or PR_SET_MM_BRK, and
arg3 is less than or equal to the end of the data segment or
specifies a value that would cause the RLIMIT_DATA resource limit
to be exceeded.
- EINVAL
- option is PR_SET_PTRACER and arg2 is not 0,
PR_SET_PTRACER_ANY, or the PID of an existing process.
- EINVAL
- option is PR_SET_PDEATHSIG and arg2 is not a valid
signal number.
- EINVAL
- option is PR_SET_DUMPABLE and arg2 is neither
SUID_DUMP_DISABLE nor SUID_DUMP_USER.
- EINVAL
- option is PR_SET_TIMING and arg2 is not
PR_TIMING_STATISTICAL.
- EINVAL
- option is PR_SET_NO_NEW_PRIVS and arg2 is not equal
to 1 or arg3, arg4, or arg5 is nonzero.
- EINVAL
- option is PR_GET_NO_NEW_PRIVS and arg2, arg3,
arg4, or arg5 is nonzero.
- EINVAL
- option is PR_SET_THP_DISABLE and arg3, arg4,
or arg5 is nonzero.
- EINVAL
- option is PR_GET_THP_DISABLE and arg2, arg3,
arg4, or arg5 is nonzero.
- EINVAL
- option is PR_CAP_AMBIENT and an unused argument
(arg4, arg5, or, in the case of
PR_CAP_AMBIENT_CLEAR_ALL, arg3) is nonzero; or arg2
has an invalid value; or arg2 is PR_CAP_AMBIENT_LOWER,
PR_CAP_AMBIENT_RAISE, or PR_CAP_AMBIENT_IS_SET and
arg3 does not specify a valid capability.
- EINVAL
- option was PR_GET_SPECULATION_CTRL or
PR_SET_SPECULATION_CTRL and unused arguments to prctl() are
not 0.
- ENODEV
- option was PR_SET_SPECULATION_CTRL the kernel or CPU does
not support the requested speculation misfeature.
- ENXIO
- option was PR_MPX_ENABLE_MANAGEMENT or
PR_MPX_DISABLE_MANAGEMENT and the kernel or the CPU does not
support MPX management. Check that the kernel and processor have MPX
support.
- ENXIO
- option was PR_SET_SPECULATION_CTRL implies that the control
of the selected speculation misfeature is not possible. See
PR_GET_SPECULATION_CTRL for the bit fields to determine which
option is available.
- EOPNOTSUPP
- option is PR_SET_FP_MODE and arg2 has an invalid or
unsupported value.
- EPERM
- option is PR_SET_SECUREBITS, and the caller does not have
the CAP_SETPCAP capability, or tried to unset a "locked"
flag, or tried to set a flag whose corresponding locked flag was set (see
capabilities(7)).
- EPERM
- option is PR_SET_SPECULATION_CTRL wherein the speculation
was disabled with PR_SPEC_FORCE_DISABLE and caller tried to enable
it again.
- EPERM
- option is PR_SET_KEEPCAPS, and the caller's
SECBIT_KEEP_CAPS_LOCKED flag is set (see
capabilities(7)).
- EPERM
- option is PR_CAPBSET_DROP, and the caller does not have the
CAP_SETPCAP capability.
- EPERM
- option is PR_SET_MM, and the caller does not have the
CAP_SYS_RESOURCE capability.
- EPERM
- option is PR_CAP_AMBIENT and arg2 is
PR_CAP_AMBIENT_RAISE, but either the capability specified in
arg3 is not present in the process's permitted and inheritable
capability sets, or the PR_CAP_AMBIENT_LOWER securebit has been
set.
- ERANGE
- option was PR_SET_SPECULATION_CTRL and arg3 is
neither PR_SPEC_ENABLE, PR_SPEC_DISABLE, nor
PR_SPEC_FORCE_DISABLE.
The prctl() system call was introduced in Linux 2.1.57.
This call is Linux-specific. IRIX has a prctl() system call (also
introduced in Linux 2.1.44 as irix_prctl on the MIPS architecture), with
prototype
ptrdiff_t prctl(int option, int arg2, int arg3);
and options to get the maximum number of processes per user, get
the maximum number of processors the calling process can use, find out
whether a specified process is currently blocked, get or set the maximum
stack size, and so on.
This page is part of release 5.05 of the Linux man-pages project. A
description of the project, information about reporting bugs, and the latest
version of this page, can be found at https://www.kernel.org/doc/man-pages/.


Ober Gatlinburg's rail jam kicks off the season
by WVLT NewsGATLINBURG, Tenn. (WVLT) -- Ober Gatlinburg started the season off with its annual Back in Blue Rail Jam.
The winter park opened up a section filled with rails, boxes and jumps for skiers and snowboarders.
In addition, Ober Gatlinburg said there were prizes, music and vendors for those not participating in the rail jam.
The jam was for one night but the snow tubing was set to be open the following morning, Saturday, Nov. 23.


These are builds for Hologram. Keep in mind that most of these are beta and some of them might be broken.


{filter-mod1-cluster.png width=373}
This contains a standard {Filter_mod_select mod select} {_parameter} and a corresponding {Filter_mod_depth mod depth} {_slider}. However, unlike the other four mod inputs, this one also includes a {Filter_mod_steps mod steps} parameter, to either introduce quantizing to the modulation, or to sample it by a {_sweep}.


<EMAIL_ADDRESS>Matthew Diana
Software Engineer working in NYC
Education
Computer Science B.S.
Binghamton University
Work
Software Engineer
DoorDash


Oops! Looks like there was something wrong with that information, please correct the info in the highlighted boxes


MikeTECH Issue Tracker
Port Harcourt, Nigeria
Add New Issue:
Description
Severity
Low
Medium
High
Assigned To
Add


|
The SimpsonsMmmmmm... Mainstream success....Matt Groening (rhymes with "complaining") had made a name for himself as a demented cult cartoonist long before "The Simpsons" ever came along. "Life in Hell," an alternative weekly comic strip, debuted in 1977 with the adventures of a dissipated rabbit named Binky, and his extremely neurotic friends (included fez-wearing gay twins/lovers Akbar and Jeff). "Life in Hell" was often searingly satirical, pushing the edge with biting comments on relationships, sex, careers and politics. Funny and off the beaten track, the strip caught the attention of the producers of "The Tracey Ullman Show," a headline attraction on the brand-spankin' new Fox TV network. The original "Simpsons" cartoons were short vignettes inserted around the commercial breaks of the comedy-variety show. These were short punchline-driven segments, with a cynical tone that flowed directly off the pages of "Life in Hell." The animation was terrible, the voices were weird, and the skits tended to have very low energy levels. But they were funny, and they were edgy, qualities that hadn't been seen in TV animation since the glory days of "Rocky and Bullwinkle." The reactions to the Simpsons bits on "Ullman" were so favorable that Fox picked up the idea as a series of its own, and "The Simpsons" debuted in midseason, January of 1990. The half hour series instantly became one of the Fox network's biggest hits, scoring an Emmy its first year out. Although it's kind of hard to imagine now, the show was a lightning rod for cultural critics at the time (including Dan Quayle and George and Barbara Bush), who found "The Simpsons" emblematic of everything that was wrong with America, such as Homer's penchant for strangling his trouble-making son, Bart. Of course, the whole point of the show was to be emblematic of everything wrong with America. Arguably, it was the whole point of the entire Fox network. Fortunately for Fox and Groening, Americans love to glorify their faults. Well, that and the fact that it was really, really, really funny. The show originally focused on the antics of Bart, the young anti-authoritarian son of the family. After a brief, faddish craze over Bart Simpson catchphrases like "Don't have a cow" and "Eat my shorts," the writers wisely realized that the heart of the show wasn't Bart so much as Homer Simpson, the crude, stupid, selfish patriarch of the family. In the early going, Homer was basically a brutish and bad father and husband of moderately low intelligence, who learned valuable lessons about caring and sharing when the show bothered to focus on him. But over the course of the first three Simpsons, people began to notice that Homer was also funny. Really funny. The character progressed from brutish to mind-bogglingly stupid, with a feckless optimism that every awesomely bad idea he came up with would be his ticket "out of this hellhole." It took a couple of years for actor Dan Castellenata to get the voice performance for Homer just right. Once his familiar cadence set in, the show entered its second, non-faddish phase of popularity, and stayed there for a decade. Homer's catchphrases had more staying power. There's not a lot of poetry in "Don't have a cow, man" but "Mmmmmmmmm... donuts" satisfied some primal need among viewers. And then there was Homer's anguished cry of existential despair, "D'oh!" Long after Bart's "cowabunga" was gathering dust in the Secret Graveyard of Abandoned Pop Culture Cliches, "D'oh!" received the special distinction of being included in the Oxford English Dictionary in 2001. (It's defined as "expressing frustration at the realization that things have turned out badly or not as planned or that one has just said or done something foolish.") Rounding out the Simpson clan are Marge, the long-suffering and mostly repressed mother, Lisa, the brainy child, and Maggie, the mute baby.  As the show went on, the supporting cast was often featured in star turns, including washed-up movie star Troy McClure, portrayed by the late Phil Hartman, who introduced himself invariably with the line: "Hi, I'm Troy McClure! You may remember me from such..."
Oh hell, let's do the Homer lines anyway:
Timeline
|


Python Flask Scrapy API¶
Arachne provides a wrapper around your scrapy spider to run them through a flask app. All you have to do is setup your SPIDER_SETTINGS
in the settings file. You can view the source code on github.
Arachne is powered by Flask, Twisted and the Scrapy package
Why not scrapyd?¶
The best code is no code at all, I have tried to write as little code as possible to maintain my scrapy projects but when I started off using scrapy daemon, it was incredibly harder to maintain. My project grew to over 100 spiders and then I started to break my projects into smaller tiny pieces when I got to the bare roots of it then lo and behold, this project is its creation.
Installation¶
To install Arachne from pip use the command
pip install -i https://pypi.python.org/pypi/Arachne
Do I support django?¶
Since I haven’t had a lot of experience working with django I would not be able to comment on it but you can run this flask app on a different port and call your individual spiders from your django app.
Deploying to webserver¶
Since this project is very much like a flask app please read the official flask docs to learn how to deploy to a webserver


this is slider Page One
this is slider Page Two
this is slider Page Three
Fill your standard identity


FATHERLAND A film review by Steve Rhodes Copyright 1997 Steve Rhodes
RATING (0 TO ****): ** 1/2
As in many a mystery, the journalist is handed a picture by a mysterious stranger. In the old photo is a group of unknown people brought together during a key moment in WWII. What has happened to these people since, and what is the relevance of this photograph? Although this outline is standard issue, the circumstances surrounding it are not.
The book "Fatherland" is a taut thriller and author Robert Harris's first novel. I read this engrossing tale on vacation a few years back and thought at the time that a wonderful motion picture could be made from it. Although the script by Ron Hutchinson and Stanley Weiser borrows liberally from the novel, usually reliable director Christopher Menaul ("Prime Suspect 1" and FEAST OF JULY) manages to excise much of the suspense. Most of the key events from the novel are there, but in the 1994 film FATHERLAND they are laid before the viewer devoid of much of the energy and emotion present in the novel.
The story is set in the mid-1960s in a Europe renamed Germania and controlled by Adolf Hitler. Hitler has essentially won the war with a stalemated peace even if the US never signed a treaty, and the war on the Eastern front with Russia drags on ad infinitum. The US, led by President Joseph P. Kennedy, has begun to make some peace overtones to Germania. For the first time since before the war, Germania is letting American journalists into the country since Germania is celebrating Hitler's 75th birthday. All, however, is not well in the National Socialists' world. The knowledge of the Holocaust is limited to a few high-ranking Germans.
Into this carefully contrived calm comes a murder of a high ranking member of the SS. With the body found in a lake, an SS police officer, Major Xavier March, is sent to investigate. According to his dossier, the dead man turns out to have been an architect of "the Jewish resettlement program" and even designed certain new efficiencies in the program. (The Germans and the world believe that the Jews were resettled to the Eastern front. With the war with Russia dragging on forever, who could check the story's accuracy anyway.)
Rutger Hauer, who specializes of late in over-the-top performances, is remarkably subtle this time as Major Xavier March. March is one of the few good Nazis, an officer whose bulky uniform seems to hang on him heavily and awkwardly now. The Major is a veteran detective member of the SS, who has grown tired of the Nazis. When his son gives the Nazi youth pledge to Hitler at mealtime, March suggests they say grace instead like they used to.
His son, Dili, is a well scrubbed and naive member of the Hitler youth movement. Rory Jennings plays Dili as an automaton who shows little emotion at times when any human being would have had to be significantly affected.
The simple murder gets more complicated when General Globus (John Shrapnel), the head of the Gestapo, is found to have been at the scene. Soon a cover-up is afoot, and March is taken off the case.
Miranda Richarson plays an American journalist named Charlie Maguire, who was originally born in Germany but who left as a little girl. She is passed the mysterious and incriminating photos by a stranger, along with a cryptic note to see someone to find out more about the picture's background.
In delicious bit of casting against type, Jean Marsh shows up briefly as a creepy old German actress who blames her lack of success in America on those Jews who run the studios.
The book spent more time on the detective work whereas the movie devotes too much time to establishing Hauer's "good" Nazi credentials. And while the book kept the reader on the edge of the chair, the movie's laconic pacing and unhurried staging robs the story of its threatening immediacy. The movie makes everything too predictable, but the book had the gift of making the obvious surprising.
A gripping and lucid book is thus transformed into a confusing and slow movie that is populated with a remarkably tame group of Nazis with little visible anger. Even the Gestapo, with the exception of their sinister hats, don't seem to be a particularly bad lot. New York City cops are usually portrayed as more vicious by the movies. Still, the fascinating underlying plot and Hauer's moving performance ultimately save the picture, but just barely.
FATHERLAND runs 1:48. It is rated PG-13 for brief nudity, some violence and a few pictures of concentration camp victims. The film would be fine for kids age 12 and up.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


In order to keep a full installation of other modules handy, we will create a copy of the profile:
Files to install:
- Restores a huge amount of scenery and other random things that were patched out of the game post-release
Files to install:
- Patch for Character Expansions Revised and Uncut Wasteland
Install normally
FNVEdit editing required:
- Restores content seen in the pre-release trailers and screenshots but later cut from the game
Install normally
- Makes the Northwest and Southwest sewers accessible and moves the Sealed Sewer back where it belongs
Install normally
- Restores possibly the stupidest quest in all of Fallout back to its intended, less stupid, state
Files to install:
- Adds a fully functional post-game world to the game that changes based on your choices in-game
Install normally
- Improves options and makes the conclusion of the Beyond the Beef quest more fulfilling
Hide the following:
- Modifies Vault 22 with more flora, ivy, bushes, grasses, etc.
NOTE: This mod can be very heavy on performance due to it not having roombounds/portals and can be skipped without any issues
Files to install:
- Removes new creatures, weapons, poison effects, crafting recipes, etc. (really any out of place changes), along with a few other misc tweaks
Install normally
Hide the following:
- An overhaul of the Lucky 38 penthouse that makes it feel less bland and visually uninteresting
Files to install:
- Removes un-lore friendly aspects of the overhaul such as real life pictures of Howard Hughes, the inspiration for Mr. House


Input group
Basic example
@
@example.com
https://example.com/users/
$
.00
$
0.00
Sizing
@
@
@
Checkboxes and radio addons
Multiple addons
$
.00
$
0.00


|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
public interface MutableDynaClass
A specialized extension to DynaClass
that allows properties
to be added or removed dynamically.
WARNING - No guarantees that this will be in the final APIs ... it's here primarily to preserve some concepts that were in the original proposal for further discussion.
| Method Summary | |
|---|---|
void |
add(String name)
Add a new dynamic property with no restrictions on data type, readability, or writeability. |
void |
add(String name,
Class type)
Add a new dynamic property with the specified data type, but with no restrictions on readability or writeability. |
void |
add(String name,
Class type,
boolean readable,
boolean writeable)
Add a new dynamic property with the specified data type, readability, and writeability. |
boolean |
isRestricted()
Is this DynaClass currently restricted, if so, no changes to the existing registration of property names, data types, readability, or writeability are allowed. |
void |
remove(String name)
Remove the specified dynamic property, and any associated data type, readability, and writeability, from this dynamic class. |
void |
setRestricted(boolean restricted)
Set the restricted state of this DynaClass to the specified value. |
| Methods inherited from interface org.apache.commons.beanutils.DynaClass |
|---|
getDynaProperties, getDynaProperty, getName, newInstance |
| Method Detail |
|---|
void add(String name)
name
- Name of the new dynamic property
IllegalArgumentException
- if name is null
IllegalStateException
- if this DynaClass is currently
restricted, so no new properties can be addedvoid add(String name, Class type)
name
- Name of the new dynamic propertytype
- Data type of the new dynamic property (null for no
restrictions)
IllegalArgumentException
- if name is null
IllegalStateException
- if this DynaClass is currently
restricted, so no new properties can be addedvoid add(String name, Class type, boolean readable, boolean writeable)
name
- Name of the new dynamic propertytype
- Data type of the new dynamic property (null for no
restrictions)readable
- Set to true
if this property value
should be readablewriteable
- Set to true
if this property value
should be writeable
IllegalArgumentException
- if name is null
IllegalStateException
- if this DynaClass is currently
restricted, so no new properties can be addedboolean isRestricted()
true
if this Mutable DynaClass
is restricted,
otherwise false
void remove(String name)
name
- Name of the dynamic property to remove
IllegalArgumentException
- if name is null
IllegalStateException
- if this DynaClass is currently
restricted, so no properties can be removedvoid setRestricted(boolean restricted)
restricted
- The new restricted state
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


An iterator that read the records from a TFRecords file. (deprecated)
tf.compat.v1.python_io.tf_record_iterator
tf.compat.v1.io.tf_record_iterator( path, options=None )
Warning: THIS FUNCTION IS DEPRECATED. It will be removed in a future version.
Instructions for updating:
Use eager execution and:
tf.data.TFRecordDataset(path)
path
: The path to the TFRecords file.options
: (optional) A TFRecordOptions object.Strings.
IOError
: If path
cannot be opened for reading.


How we were hired ?
Kamal Traders is a 48 year old flower decoration business.
Ramesh Bajaj sir asked around and found out about our work for businesses wanting to start selling online.
A colleague of his recommended us.
We analyze data to identify action plans, priorities for better digital marketing.
We measure results and constantly experiment to use the best marketing actions and channels for you.
We make our own tools to constantly accelerate your business growth through automations where applicable.
Create and manage multiple opencart online stores instantly.
We love jekyll. We made a simple minimal ecommerce store by using jekyll for our customers starting up in ecommerce.
How we were hired ?
Kamal Traders is a 48 year old flower decoration business.
Ramesh Bajaj sir asked around and found out about our work for businesses wanting to start selling online.
A colleague of his recommended us.
How we got hired ?
Amit Gala - a young, strong entrepreneur contacted vineet naik to implement a new idea.
We were lucky to have vineet naik as our CTO till 2014.
Vineet referred us and Amit Gala visited us.
How we got hired ?
Few Months back, I was hanging out at therodinhoods.com
Luckily a rodinhoods member recommended our work to chandan mishra - the founder at 3digiprints.
How we were hired ?
3 years back - we were offering ecommerce websites to customers.
Shiv Shah sir visited us one day and spoke at length about the extensive range of health
products he had learned to create over a decade.
Here is some more information about this product that is only revealed once clicked on.
Here is some more information about this product that is only revealed once clicked on.
Here is some more information about this product that is only revealed once clicked on.
Here is some more information about this product that is only revealed once clicked on.
Congratulations on a job well done.

We have worked together for 3+ years and it was an easy happy experience.
Keep up the good work.
You guys are running a great show.
I have worked with 10+ companies into development and digital marketing.
you guys are offering real results and growth.
Glad to keep working with you.


Phil Nash
You've probably heard of the magic of a Service Worker when a user is offline, but what can we do for them when they get back online? We can take advantage of the Service Worker's life outside of the page and start to perform actions in the background.
In this talk we'll investigate the Background Sync API and the APIs that it depends upon, we'll look at what you might use it for and see it in action. Once that is behind us we can take a peek into the future and even more background tasks with a look at the Periodic Sync API.
Ashley Williams
Everybody knows `npm install`. In fact, around 100,000,000 people run it everyday. But what many people don't know is that there is much more to npm than simply installing! Ashley, an ops and services engineer, will take you on a tour of npm's greatest features, old and new, and demonstrates how they can be integrated into your workflow to make you better, happier, and more productive. Along the way she'll share some of the amazing stats about npm's usage, and show off some of the lesser known registry services that npm offers to help you build your own tooling for the npm ecosystem.
Shubheksha Jalan
The tremendous amount of activity in the JS ecosystem is a direct consequence of web being an “open” platform -- it is not owned by any particular corporation -- it’s at the disposal of the community to be advanced in the right direction. To do this and sustain its growth, we need to make sure our open source communities welcome everyone. I want to talk about the need for safe and welcoming open source communities in the context of “a web for everyone” so that everyone can play a part in propelling it forward. This talk will be about why we should and how we can lower barriers of entry to open source.
Andrey Sitnik
Andrey Sitnik, author of PostCSS and Autoprefixer will present his new open source project — Logux. A mix of ideas beside Redux, CRDT and Relay to replace AJAX requests and develop websites with live updates, Offline-first and Optimistics UI much easier


User:
errors
First name:
Last name:
Email:
Location:
Age:
Subscriptions:
Password:
Retype password:
10 + 1 =
Submit
Make 'Location' required


Show Version
Processname
Time to Capture (0 for infinity)
Record Directory
File format
Json
Json + CSV
Start Capture
Stop Capture


@() @main("Tic-Tac-Toe Debug") {
{ request: 'FindGameForPlayer', player: 'John' }
{ request: 'BoardStateRequest', game: '5' }
{ request: 'JoinGame', game: '5', player: 'Jim567' }
{ request: 'ListenToGame', game: '5' }
{ request: 'Move', row: 1, col: 2, game: '5' }}


The mission of The London Django Meetup Group is to provide a fun, welcoming and professional environment for a diverse group of people.
Code of conduct: djangolondon.com/code-of-conduct
Tonight's meetup is kindly sponsored by:
Kraken is a revolutionary energy tech platform built with Django. Serving 25 million households worldwide.
Pollen is a marketplace for the best in shared experiences.
4th July
Versions 4.0.6 and 3.2.14.
SQL injection vulnerability in Extract
and Trunc
database functions.
28th July
Event TBC but something will happen - see Meetup.
Dublin & Remote, 11th-17th July
Cfv closing this Friday!
Cardiff, 16th-18th September
Porto, 21st-23rd September
San Diego, October 16-21!
There will not be a DjangoCon Europe 2023 if the DSF board does not receive viable proposals for one.
CfP closing August 10
Must-have tools for running a production ready GraphQL API
by Ahter Sonmez
Setting up an internship programme from scratch
by Maya Shah
Q&A at the end of each talk.
You have a chance to win one of two 100% discount codes for a JetBrains product (AppCode, PyCharm, WebStorm. etc)
Put your name in the hat and we will draw the winners and send the licences via email.
After the talks we will chat here for a bit, and then later go round the corner to the pub.
Please use the form on our Twitter @djangolondon, or message us directly.
Website: djangolondon.com
Twitter: @djangolondon
Github: github.com/djangolondon
Open Collective: opencollective.com/the-london-django-meetup-group


| GCOV(1) | GNU | GCOV(1) |
Profiling tools help you analyze your code's performance. Using a profiler such as gcov or gprof, you can find out some basic performance statistics, such as:
Once you know these things about how your code works when compiled, you can look at each module to see which modules should be optimized. gcov helps you determine where to work on optimization.
Software developers also use coverage testing in concert with testsuites, to make sure software is actually good enough for a release. Testsuites can verify that a program works as expected; a coverage program tests to see how much of the program is exercised by the testsuite. Developers can then determine what kinds of test cases need to be added to the testsuites to create both better testing and a better final product.
You should compile your code without optimization if you plan to use gcov because the optimization, by combining some lines of code into one function, may not give you as much information as you need to look for `hot spots' where the code is using a great deal of computer time. Likewise, because gcov accumulates statistics by line (at the lowest resolution), it works best with a programming style that places only one statement on each line. If you use complicated macros that expand to loops or to other control structures, the statistics are less helpful---they only report on the line where the macro call appears. If your complex macros behave like functions, you can replace them with inline functions to solve this problem.
gcov creates a logfile called sourcefile.gcov which indicates how many times each line of a source file sourcefile.c has executed. You can use these logfiles along with gprof to aid in fine-tuning the performance of your programs. gprof gives timing information you can use along with the information you get from gcov.
gcov works only on code compiled with GCC. It is not compatible with any other profiling or test coverage mechanism.
Structure of the JSON is following:
{ "current_working_directory": <current_working_directory>, "data_file": <data_file>, "format_version": <format_version>, "gcc_version": <gcc_version> "files": [<file>] }
Fields of the root element have following semantics:
Each file has the following form:
{ "file": <file_name>, "functions": [<function>], "lines": [<line>] }
Fields of the file element have following semantics:
Each function has the following form:
{ "blocks": <blocks>, "blocks_executed": <blocks_executed>, "demangled_name": "<demangled_name>, "end_column": <end_column>, "end_line": <end_line>, "execution_count": <execution_count>, "name": <name>, "start_column": <start_column> "start_line": <start_line> }
Fields of the function element have following semantics:
Note that line numbers and column numbers number from 1. In the current implementation, start_line and start_column do not include any template parameters and the leading return type but that this is likely to be fixed in the future.
Each line has the following form:
{ "branches": [<branch>], "count": <count>, "line_number": <line_number>, "unexecuted_block": <unexecuted_block> "function_name": <function_name>, }
Branches are present only with -b option. Fields of the line element have following semantics:
Each branch has the following form:
{ "count": <count>, "fallthrough": <fallthrough>, "throw": <throw> }
Fields of the branch element have following semantics:
gcov should be run with the current directory the same as that when you invoked the compiler. Otherwise it will not be able to locate the source files. gcov produces files called mangledname .gcov in the current directory. These contain the coverage information of the source file they correspond to. One .gcov file is produced for each source (or header) file containing code, which was compiled to produce the data files. The mangledname part of the output file name is usually simply the source file name, but can be something more complicated if the -l or -p options are given. Refer to those options for details.
If you invoke gcov with multiple input files, the contributions from each input file are summed. Typically you would invoke it with the same list of files as the final link of your executable.
The .gcov files contain the : separated fields along with program source code. The format is
<execution_count>:<line_number>:<source line text>
Additional block information may succeed each line, when requested by command line option. The execution_count is - for lines containing no code. Unexecuted lines are marked ##### or =====, depending on whether they are reachable by non-exceptional paths or only exceptional paths such as C++ exception handlers, respectively. Given the -a option, unexecuted blocks are marked $$$$$ or %%%%%, depending on whether a basic block is reachable via non-exceptional or exceptional paths. Executed basic blocks having a statement with zero execution_count end with * character and are colored with magenta color with the -k option. This functionality is not supported in Ada.
Note that GCC can completely remove the bodies of functions that are not needed -- for instance if they are inlined everywhere. Such functions are marked with -, which can be confusing. Use the -fkeep-inline-functions and -fkeep-static-functions options to retain these functions and allow gcov to properly show their execution_count.
Some lines of information at the start have line_number of zero. These preamble lines are of the form
-:0:<tag>:<value>
The ordering and number of these preamble lines will be augmented as gcov development progresses --- do not rely on them remaining unchanged. Use tag to locate a particular preamble line.
The additional block information is of the form
<tag> <information>
The information is human readable, but designed to be simple enough for machine parsing too.
When printing percentages, 0% and 100% are only printed when the values are exactly 0% and 100% respectively. Other values which would conventionally be rounded to 0% or 100% are instead printed as the nearest non-boundary value.
When using gcov, you must first compile your program with a special GCC option --coverage. This tells the compiler to generate additional information needed by gcov (basically a flow graph of the program) and also includes additional code in the object files for generating the extra profiling information needed by gcov. These additional files are placed in the directory where the object file is located.
Running the program will cause profile output to be generated. For each source file compiled with -fprofile-arcs, an accompanying .gcda file will be placed in the object file directory.
Running gcov with your program's source file names as arguments will now produce a listing of the code along with frequency of execution for each line. For example, if your program is called tmp.cpp, this is what you see when you use the basic gcov facility:
$ g++ --coverage tmp.cpp $ a.out $ gcov tmp.cpp -m File 'tmp.cpp' Lines executed:92.86% of 14 Creating 'tmp.cpp.gcov'
The file tmp.cpp.gcov contains output from gcov. Here is a sample:
-: 0:Source:tmp.cpp -: 0:Working directory:/home/gcc/testcase -: 0:Graph:tmp.gcno -: 0:Data:tmp.gcda -: 0:Runs:1 -: 0:Programs:1 -: 1:#include <stdio.h> -: 2: -: 3:template<class T> -: 4:class Foo -: 5:{ -: 6: public: 1*: 7: Foo(): b (1000) {} ------------------ Foo<char>::Foo(): #####: 7: Foo(): b (1000) {} ------------------ Foo<int>::Foo(): 1: 7: Foo(): b (1000) {} ------------------ 2*: 8: void inc () { b++; } ------------------ Foo<char>::inc(): #####: 8: void inc () { b++; } ------------------ Foo<int>::inc(): 2: 8: void inc () { b++; } ------------------ -: 9: -: 10: private: -: 11: int b; -: 12:}; -: 13: -: 14:template class Foo<int>; -: 15:template class Foo<char>; -: 16: -: 17:int 1: 18:main (void) -: 19:{ -: 20: int i, total; 1: 21: Foo<int> counter; -: 22: 1: 23: counter.inc(); 1: 24: counter.inc(); 1: 25: total = 0; -: 26: 11: 27: for (i = 0; i < 10; i++) 10: 28: total += i; -: 29: 1*: 30: int v = total > 100 ? 1 : 2; -: 31: 1: 32: if (total != 45) #####: 33: printf ("Failure\n"); -: 34: else 1: 35: printf ("Success\n"); 1: 36: return 0; -: 37:}
Note that line 7 is shown in the report multiple times. First occurrence presents total number of execution of the line and the next two belong to instances of class Foo constructors. As you can also see, line 30 contains some unexecuted basic blocks and thus execution count has asterisk symbol.
When you use the -a option, you will get individual block counts, and the output looks like this:
-: 0:Source:tmp.cpp -: 0:Working directory:/home/gcc/testcase -: 0:Graph:tmp.gcno -: 0:Data:tmp.gcda -: 0:Runs:1 -: 0:Programs:1 -: 1:#include <stdio.h> -: 2: -: 3:template<class T> -: 4:class Foo -: 5:{ -: 6: public: 1*: 7: Foo(): b (1000) {} ------------------ Foo<char>::Foo(): #####: 7: Foo(): b (1000) {} ------------------ Foo<int>::Foo(): 1: 7: Foo(): b (1000) {} ------------------ 2*: 8: void inc () { b++; } ------------------ Foo<char>::inc(): #####: 8: void inc () { b++; } ------------------ Foo<int>::inc(): 2: 8: void inc () { b++; } ------------------ -: 9: -: 10: private: -: 11: int b; -: 12:}; -: 13: -: 14:template class Foo<int>; -: 15:template class Foo<char>; -: 16: -: 17:int 1: 18:main (void) -: 19:{ -: 20: int i, total; 1: 21: Foo<int> counter; 1: 21-block 0 -: 22: 1: 23: counter.inc(); 1: 23-block 0 1: 24: counter.inc(); 1: 24-block 0 1: 25: total = 0; -: 26: 11: 27: for (i = 0; i < 10; i++) 1: 27-block 0 11: 27-block 1 10: 28: total += i; 10: 28-block 0 -: 29: 1*: 30: int v = total > 100 ? 1 : 2; 1: 30-block 0 %%%%%: 30-block 1 1: 30-block 2 -: 31: 1: 32: if (total != 45) 1: 32-block 0 #####: 33: printf ("Failure\n"); %%%%%: 33-block 0 -: 34: else 1: 35: printf ("Success\n"); 1: 35-block 0 1: 36: return 0; 1: 36-block 0 -: 37:}
In this mode, each basic block is only shown on one line -- the last line of the block. A multi-line block will only contribute to the execution count of that last line, and other lines will not be shown to contain code, unless previous blocks end on those lines. The total execution count of a line is shown and subsequent lines show the execution counts for individual blocks that end on that line. After each block, the branch and call counts of the block will be shown, if the -b option is given.
Because of the way GCC instruments calls, a call count can be shown after a line with no individual blocks. As you can see, line 33 contains a basic block that was not executed.

For each basic block, a line is printed after the last line of the basic block describing the branch or call that ends the basic block. There can be multiple branches and calls listed for a single source line if there are multiple basic blocks that end on that line. In this case, the branches and calls are each given a number. There is no simple way to map these branches and calls back to source constructs. In general, though, the lowest numbered branch or call will correspond to the leftmost construct on the source line.
For a branch, if it was executed at least once, then a percentage indicating the number of times the branch was taken divided by the number of times the branch was executed will be printed. Otherwise, the message "never executed" is printed.
For a call, if it was executed at least once, then a percentage indicating the number of times the call returned divided by the number of times the call was executed will be printed. This will usually be 100%, but may be less for functions that call "exit" or "longjmp", and thus may not return every time they are called.
The execution counts are cumulative. If the example program were executed again without removing the .gcda file, the count for the number of times each line in the source was executed would be added to the results of the previous run(s). This is potentially useful in several ways. For example, it could be used to accumulate data over a number of program runs as part of a test verification suite, or to provide more accurate long-term information over a large number of program runs.
The data in the .gcda files is saved immediately before the program exits. For each source file compiled with -fprofile-arcs, the profiling code first attempts to read in an existing .gcda file; if the file doesn't match the executable (differing number of basic block counts) it will ignore the contents of the file. It then adds in the new execution counts and finally writes the data to the file.
if (a != b) c = 1; else c = 0;
can be compiled into one instruction on some machines. In this case, there is no way for gcov to calculate separate execution counts for each line because there isn't separate code for each line. Hence the gcov output looks like this if you compiled the program with optimization:
100: 12:if (a != b) 100: 13: c = 1; 100: 14:else 100: 15: c = 0;
The output shows that this block of code, combined by optimization, executed 100 times. In one sense this result is correct, because there was only one instruction representing all four of these lines. However, the output does not indicate how many times the result was 0 and how many times the result was 1.
Inlineable functions can create unexpected line counts. Line counts are shown for the source code of the inlineable function, but what is shown depends on where the function is inlined, or if it is not inlined at all.
If the function is not inlined, the compiler must emit an out of line copy of the function, in any object file that needs it. If fileA.o and fileB.o both contain out of line bodies of a particular inlineable function, they will also both contain coverage counts for that function. When fileA.o and fileB.o are linked together, the linker will, on many systems, select one of those out of line bodies for all calls to that function, and remove or ignore the other. Unfortunately, it will not remove the coverage counters for the unused function body. Hence when instrumented, all but one use of that function will show zero counts.
If the function is inlined in several places, the block structure in each location might not be the same. For instance, a condition might now be calculable at compile time in some instances. Because the coverage of all the uses of the inline function will be shown for the same source lines, the line counts themselves might seem inconsistent.
Long-running applications can use the "__gcov_reset" and "__gcov_dump" facilities to restrict profile collection to the program region of interest. Calling "__gcov_reset(void)" will clear all profile counters to zero, and calling "__gcov_dump(void)" will cause the profile information collected at that point to be dumped to .gcda output files. Instrumented applications use a static destructor with priority 99 to invoke the "__gcov_dump" function. Thus "__gcov_dump" is executed after all user defined static destructors, as well as handlers registered with "atexit". If an executable loads a dynamic shared object via dlopen functionality, -Wl,--dynamic-list-data is needed to dump all profile data.
Profiling run-time library reports various errors related to profile manipulation and profile saving. Errors are printed into standard error output or GCOV_ERROR_FILE file, if environment variable is used. In order to terminate immediately after an errors occurs set GCOV_EXIT_AT_ERROR environment variable. That can help users to find profile clashing which leads to a misleading profile.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with the Invariant Sections being "GNU General Public License" and "Funding Free Software", the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the gfdl(7) man page.
(a) The FSF's Front-Cover Text is:
A GNU Manual
(b) The FSF's Back-Cover Text is:
You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.
| 2020-03-12 | gcc-9.3.0 |


Default Title
Add any Wish you can dream up, with occasion, description, price and target date
My Wish is
for the occasion of
It will cost
$
I would like to fulfill my wish by, Date
View your wish list


A model of cancer cells evolving along a
spatial oxygen gradient. This model is a companion to a set of laboratory experiments using
MEMIC plates.
If you have questions or want to know more, feel free to contact me!
Click the "start" button in the lower left to start the model. Click "stop" at any time to pause it.
The left box shows a map of oxygen concentration across the world (higher hue values (e.g. blue, purple, magenta) have more oxygen). You can click anywhere on the map to add oxygen there.
The right box shows the phylogenetic depth (distance from original ancestor) of each cell in the world. Higher hue values are farther down the tree (i.e. more generations have elapsed). Black cells are unoccupied. To color based on a different piece of data, click the dropdown menu next to the "start" and "reset" buttons and select a new color rule.
You can adjust the sliders to change parameters. For parameters that change the starting conditions (e.g. initial population size), click the "reset" button after adjusting the parameter before clicking "start."
To apply radiation, click the "Radiation" button. This will simulate applying the number of doses specified by the "Doses" parameter (note that the default is 0, which will apply no radiation) of the size specified by the "Dose size" parameter. Applying radiation will mark cells for death, causing them to die when they next try to divide (choose to color be "Marked for death" to see which cells have been marked for death).
Great! Thanks for letting me know! You can send bugs and feature requests by making an issue on GitHub (or contacting me some other way, if that's easier for you).
Fantastic! Send me an e-mail and we can talk about collaboration.
For full details, see the GitHub repo for this site. In summary, though, I used:
This project is being carried out by the Theory Division at the Cleveland Clinic Lerner Research Institute (views expressed here are my own and do not necessarily reflect the views of Cleveland Clinic or LRI).
I'm a Postdoctoral Fellow at the Cleveland Clinic Lerner Research Institute studying evolution, ecology, and computer science. To learn more about my research, see my website.