It’s difficult to get far in imaging and guiding without
coming to grips with astronomical seeing.
This is a complex subject so only the bare minimum can be covered here. “Seeing” is the term given to the positional jitter
and sudden brightness changes of stars we see (or photograph) through a
telescope. With the naked eye, we see
this as “twinkling” because our eye can’t resolve the tiny positional movements
of the star. It is atmospheric
turbulence, caused by the movement of thermal cells at various levels in the
Earth’s atmosphere. Light is refracted as it passes through each atmospheric
cell, so when you look at a star, you’re really looking up through a column of
air that is behaving like a column of little lenses. The refraction of the light by each cell
depends on its temperature, and the cells generally have different
temperatures. And because the atmosphere
is very dynamic, these elements are all moving around at various speeds, coming
into and then leaving the column of air you’re looking through. Particularly with longer focal lengths, this
atmospheric seeing is the single biggest source of the guide star movement we
see with a properly working mount, and it can’t be “guided out”. The
movement of the atmospheric cells means
the guide star position is changing at rates of 10’s to 1000’s of times
per
second, and amateur-grade equipment, even adaptive optics devices,
can’t react
quickly enough to correct for it. Professional observatories are able
to do it
to a large extent by employing very expensive measurement devices,
artificial
stars, and mechanisms that can both deform the mirror and shift the
image at
very high frequencies. For these observatories, most
of the seeing disturbances originate in the upper layers of the
atmosphere and those are the layers that are used for seeing
models and most seeing forecasts. For amateurs and
especially for those who image from urban or backyard locations, seeing
problems also arise from sources close to the telescope. Heat
convection from hard ground surfaces or neighboring rooftops create
lower frequency "boiling" behavior that degrade guiding and imaging
performance. Ground-level heat can also create tube currents and
uneven layers of hot air inside the telescope tube - these also can
masquerade as low-frequency seeing effects. Users should do what
they can to avoid or mitigate these situations and, when working in
locations with high daytime temperatures, should expect it will take
many hours after sunset for the equipment temperatures to equilibrate.
The high-frequency, seeing-induced star motion seen by the
guide camera is strongly affected by the length of your guide exposure. Look at the following plot to see how the observed range
of guide star motion decreases as the exposure time is increased:
Essentially, the camera sensor is averaging the changing light pattern of the star and smoothing the result. Measurement uncertainty is still present because of under-sampling, but the longer exposures make it easier for PHD2 to isolate and identify the lower frequency errors that really can be improved through guiding. Obviously, there is a practical upper limit to the exposure time. Typically, it will be limited by the length of time your mount can run on its own without needing a correction. Small errors from periodic error, drift, flexure and other sources need to be corrected before they become large enough to ruin an image. Finding the right balance will always depend on both the seeing conditions and the quality of the equipment. As a starting point in PHD2, we typically recommend using exposure times of around 2 seconds and lower exposures of at least 0.5 sec only if the mount requires it and then only if guiding is active on multiple stars.
In order to reduce fixed-pattern noise
and hot pixels, imagers often move the telescope by very small amounts between
exposures – this is called dithering. Dithering is always controlled by the imaging
app because it is the only one that can suspend exposures with the main camera
while the pointing position is being shifted. PHD2’s only role in this is
to issue guide commands that will accomplish the requested shift in position –
it is simply doing that it’s told. The small shift in pointing position is accomplished by PHD2 in two steps:
1. Change the lock-point of the primary guide star by the
amount requested by the imaging app.
2.
Use the normal guiding routines to move the primary
guide star to the new lock-point
The size of the dither is controlled by the imaging
app, at least indirectly. The app may
let you specify the maximum size of a dither, typically in units of
pixels. In that case, PHD2 interprets this
as the upper range of random values between zero and this limit. The randomizing process is done to insure
that dithering doesn't follow a simplistic back-and-forth pattern or shift the
frame back to a location where it has previously been. For some applications that do
PHD2 dithering, you can't specify the maximum amount directly - you are perhaps
limited to choices like small/medium/large and the max dither amounts will have
preset values. For that reason, PHD2 has a dither scaling parameter in
the 'Global' tab of the Advanced Settings dialog. It is basically a
multiplier term that lets you adjust the range of dither amounts that are
possible. So a scale factor of 1 doesn't change the preset value at all,
a value of 10 multiplies it by 10X, etc. If you're using an app that lets
you specify the maximum amount directly (e.g. PHD_Dither), you should leave the
dither scale set to 1.0. Otherwise, you can adjust the scale factor if
you aren't happy with the overall range of dithering you're getting with one of
the small/medium/large choices..
It’s
up to the imaging app to determine
when the guiding has settled down and it’s time to start the next
exposure with the main camera. To make this easier for
authors of the imaging apps, PHD2 provides
some extra measurement information on how the settling process is
proceeding. This information doesn’t need to be used by the
imaging app,
it is entirely optional. In order to take advantage of this help,
the
imaging app specifies what level of stability it wants to see in order
to
decide that the dithering activity has settled down. There are
three
settling parameters for doing this:
1.
The maximum amount of guide star
position error that is considered acceptable – call that position tolerance, PT
2.
The length of time that must elapse during
which the guide star position error stays below the position tolerance – call
that the evaluation time, ET
3.
The maximum amount of time that can be tolerated
before the measurement process is terminated and the dither is declared to be
“done” regardless of the guiding stability – call that the time-out period, TO
To state this in a sentence, the
settling process is “done” when the guiding error is <= PT for ET
seconds or, if that condition is never satisfied, after TO seconds have
expired. When this evaluation process is complete, PHD2 sends a message
to the imaging app saying settling is done. This is all just extra credit
for PHD2, normal guiding is being done from the time the lock-point is moved.
Of course, the specification of these
parameters, PT, ET, and TO,
is up to you and the values
have to be chosen intelligently. Your imaging app may not expose all of
these parameters in its user interface or it may give them different
names. If you’re dithering by large amounts
with a low-performance mount, you have to expect it will take a long
time to
settle down. If you specify a PT value that is too large or an ET
value that is too small (overly lax parameters), the imaging app may start the
next exposure too soon and you could get streaked stars in the image. The same problem could occur if you specify a TO
value that is too short. Conversely, if you specify a PT value
that is too small or an ET value that is too long (overly demanding
parameters), then all of your dithers will incur a delay of TO
seconds and settling will "fail" – you are asking too much from
your mount. A sensible approach is to look at your past performance to
see how well your mount responds under typical seeing conditions with the size
of dithering you want to use. If your mount has a lot of Dec backlash,
you should see how long it takes for guiding to settle down when the direction
of the Dec guide command is reversed. The ET and PT values
should reflect the guiding performance you normally get with your setup with a
little bit of slack to avoid wasting time.
PHD2 also supports different choices
for how the star is moved in RA and Dec.
With the default settings, the mount will be shifted in RA and Dec by
different random amounts as described earlier.
If you choose “spiral mode”, the guide star will be moved in a pattern
that eventually produces a spiral pattern around the original lock-point. This automatically reduces the number of Dec
reversals and can be a good choice if your mount has substantial backlash. In
this mode, there is no randomizing process involved, each dither has the size
specified by the imaging app. Alternatively,
you can choose the RA-only option and eliminate Dec reversals altogether, but
this may not be a good choice if your imaging camera has a lot of fixed-pattern
noise.
If your mount has a substantial amount of declination backlash in the mount, you may be guiding in only the north or south Dec direction. If PHD2 receives a command to dither in declination while you're operating in this mode, it will temporarily allow guiding in both Dec directions until the dither and settling are completed. It will then revert to the original north/south-only guiding mode. If you don't want this behavior, you should restrict dithering to 'RA-only'. All of the PHD2 dither controls are contained on the 'Global' tab of the Advanced Settings dialog.
Periodic error is most often caused by very small machining errors in the various components of the RA drive system. One part of a typical drive system is shown here:
Credit: Mathis Instruments
A high-precision worm gear (arrow 1) is used to drive the
much larger worm wheel (arrow 2). The
latter is attached to the RA shaft and when the mount is tracking at the
sidereal rate, the worm wheel will complete a rotation in one sidereal day
(23.934 hours). In order for this
tracking to be perfect, all the following conditions must be met:
Identical pitch and spacing for every thread in the worm gear
Rigid attachment of the worm gear to the mounting plate with
no flexure or movement of the gear or the mounting blocks
Identical shape and spacing of every tooth in the worm wheel
Worm wheel perfectly round and perfectly centered on its
axis of rotation
These are actually just a few of the necessary conditions, but it’s obvious that this level of precision is not likely to be present in most amateur mounts. The machining of the worm gear is usually the biggest challenge so tracking errors often originate there. The worm gear turns at a constant rate during sidereal tracking and the time it takes to make one full revolution is called the “worm period”. Worm periods vary among different mounts but generally fall in the range of 4 to 10 minutes. A machining inaccuracy on one of the worm threads will therefore make its presence known once in every worm period. Of course, many of the worm gear threads are likely to have some inaccuracies and each will make its own contribution to tracking error once during the worm period. When the tracking error is graphed over a single worm period, the result is usually a curve that is roughly sinusoidal with varying slopes, peaks, and valleys – this is what is known as periodic error. Here’s an example:
Notice the high-frequency movements caused by seeing that
are not part of the mechanical periodic error.
There are other gears in the RA system, often a series of
gears that lie between the motor and the worm gear. These are required to convert from the native
speed of the motor to the slower rotation speed of the worm gear and also to
generate the torque needed to drive the worm gear. Each of these components will have machining
inaccuracies of its own and will contribute to cumulative tracking errors of
the mount. Many of these components will
introduce errors on shorter time periods than the worm period. Some mounts use drive belts to sidestep some
of these “upstream” gear inaccuracies but those can introduce errors of their
own – incorrect tensioning, lateral movement of the belt on spindles, etc.
Periodic error correction (PEC) in the mount firmware is beneficial to auto-guiding if the feature is implemented correctly. Unfortunately, this isn’t always the case. But when done correctly, periodic error correction handles some tracking errors before they are seen in the guide camera image. These corrections are predictive, based on a model of the mount’s PE, as opposed to being reactive like normal auto-guiding. The net result is that PHD2 has less work to do to keep the RA axis on-target. Even when the implementation in the mount is done well, calculation of a high-quality PEC curve must be done carefully using an application specific to the purpose. During the measurement process, the app must filter out seeing-induced guide star movements to produce a smooth correction curve that represents samples across multiple worm periods. It must also be aware of the worm period and the various harmonics in the mount drive system in order to apply corrections only for those tracking errors that are harmonic - i.e. errors with frequencies that are integer multiples of the worm frequency. If the PE correction curve is poorly constructed, the RA tracking can be worse than using no PEC at all.
If PEC isn't available for your mount or is badly implemented, you can use the PPEC guide algorithm in PHD2. PHD2 Predictive PEC
Backlash can occur when the direction of motion on an axis is reversed. The telescope may not immediately start moving in the reverse direction even though the motor is turning. The usual cause is loose meshing of the gears in the drive train. For auto-guiding, this problem doesn't affect guiding in RA because the RA drive system is continuously moving the axis west as it tracks the sky - it never reverses direction because of guiding. But it is a common source of trouble for Declination because the Dec axis is mostly idle during guiding, running only in short bursts in response to guide commands to move the scope north or south..  In the diagram above, assume the bottom gear is the drive gear currently rotating counter-clockwise. The teeth on the drive gear are in contact with the teeth on the driven gear above it and the latter is being driven clockwise. But the arrows show that the surface on the trailing edge of the drive gear tooth is not touching the matching tooth on the driven gear - there is a small gap. So when the drive gear reverses direction, there will be a short period of time before the gears are fully meshed and the driven gear starts turning in the opposite direction. The "reversal delay" in this case is caused by simple backlash. Some amount of gap is generally required to avoid binding in the gear system and to allow room for lubricant and thermal expansion. When the mesh is too tight, the axis may exhibit stiction (static friction), a situation where the axis will not move smoothly and freely or is difficult to get moving from a stationary state. Stiction on the Dec axis can result in a pattern of an initial reversal delay that looks like backlash followed by a large over-shoot once the axis finally starts moving. Other than mistakenly having backlash compensation enabled in the mount software, stiction is the most common cause of oscillations in Dec guiding.
The Guiding Assistant will measure how the Dec axis behaves when it is forced to reverse direction. It is only capable of measuring the "reversal delay", the amount of time it takes to change direction and get the axis rotating at the expected rate. It isn't always possible to distinguish whether the problem is backlash, stiction, or both; but the graph produced by the GA can often provide clues. This behavior can also be seen during normal guiding sessions that don't employ the large guide pulses used by the GA. If the reversal delay is large, say above 3 seconds, it's probably best to try adjusting the Dec drive system. If the delay is less than that, the PHD2 Dec Backlash Compensation feature will probably be able to handle Dec reversals fairly well. Note that the amount of delay is inversely proportional to the guide speed in the mount - as the guide speed is increased, the reversal delay decreases. This is one of the reasons we recommend using guide speeds of at least 0.5x sidereal.
The reversal delay is usually not a constant value for the mount. Instead, it often depends on the pointing position of the scope and the balance of the scope on the Dec axis. As mounts age, the gears wear and for Dec, the wear will be greatest where the scope spends most of its time during imaging. For northern observers, that is probably in the Dec range of 0 to 40 degrees. With older mounts especially, the reversal delay can be quite different in those pointing positions than, for example, regions closer to the pole. This is another reason why the PHD2 Backlash Compensation feature is a better choice than any fixed-size compensation that is programmed in the mount controller.
Mounts with very accurate absolute encoders and detailed
pointing models often allow imaging without any guiding at all. But there are limitations to how long this
can be done without needing some guiding corrections. The goal in this scenario is to provide a “backup”
guiding mechanism that won’t conflict with the inputs from encoders and
pointing models and will still improve the overall result. The recommended strategy for accomplishing
this is as follows:
1.
Keep the frequency of guide commands as low as possible.
These mounts can actually be quite “busy” with corrections coming from encoders
and fine-grained pointing models, none of which are visible to ASCOM applications.
A slow guiding frequency will minimze the potential for creating instabilities in
these functions from external guide commands.
2.
Be especially carefully to avoid chasing the seeing – this is most easily
done by using moderate-length or long guide camera exposures and generous
min-move settings.
In previous PHD2 releases, users have been able to approximate
this approach by using exposures in the 4-8 second range, coupled with a
non-zero “time lapse” delay. The latter simply imposes a fixed delay
between the completion of the last guide command and the start of the next
guide camera exposure. The downside of this approach is that operations
other than steady-state guiding – things like looping, star selection,
calibrating, dithering and settling, etc. – are unnecessarily slowed by the
time-lapse value. The “variable delay” feature eliminates this problem by
letting the user specify two different delay values:
1.
A “short” delay that will be used for any activity other
than
steady-state guiding. This might be zero but at least for some
mounts, it should be non-zero to allow time for the encoders to finish
their
corrections. Values above 1 second are probably unnecessary.
2.
A “long” delay that will be used for the normal frame-frame guiding that
is typical of steady-state, long-exposure imaging. This is the value, in addition to
the camera exposure time, that controls the “cadence” of the guiding.
To give an example, you might use camera exposures of 4 seconds, a “short” delay of 1 second, and a “long” delay of 4 seconds. The 4-second exposure time will provide good suppression of seeing-related effects and the sum of (4+4) seconds results in a steady 8-second guiding cadence for most of the imaging session. At the same time, the dither settling times will benefit from the short (4+1) second delays between camera exposures.
Any telescope/camera combination is going to flex and sag in
various ways as it tracks an object in the sky – that’s just a consequence of
gravity and physics. In fact, each
individual component is going to exhibit its own unique behavior in this regard
depending on its mass and how it’s attached to its neighboring components. Especially with larger scopes and heavier
cameras, the amount of flexure can be significant, keeping in mind that guiding
is dealing in units of a small number of microns. Since we aren’t generally familiar with
dimensions this small, it’s useful to remember that a human hair is roughly 50
microns thick, roughly 10x larger than most guiding corrections.
When a separate guide scope is being used in addition to the
imaging scope, each unit will flex and shift independently – this is called
differential flexure. If PHD2 is using
the separate guide scope, it will only see and correct for the movements of the
guide scope/camera, the differential movements of the imaging scope/camera are
invisible. This can lead to a fairly
common and frustrating problem where the guiding results are excellent but the
stars taken through the main camera are elongated.

For imaging scopes with focal lengths of 1800mm or greater, differential
flexure is usually a problem unless the main-camera exposures are kept fairly short. There’s no way to predict this because there
are simply too many mechanical interface points that can move around – movable
SCT mirrors, all the connectors between the cameras and their focusers, the
focusers themselves, all the thumb-screw fasteners in the system, the mounting
ring arrangement for the guide scope, etc. The typical solution is to eliminate the
dual-scope setup and use an off-axis-guider (OAG) on the imaging scope. This allows PHD2 to “see” all the movements,
mechanical or otherwise, that will affect the main-camera images. In the early days, OAGs were often difficult
to use because their fields of view were small and usable guide stars were hard
to find. With the current generation of
guide cameras and their large, highly sensitive sensors, most of these problems
are a thing of the past.
If you have a situation where you frequently have elongated stars but the guiding results show reasonably similar results for both Dec and RA, you should suspect differential flexure. You can usually verify this fairly easily with a simple test. Using the main camera, with guiding active, find the largest exposure time that still has acceptably round stars. Then capture a sequence of perhaps 10-20 images at that exposure time. Using an app that is capable of displaying that image set, “blink” through the images in the order they were captured. You will usually see a consistent offset of the stars in each image relative to the previous image – the stars will appear to “march” in a particular direction as you cycle through the image set. Alternatively, you can simply stack all the images without first aligning them to see the star elongation emerge.
Generally
speaking, amateur-grade adaptive/active optics (AO) devices can only
deal with some of the problems that create imperfect guiding.
AO’s can usually mask or at least improve the behavior of an
under-performing mount because most of the guiding adjustments are
accomplished by moving a small tip-tilt optical element – not 70 pounds
of telescope gear. Basically, the mount is rarely asked to do
anything beyond basic sidereal tracking. Problems with backlash,
stiction, and periodic error are mostly masked with AO use. In
addition, because an AO is inherently an off-axis-guider, it also
eliminates differential flexure problems. These are significant
benefits and explain why many serious imagers use AO’s.
What
an AO can’t eliminate is guide star movement due to seeing, at least
not under normal conditions. Guide star movement due to upper
atmosphere seeing occurs at frequencies of at least 100s/sec and it
isn’t usually practical to find guide stars that can be measured that
rapidly. If you attempt to run the AO at such high rates you will have
two problems: 1) Any available guide stars will probably have low SNR
values, and the calculation of their positions will degrade
proportionately; and 2) you will under-sample the seeing
deflections. The latter situation results in “aliasing”,
resulting in guide commands that are invariably incorrect and likely to
make things even worse. For these reasons, AO users are still
advised to use exposure times of no less than 0.5 second to avoid
chasing the seeing. The goal with AO guiding is really to make
the mount “look” better than it really is in terms of tracking accuracy
and responsiveness. If your imaging isn't limited by mount
performance, an AO is not likely to provide much benefit.
AO
guiding usually involves guide commands being directed, at times, to
both the AO and the mount. The commands are sent only to the AO
so long as the guide corrections don’t exceed the physical limits of
the tip-tilt element. As this limit is approached, “bump” guide
commands are sent to the mount to help restore the primary guide star
to a more central position of the tip-tilt element. This can
happen to correct for polar alignment drift, large guiding excursions
arising from external problems (e.g. cable snags) or for large
dithers. An explanation of how these guide commands are “blended”
is provided in the Advanced Settings/AO Parameters section of the
manual. AO Parameters
One of the most common responses to a request for support in the PHD2 Forum is: please upgrade to the latest version and see if the problem still exists. If you are seeing an issue in an older version of PHD2 it is quite likely that you are not the first person to encounter it, and it has already been discovered and fixed in a newer version of PHD2. For this reason, the developers of PHD2 feel that it is important to be running the most up-to-date version of the program.
Updating a program that you rely on for unattended imaging can sometimes be perceived as a risky proposition. The developers of PHD2 recognize this sentiment--we are imagers too! There is a necessary trade-off between maintaining a stable software installation and staying current with the latest bug fixes and other improvements. In some cases, camera vendors will issue "breaking" changes to their software drivers and SDKs, often because they have introduced a new camera model. This poses a problem for us because we are forced to update the camera SDK in order to support the new camera. But this also means that current users may encounter problems with a camera and drivers that have been working well, something that can only be corrected by upgrading to the latest camera drivers and the latest version of PHD2.
PHD2 achieves a balance between these two opposing needs by publishing two series of software releases. The development releases contain the latest ongoing bug fixes and feature improvements and are tested by the developers--usually during actual imaging time--before being released. Users who choose to run the development releases will get the latest bug fixes and newest features. Development releases have names like "2.6.3dev6" indicating, for example, the 6th development release after the 2.6.3 major release.
Periodically, after a development release has received more test time, it will be published as a major release. For example, 2.6.3dev6 could be published as major release 2.6.4.
PHD2 has an option to automatically check for software updates. We recommend enabling this option to help keep your version of PHD2 up to date. When the automatic check option is enabled, PHD2 will check for updates in the background when PHD2 starts. If new updates are available, PHD2 will give you the option to install the new version. Enabling the automatic check for updates will not interfere with the ordinary operation of PHD2, including automated operation. It is also safe to leave the option enabled if you are imaging in the field without internet connectivity. If PHD2 cannot check for updates, it will wait until the next time it is started before trying to check again.
Regardless of whether you allow PHD2 to automatically check for updates at startup, you can always manually check for updates by clicking "Check for updates" from the Help menu.


options.h
GitHub: base/options.h base/options.cc
Top-level Functions
default_options()
namespace base { Options default_options(); }
RC. Returns the global default options. Thread-safe.
set_default_options()
namespace base { void set_default_options(Options opts); }
RC. Replaces the global default options. Thread-safe, although there's no means provided to do atomic read-modify-writes.
OptionsType
namespace base { struct OptionsType {}; }
RC. Inheriting from this empty base class marks the subclass as being
safe and appropriate to store in a base::Options
.
In the strictest sense, there are only two hard requirements for inheriting from this class: your subclass is default constructible, and your subclass is copy constructible.
Options
namespace base { class Options { public: Options(); Options(const Options& other); Options(Options&& other) noexcept; Options& operator=(const Options& other); Options& operator=(Options&& other) noexcept; template <typename T> T& get(); template <typename T> const T& get() const; template <typename T> operator T&(); template <typename T> operator const T&() const; }; }
RC. Holds various option classes in a type-safe extensible container. It can hold one instance of each option class.
Options::Options()
Constructs a base::Options
value.
- The default constructor creates a new set of options, all with their default values.
- The copy constructor creates a new set of options, initially having the same values as the copied-from options but thereafter independent.
- The move constructor creates a new set of options, taking on the values of the moved-from options, and leaving the moved-from options in the default-constructed state.
Options::operator=()
Assigns to a base::Options
value. The copy and move
assignment operators work analogously to their respective
constructors.
Options::get()
Retrieves the value for the template-provided
base::OptionsType
subclass.
(If no such subclass is yet known to this instance, then a subclass instance is transparently constructed and returned.)
Options::operator T&()
Convenience alias for Options::get().


Data (data.R)¶
Loads data sets available for use. These include:
"gene_set"
: These are a collection of gene sets as used in the Lamb 2006 CMap paper."cdesc_char"
: An example table of metadata, as would be parsed from a text file or using parse.gctx.Warning
Initially, all columns are of type character.
"ds"
: An example of a GCT object with row and column data, and gene expression values in the matrix.


On 7 December 2017, 11 new articles were published in 8 journals.
Extended Suicide: Public Tragedy
Section 44: Is This Provision in Mental Health Legislation in England and Wales Obsolete?
Victim Compensation For Acts of Terrorism and the Limits of the State
Self-Control, Parental Crime, and Discipline Across Three Generations
Hybrids: on the Crime–terror Nexus
Effects of Mental Strength Training For Police Officers: A Three-Wave Quasi-Experimental Study
Reality Versus Perception: Toward Understanding Boko Haram in Nigeria
Note: although this article was published on 9 November 2017, the publisher only added it to the journal RSS feed on 7 December 2017, which is why it is shown in the list of articles for that date.
Note: although this article was published on 13 November 2017, the publisher only added it to the journal RSS feed on 7 December 2017, which is why it is shown in the list of articles for that date.


Flyers-Panthers Sums
by EndPlayFirst Period_1, Philadelphia, Sanheim 2 (Myers, Hayes), 6:26. 2, Florida, Sceviour 2 (Matheson, Connolly), 10:38. 3, Florida, Connolly 8 (Trocheck), 12:30. Penalties_Trocheck, FLA, (tripping), 19:24.
Second Period_4, Florida, Barkov 7 (Brown, Dadonov), 6:46. 5, Florida, Huberdeau 10 (Dadonov, Barkov), 10:23. 6, Philadelphia, Frost 1 (Konecny), 14:20. Penalties_Gostisbehere, PHI, (high sticking), 11:35; Huberdeau, FLA, (cross checking), 16:56; Myers, PHI, (cross checking), 16:56; Myers, PHI, served by van Riemsdyk, major (high sticking), 16:56.
Third Period_7, Florida, Hoffman 9, 17:28. Penalties_Hoffman, FLA, (high sticking), 6:58.
Shots on Goal_Philadelphia 13-10-14_37. Florida 11-10-5_26.
Power-play opportunities_Philadelphia 0 of 2; Florida 0 of 4.
Goalies_Philadelphia, Hart 6-5-2 (18 shots-14 saves), Elliott 4-2-2 (7-7). Florida, Bobrovsky 8-4-4 (37-35).
A_11,515 (19,250). T_2:24.
Referees_Jean Hebert, Kelly Sutherland. Linesmen_Darren Gibbs, Jesse Marquis.


Tory and Labour MP caught having backstage face off after leaders’ debate
Foreign secretary Dominic Raab and Labour MP Andy McDonald had an angry clash in the media room of the BBC Question Time debate when cameras were still rolling.
The pair were caught scrapping over Islamophobia and anti-semitism during a live TV interview on Sky News.
What started as a disagreement over Boris Johnson’s Brexit deal descended into a heated argument over racism in both parties.
As cameras prepared to cut away but the pair could be heard continuing their argument in the background – drawing attention to them both.
Mr McDonald accused the Conservatives of ‘kicking it into the long grass’ over racism in the party.
The Shadow Transport Secretary said the Tories should be having an independent inquiry into Islamophobia, telling Raab ‘Listen to Baroness Warsi’.
Advertisement Advertisement
Ms Warsi, a senior Muslim Tory peer, has repeatedly criticised her own party for failing to get to grips with Islamophobia.
But Mr Raab hit back, saying: ‘Two parties in this country’s history have been investigated by the Equalities and Human Rights Commission – Labour under Corbyn and the BNP.’
The heated exchange ended with Mr McDonald jabbing his finger towards the Tory minister, repeating: ‘You should be doing it. You should be doing it.’
He fumed ‘You should be following Baroness Warsi and you should have your commission.’
Mr Raab walked off before cameras cut.
The tense exchange followed a two hour special that saw the four main parties leaders face a grilling from a BBC Question Time audience.
Both Jeremy Corbyn and Boris Johnson faced questions about racism in their parties during the special debate.
Corbyn was asked about his failure to intervene at a press conference to protect the Jewish Labour MP Ruth Smeeth from a heckler who was later kicked out of the party.
The Labour leader said he’d had many discussions with his colleague on the matter since then, adding: ‘Nobody should suffer any abuse in public life or privately’.
He continued to be grilled on his failure to tackle antisemitism by the same audience member, who asked how he felt about an investigation by the Equalities and Human Rights Commission into his party’s process for handling antisemitism complaints.
Corybn said he ‘welcomed the investigation’ and said the party had ‘placed ourselves completely open’.
Advertisement Advertisement
The Labour leader’s record on fighting racism was later defended during Jo Swinson’s ‘car crash’ interview, where she faced criticism for attacking Labour rather than focusing on her own policies.
An audience member criticised the Lib Dem leader for branding Corbyn anti-Semitic, and told her: ‘Jeremy Corbyn has been fighting racism since before you were born’.
Meanwhile, Boris Johnson has faced criticism for once again refusing to apolgosie for notorious comments comparing Muslim women to letterboxes.
He defended his ‘right to speak out’ and said he was making a liberal case for women being able to wear what they want.
Got a story for Metro.co.uk?
Get in touch with our news team by emailing us at<EMAIL_ADDRESS>For more stories like this, check our news page.


/*
* Copyright (c) 2009 Marco Peereboom<EMAIL_ADDRESS>* Copyright (c) 2009 Ryan McBride<EMAIL_ADDRESS>*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
 IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
Additionally, much code in scrotwm.c comes from dwm under the following license:
/*
* Much code and ideas taken from dwm under the following license:
* MIT/X Consortium License
*
* 2006-2008 Anselm R Garbe <garbeam at gmail dot com>
* 2006-2007 Sander van Dijk <a dot h dot vandijk at gmail dot com>
* 2006-2007 Jukka Salmi <jukka at salmi dot ch>
* 2007 Premysl Hruby <dfenze at gmail dot com>
* 2007 Szabolcs Nagy <nszabolcs at gmail dot com>
* 2007 Christof Musik <christof at sendfax dot de>
* 2007-2008 Enno Gottox Boland <gottox at s01 dot de>
* 2007-2008 Peter Hartlich <sgkkr at hartlich dot com>
* 2008 Martin Hurton <martin dot hurton at gmail dot com>
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*/
Finally, The LD_PRELOAD hack in lib/swm_hack.c comes from e16, licensed as follows:
/*
* Copyright (C) 2005-2007 Carsten Haitzler
* Copyright (C) 2006-2007 Kim Woelders
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to
* deal in the Software without restriction, including without limitation the
* rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies of the Software, its documentation and marketing & publicity
* materials, and acknowledgment shall be given in the documentation, materials
* and software packages that this Software was used.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
* IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
$scrotwm: license.html,v 1.2 2009/02/01 07:42:12 mcbride Exp $


“开始的时候，我们团队没有一个成员了解 Go，但是一个月后，我们每个人都开始用 Go 写代码，我们当时正在构建终端服务。正是 Go 的灵活性、易用性及其一流的理念（Go 如何处理本机并发、垃圾回收，当然还有安全性和运行速度）等在构建过程中帮了我们。毕竟，谁能战胜这只可爱的吉祥物呢！”
“一门快速编译的小巧语言会创造一个快乐的开发者。 Go 语言很小，编译速度很快，因此你可以把精力更多集中在实际的问题上，而不必在意解决问题的工具。编码、测试以及调试周期是如此之快，以至于让你误以为自己在使用解释型语言。看下你的代码，你会发现有更少的重复代码（boilerplate）以及更多的业务逻辑。”
“Go 语言有出色的可伸缩特性，用 Go 写的服务通常占用很小的内存。因为代码会编译成单个静态二进制文件，服务也可以轻松地进行容器化，所以构建和部署也就更加简单。所有这些特性使得 Go 成为构建微服务的理想选择, 因为你可以轻松地将其部署到 Kubernetes 等高可用和可伸缩的环境中。”
With fast build times, lean syntax, an automatic formatter and doc generator, Go is built to support both DevOps and SRE.
“I started writing in Go when I was just out of college and couldn’t believe how quickly I picked it up, especially compared to other languages. I had spent months learning about how to build APIs in other languages (and mostly failing), but after a week of writing Go, I had completed my first API.”
Nov 15, 2019
Leipzig, Germany
We enjoy using Go and we are curious about the language, its
features and applications, especially in the context of cloud
computing and infrastructure.
Our goal is to establish a place, where people from all
backgrounds interested in the Go programming language and various
cloud technologies can meet, learn, share experiences, present,
discuss and network.
We aim to be a welcoming community, respecting Gopher values, as
outlined here:
https://golang.org/conduct.
Find out more on:
https://golangleipzig.space/
and
https://github.com/golang-leipzig
Since March 2019, we are part of the Go Developer Network:
https://blog.golang.org/go-developer-network
Nov 16, 2019
Gurgaon, India
This group is for people interested in learning both the
programming language Go(lang), and how to build interesting things
with it. We will aim the first few sessions at
beginner-intermediate levels and maybe later introduce some
high-level talks.
WE ARE ACTIVELY LOOKING FOR MEETUP VENUES.
Want to help organise/volunteer? - Find something to do at
https://trello.com/b/qozwyn8D
and reach out to me.
Also, meet fellow gophers on
Slack.
Nov 16, 2019
Curitiba, Brazil
Esse é o chapter de Curitiba do Women Who Go, um grupo que reúne
mulheres e outras minorias de gênero pra estudar a linguagem de
programação chamada Go.
Queremos construir uma comunidade de Golang mais diversa.


Skip to restaurants list
Restaurant Reviews
Best restaurants in your area
Filter Results
All Neighborhoods
All Cuisines
Restaurants in neighborhoods


Fiona was born and raised in Taiwan, after living there for fourteen years she set out to experience a different culture and moved to the United States. She resided in Tennesse where she attended High School. After High School Fiona moved to San Deigo to pursue a degree in Cognitive Science & Pyschology at the University of California in San Deigo. She speaks fluent English & Mandarin, and is currently learning Spanish. After graduating college, Fiona desires to work in UI/UX, travel the world with Shrek.
Raised in the Philippines, Britt Johnson has traveled a bit. She attended Princeton, achieving a degree in the History of Science and Technology. Tackling JavaScript is helping her improve her coding skills (along with Python coding), and she hopes to be a full-stack developer. Britt now resides in Seattle, Washington, and she loves working with and helping people, which feeds her 2nd job at saving the world one code at a time. She also loves her partner and three black cats - like - a lot.
Tian was born and raised in Tulsa, Oklahoma where she lived for 17. Upon moving to Stillwater, Ok she attented Oklahoma State University where she obtained a Bachelors degree in University Studies and Health Education and Promotion. Traveling the world she landed in Seattle, Washington where she lives now, fulfilling her dream of helping others find their passion, pursuing their dreams and reaching goals. As a motivational speaker Tian wants to spread Thunder knowledge in a Supersonic land.


--- layout: page title: "Thanks" header-img: "img/post-bg-rwd.jpg" ---
BY blog template.
Thomas Hardy's free responsive HTML/CSS3 CV template.


Oh onion! Disorder, scuffles, irregularities mar TCB sale in Dhaka
by bdnews24.comConsumers in Dhaka are swooping down on trucks used by dealers of the Trading Corporation of Bangladesh or TCB to sell onion at fair price in an effort to ease skyrocketing prices.
The dealers appeared unprepared for the huge crowds as scuffles, disorder and irregularities marred the sale at different points.
bdnews24.com visited Kachukhet, Mirpur-10 and Khamarbari intersection of Farmgate where people scrambled for onion when the TCB dealers arrived with loaded trucks.
Most disorder occurred at Kachukhet where many customers alleged they failed to get any onion after waiting in long queues for hours from as early as 9am.
But some were still buying onion at noon by breaking the queues and getting into the disorderly crowd created at the front of the lines.
Influential people of the neighbourhood and some policemen were buying onion from the sides of the truck, skipping the long queues, and more than once, which was prohibited.
The customers are allowed only one kg at Tk 45 by the TCB as prices have shot up in the market following a supply squeeze across South Asia due to bad weather leading to a drop in production.
“We are trying our best, but the people themselves are creating trouble,” one of the men selling TCB onion at Kachukhet said.
They stopped selling to women when the disorder reached the peak in the queues for the female customers.
One of them, Sathi Akter, jumped onto the truck at the time and tried to bring order to the queue for half an hour in a failed attempt.
She pointed the finger at the sellers for the disorder.
“They knew this will happen, then why haven’t they taken measures?” she asked.
Customers at Mirpur-10 started an altercation with the sellers when a traffic policeman collected 5 kg onion by skipping the queues.
TCB spokesman Humayun Kabir told bdnews24.com they had raised the issue of disorder at a meeting on coordination.
“Dhaka Metropolitan Police were given a list of the 35 points of TCB onion sale and asked to take measures as we don’t have enough manpower to keep order,” he said.


class FileManager
File Manager
Methods
|
__construct(array $supportedFileModels)
Create a new FileManager instance. |
||
| FileModelInterface |
getModelInstance(string $fileType, string $parentType)
Create a new FileModelInterface instance, from the supportedFileModels table |
|
|
addFileModel(string $fileType, string $parentType, string $fullyQualifiedClassName)
A a new FileModelInterface class name to the supported class list. |
||
| UploadedFile |
copyUploadedFile(FileModelInterface $model, UploadedFile $uploadedFile)
Copy UploadedFile into the server storage directory |
|
| int |
saveImage(ImageCreateOrUpdateEvent $event, FileModelInterface $imageModel)
Save file into the database |
|
| int |
saveDocument(DocumentCreateOrUpdateEvent $event, FileModelInterface $documentModel)
Save file into the database |
|
| string |
sanitizeFileName(string $string)
Sanitizes a filename replacing whitespace with dashes |
|
|
deleteFile(FileModelInterface $model)
Delete image from file storage and database |
||
| string |
renameFile(int $modelId, UploadedFile $uploadedFile)
Rename file with image model id |
|
| bool |
isImage(string $mimeType)
Check if a file is an image Check based on mime type |
Details
at line 37
public
__construct(array $supportedFileModels)
Create a new FileManager instance.
at line 63
public FileModelInterface
getModelInstance(string $fileType, string $parentType)
Create a new FileModelInterface instance, from the supportedFileModels table
at line 93
public
addFileModel(string $fileType, string $parentType, string $fullyQualifiedClassName)
A a new FileModelInterface class name to the supported class list.
at line 107
public UploadedFile
copyUploadedFile(FileModelInterface $model, UploadedFile $uploadedFile)
Copy UploadedFile into the server storage directory
at line 174
public int
saveImage(ImageCreateOrUpdateEvent $event, FileModelInterface $imageModel)
Save file into the database
at line 187
public int
saveDocument(DocumentCreateOrUpdateEvent $event, FileModelInterface $documentModel)
Save file into the database
at line 203
public string
sanitizeFileName(string $string)
Sanitizes a filename replacing whitespace with dashes
Removes special characters that are illegal in filenames on certain operating systems and special characters requiring special escaping to manipulate at the command line.
at line 213
public
deleteFile(FileModelInterface $model)
Delete image from file storage and database
at line 230
public string
renameFile(int $modelId, UploadedFile $uploadedFile)
Rename file with image model id
at line 255
public bool
isImage(string $mimeType)
Check if a file is an image Check based on mime type


The AnkhSVN project provides Daily builds of the current development tree. These versions are not tested, but may contain bugfixes (and new bugs) that are not in released versions.
You can find a list of changes and the last daily build on our daily update(d) page.


{% extends "templates/partials/base.html" %} {% block title %}{% parent %} - Homepage{% endblock %} {% block content %}
Whether you like to drink it, smoke it, eat it, or rub it on your face—we’ve got everything you (or your lady friend!) need to experience your green with high style. Consider it your summer survival pack.
Enter by August 10, 2017 to be in the draw.
By entering the sweepstakes, I agree that I am over 18+. I also agree to receive email communication and special offers from the featured brands.


book
Hello Books
Home
Login
Sign Up
Library
<
Home
Login
Sign Up
Library
more_vert
Hello Reader
Welcome home avid reader
Sign Up
Already have an account?
Login Here


 Add extra chilli if you like.
294 calories per portion (without rice)
Cut each chicken breast into eight or nine bite-sized pieces, season with black pepper and put them in a non-metallic bowl. Stir in the yoghurt, cover with cling film and chill for a minimum of 30 minutes but ideally 2–6 hours.
Heat the oil in a large, non-stick saucepan and add the onions, garlic and ginger. Cover and cook over a low heat for 15 minutes until very soft and lightly coloured. Stir the onions occasionally so they don’t start to stick.
Once the onions are softened, stir in the crushed cardamom seeds, cumin, coriander, turmeric, chilli powder and bay leaf. Pinch off the ends of the cloves into the pan and throw away the stalks. Cook the spices with the onions for five minutes, stirring constantly.
Stir in the flour, saffron, sugar and ½ teaspoon of salt, then slowly pour 300ml/½ pint cold water into the pan, stirring constantly.
Bring to a gentle simmer, then cover and cook for 10 minutes, stirring occasionally.
Remove the pan from the heat, take out the bay leaf and blend the onion mixture with a stick blender until it is as smooth as possible. You can do this in a food processor if you prefer, but let the mixture cool slightly first.
The sauce can now be used right away or cooled, covered and chilled until 10 minutes before serving.
Drain the chicken in a colander over the sink, shaking it a few times – you want the meat to have just a light coating of yoghurt.
Place a non-stick frying pan on the heat, add the sauce and bring it to a simmer.
Add the chicken pieces and cream and cook for about 10 minutes or until the chicken is tender and cooked through, stirring regularly. Exactly how long the chicken takes will depend on the size of your pieces, so check a piece after eight minutes – there should be no pink remaining.
Adjust the seasoning to taste, spoon into a warmed serving dish and serve garnished with fresh coriander if you like.


- getContent(WebClient, String, String) - Method in class Snapshotter
-
Get the content of a url
- getCustomChildren(Boolean) - Method in class CustomElement
-
Return a list of the children, as CustomElements instead of Elements.
- getCustomParentElement() - Method in class CustomElement
-
Get the parent elements as CustomElement
- getCustomText() - Method in class CustomElement
-
- getKey() - Method in class EditAction
-
- getKeyLists() - Method in class AttributeDiffer
-
Initialise lists
- getKeyLists() - Method in class StyleDiffer
-
Initialise lists
- getLinks() - Method in class Snapshotter
-
Get all links present at ud, after login in at ul
- getMatchingBlocks(int, int, int, int) - Method in class SequenceMatcher
-
Get all matching blocks in a.substring(alo, ahi) and b.substring(blo, bhi)
- getNewParent() - Method in class EditAction
-
- getNrOfLeafsInSubtree() - Method in class CustomElement
-
Return the number of leafs in the subtree rooted at this node
- getOpcodes() - Method in class SequenceMatcher
-
Get the opcodes to rewrite a to b.
- getPartner() - Method in class Partner
-
- getPosition() - Method in class EditAction
-
- getPositionInParent() - Method in class CustomElement
-
Return the index of this CustomElement in its parent, taking into account deleted children as well.
- getRoot() - Method in class TreeEditor
-
- getSimilarity() - Method in class Partner
-
- getSimilarityMultiplier(CustomElement, CustomElement, HashMap<CustomElement, Partner>) - Static method in class SimilarityCalculator
-
Define a multiplier which increases the similarity by use of several heuristics
Todo: Add more cases for the multiplier
- getStyleAttributes() - Method in class CustomElement
-
- getStyleType() - Method in class EditStyleAction
-
- getTail() - Method in class CustomElement
-
- getTarget() - Method in class EditAction
-
- getType() - Method in class EditAction
-
- getValue() - Method in class EditAction
-


Recently published scripts
{% include /ui/recent-scripts.html %}
Recently pitched scripts
{% include /ui/recent-scripts-pitched.html %}


URL Shortener Microservice
Here are the specific user stories that are implemented for
this project:
- User Story: I can pass a URL as a parameter and I will
receive a shortened URL in the JSON response.
- User Story: If I pass an invalid URL that doesn't follow
the valid http://www.example.com format, the JSON response will
contain an error instead.
- User Story: When I visit that shortened URL, it will
redirect me to my original link.
Here are some examples:
-
https://dmanley-fcc-urlclipper.herokuapp.com/new/https://www.google.com
-
https://dmanley-fcc-urlclipper.herokuapp.com/new/http://www.yahoo.com (which returns)
{"original_url":"http://www.yahoo.com","short_id":"c","comment":"this service is something like a bookmark"}
- https://dmanley-fcc-urlclipper.herokuapp.com/c (which returns)
(Yahoo.com page)


AP Top International News at 4:00 a.m. EST
by EndPlayHong Kong police battle protesters trying to escape arrest
Gotabaya Rajapaksa sworn in as Sri Lanka's new president
North Korea says it won't give Trump a summit for free
Iran's top leader warns ‘thugs' as protests reach 100 cities
UK media: Prince Andrew's sex claims rebuttal a PR disaster
The Latest: China editor says HK police should use live ammo
Leaked Russian interference report raises UK vote questions
3rd record tide enters Venice as Italy hit with snow, rain


| Interface | Description |
|---|---|
| AnimatableItem |
Interface used to expose a limited API to the animations package.
|
| BatchedStateUpdatesStrategy |
A Batched State Update Strategy will define when do we schedule a final state update and
corresponding layout calculation, so that we can enqueue the most reasonable number of state
updates without incurring with an excessive number of layout calculations.
|
| CalculationStateContext | |
| Component.RenderData |
A per-Component-class data structure to keep track of some of the last mounted @Prop/@State
params a component was rendered with.
|
| ComponentLayout |
Represents a
Component 's computed layout state. |
| ComponentsLogger |
An interface for logging events and performance events in litho as well as in user defined
components.
|
| ComponentTree.MeasureListener | |
| ComponentTree.NewLayoutStateReadyListener |
Listener that will be notified when a new LayoutState is computed and ready to be committed to
this ComponentTree.
|
| DebugComponent.Overrider | |
| DebugComponentDescriptionHelper.ExtraDescription |
An interface for callsite to append extra description into
StringBuilder by given
DebugComponent . |
| DeprecatedLithoTooltip |
Defines a tooltip that can be passed to the ComponentTree to be anchored to a component.
|
| DerivedDynamicValue.Modifier<I,O> | |
| DiffNode |
A lightweight representation of a layout node, used to cache measurements between two Layout tree
calculations.
|
| EndToEndTestingExtension.EndToEndTestingExtensionInput | |
| Equivalence<T> |
Equivalence is a Component/Section concept to have a custom equal-like method.
|
| EventDispatcher |
A class implementing this interface will expose a method to dispatch an
Event given an EventHandler . |
| EventDispatcherInstrumenter.Instrumenter | |
| EventTriggerTarget |
A class implementing this interface wll expose a method annotated with
OnTrigger to accept an Event given an EventTrigger |
| FrameworkLogEvents |
Set of events and event params logged by the framework if a
ComponentsLogger was supplied
to the ComponentContext used to create the tree. |
| HasEventDispatcher |
A class implementing this interface will expose a method to retrieve an
EventDispatcher . |
| HasEventTrigger |
A class implementing this interface will expose a method to record all the
EventTrigger
into a EventTriggersContainer |
| HasLithoViewChildren |
An interface that a mountable view can extend which informs that this mountable content has other
LithoView children.
|
| HookInitializer<T> |
Interface for a block of code that will initialize a hook value.
|
| HookUpdater |
EXPERIMENTAL - interface for a block of code that will update state created with useState.
|
| ImageContent |
A UI element that contains simple resource drawables.
|
| InterStagePropsContainer |
Container for inter-stage props.
|
| LayoutProps | |
| LithoLifecycleListener |
Can observe lifecycle changes that a LithoLifecycleProvider goes through.
|
| LithoLifecycleProvider |
Manages a Litho ComponentTree lifecycle and informs subscribed LithoLifecycleListeners when a
lifecycle state occurs.
|
| LithoTooltip | |
| LithoView.LayoutManagerOverrideParams |
LayoutParams that override the LayoutManager.
|
| LithoView.OnDirtyMountListener | |
| LithoView.OnPostDrawListener | |
| MountContentPool |
A pool dedicated to recycling mount content.
|
| NodeConfig.InternalYogaNodeFactory | |
| PerfEvent |
A logging event created through
ComponentsLogger.newPerformanceEvent(ComponentContext,
int) to track performance metrics in the framework. |
| PoolWithDebugInfo |
A object pool that has debug info for display in tools like Stetho.
|
| PotentiallyPartialResult |
Interface defining a result calculated from a
TreeFuture that could be interrupted, and
therefore be partial (and resumed on the UI thread). |
| PrepareInterStagePropsContainer | |
| RootWrapperComponentFactory |
Takes a component and returns a new component that it is wrapped in.
|
| SpecGeneratedComponent.TransitionContainer |
Generated component's state container could implement this interface along with
StateContainer when componentspec specifies state update method with OnUpdateStateWithTransition annotation. |
| TextContent |
A UI element that contains text.
|
| Touchable |
Any interface for mounted items that need to capture motion events from its
ComponentHost . |
| Transition.TransitionAnimator |
Class that knows how to create a
TransitionAnimationBinding given a PropertyAnimation . |
| TransitionManager.OnAnimationCompleteListener<T> |
A listener that will be invoked when a mount content has stopped animating.
|
| WorkContinuationInstrumenter.Instrumenter |
Allows to record work being continued across threads.
|
| WorkingRange |
| Class | Description |
|---|---|
| AccessibilityRole |
A list of all roles used for accessibility.
|
| AccessibilityUtils | |
| Animations | |
| Animations.AnimationBuilder | |
| Animations.DynamicValueBindingBuilder | |
| AnimationsDebug |
Utilities for animations debug.
|
| AOSPLithoLifecycleProvider |
This LithoLifecycleProvider implementation dispatches to the registered observers the lifecycle
state changes triggered by the provided LifecycleOwner.
|
| ArrayBatchAllocator | |
| AttachDetachHandler |
Manages dispatching attach/detach events to a set of
Attachable . |
| BaseMatcher<T extends BaseMatcher<T>> |
Base class used to share common properties used in TestSpec builders.
|
| BaseMatcherBuilder | |
| BenchmarkTestHelper |
Helper class to access Litho internals for benchmark testing.
|
| Border |
Represents a collection of attributes that describe how a border should be applied to a layout
|
| Border.Builder | |
| BoundaryWorkingRange |
An implementation of working range that uses offset to define the upper bound and the lower
boundary.
|
| ClickEvent |
Components should implement an event of this type in order to receive Android click events.
|
| Column |
A
Component that renders its children in a column. |
| Column.Builder | |
| CommonProps |
Internal class that holds props that are common to all
Component s. |
| CommonProps.DefaultLayoutProps | |
| CommonUtils | |
| Component |
Represents a unique instance of a component.
|
| Component.Builder<T extends Component.Builder<T>> | |
| Component.ContainerBuilder<T extends Component.ContainerBuilder<T>> | |
| ComponentContext |
A Context subclass for use within the Components framework.
|
| ComponentHost |
A
ViewGroup that can host the mounted state of a Component . |
| ComponentKeyUtils | |
| ComponentLogParams |
Data class for params used to log error in LithoView.
|
| ComponentsLifecycles |
Callbacks that must be invoked to avoid leaking memory if using Components below ICS (API level
14).
|
| ComponentsReporter |
This is intended as a hook into
android.util.Log , but allows you to provide your own
functionality. |
| ComponentsSystrace |
This is intended as a hook into
android.os.Trace , but allows you to provide your own
functionality. |
| ComponentTree |
Represents a tree of components and controls their life cycle.
|
| ComponentTree.Builder |
A builder class that can be used to create a
ComponentTree . |
| ComponentTreeDumpingHelper |
Helper class in charge of dumping the component hierarchy related to a provided
ComponentContext |
| ComponentUtils | |
| ContextUtils | |
| DebugComponent |
A DebugComponent represents a node in Litho's component hierarchy.
|
| DebugComponentDescriptionHelper |
Describes
DebugComponent s for use in testing and debugging. |
| DebugComponentTimeMachine |
This class provides the means to save and restore ComponentTrees for time-traveling debugging.
|
| DebugComponentTimeMachine.TreeRevision | |
| DebugComponentTimeMachine.TreeRevisions | |
| DebugHierarchy |
DebugHierarchy provides a light(er) weight way to track and access information about the
component parentage of a given MountItem . |
| DebugHierarchy.Node | |
| DebugLayoutNode |
A DebugLayoutNode is a wrapper around InternalNode which allows debug tools to inspect and mutate
internal nodes without making InternalNode a public class.
|
| DebugLayoutNodeEditor | |
| DebugMetadata |
DebugMetadata is a special class that allows custom key-value pairs to be appended to
LithoMetadataExceptionWrapper when it wraps an exception. |
| DefaultComponentsReporter | |
| DefaultComponentsSystrace | |
| DefaultDiffNode | |
| DefaultErrorEventHandler |
Default implementation of ErrorEvent handler.
|
| DefaultLithoHandlerDynamicPriority |
LithoHandler implementation backed by a HandlerThread, which allows changing the priority of a
HandlerThread.
|
| DefaultMountContentPool |
The default
MountContentPool used for mount content unless your MountSpec
implements @OnCreateMountContentPool. |
| DelayTransitionSet |
A
TransitionSet that, however, designed to have exactly one transition child to which the
specified apply would be applied |
| DelegatingEventHandler<E> |
An event handler that takes two event handlers and calls both of them when an event is
dispatched.
|
| DerivedDynamicValue<I,O> |
Allows a new DynamicValue to be derived from an existing DynamicValue, with modifications
applied.
|
| Diff<T> |
Represents a diff between two
T values. |
| DisabledMountContentPool |
A MountContentPool that has no size and doesn't recycle objects.
|
| DispatchPopulateAccessibilityEventEvent |
Components should implement an event of this type in order to receive callbacks to
View#dispatchPopulateAccessibilityEvent(AccessibilityEvent) |
| DoubleMeasureFixUtil | |
| DrawableMatrix |
Static class containing a factory method for creating a matrix to apply to a drawable.
|
| DynamicPropsExtension | |
| DynamicPropsManager |
Takes care of dynamic Props
|
| DynamicValue<T> |
Class represents a DynamicValue, and provides users with ability to change the value, by exposing
one public method
DynamicValue.set(Object) It also allows attaching listeners (package level access),
and takes care of notifying them when the held value changes. |
| Edges | |
| EmptyComponent |
A component which renders nothing.
|
| EndToEndTestingExtension | |
| EquivalenceUtils | |
| ErrorBoundariesConfiguration |
Temporary internal settings augmenting
ComponentsConfiguration . |
| ErrorEvent |
An event used internally to propagate exceptions up the hierarchy.
|
| ErrorEventHandler |
This class is an error event handler that clients can optionally set on a
ComponentTree
to gracefully handle uncaught/unhandled exceptions thrown from the framework while resolving a
layout. |
| EventDispatcherInstrumenter |
Plugin style that can be used for instrument before & after the event is dispatched by
EventDispatcher.dispatchOnEvent(EventHandler, Object) |
| EventDispatchInfo |
Holds onto the mutable data used to dispatch an event.
|
| EventHandler<E> | |
| EventHandlersController |
Manages the mapping of event handlers to dispatchers.
|
| EventHandlersController.EventHandlersWrapper |
Used to hold a dispatcher's event handlers.
|
| EventTrigger<E> |
Allows a top-down communication with a component and its immediate parent.
|
| EventTriggersContainer |
Keeps all valid instances of
EventTrigger from the hierarchy when the layout is completed |
| ExecutorLithoHandler |
A
LithoHandler implementation that runs all layout computations against the provided
Executor . |
| FastMath |
Implements some math functions in a faster way than the java Math package.
|
| FocusChangedEvent |
Event triggered when focus changes on a Component.
|
| FocusedVisibleEvent |
Event triggered when a Component enters the Focused Range.
|
| FullImpressionVisibleEvent |
Event triggered when a Component enters the Full Impression Range.
|
| Handle |
Instances of this class are used to uniquely identify
Component s for triggering external
events including showing a LithoTooltip or triggering an event. |
| HostMountContentPool |
A specific MountContentPool for HostComponent - needed to do correct recycling with things like
duplicateParentState.
|
| InitialStateContainer |
The InitialStateContainer is a lookaside table used by a ComponentTree to create initial states
for Components.
|
| InterceptTouchEvent |
Components should implement an event of this type in order to intercept Android touch events.
|
| InternalNodeUtils | |
| InvisibleEvent |
Event triggered when a Component becomes invisible.
|
| KStateContainer | |
| LayoutState |
The main role of
LayoutState is to hold the output of layout calculation. |
| LayoutStateContext |
Wraps objects which should only be available for the duration of a LayoutState, to access them in
other classes such as ComponentContext during layout state calculation.
|
| LayoutThreadPoolConfigurationImpl |
Configures a thread pool used for layout calculations.
|
| LayoutThreadPoolExecutor |
Thread pool executor implementation used to calculate layout on multiple background threads.
|
| LayoutTreeFuture | |
| LifecycleStep.StepInfo | |
| LithoAnimtableItem |
Litho's implementation of the
AnimatableItem required by the TransitionsExtension
to power animations. |
| LithoGestureDetector |
Simple wrapper of
GestureDetector to be used in Litho lifecycle methods. |
| LithoHostListenerCoordinator |
Helper for dispatching events to multiple MountListenerExtensions in Litho.
|
| LithoLayoutContextExtraData | |
| LithoLayoutContextExtraData.LithoLayoutExtraData | |
| LithoLayoutData |
This object will host the data associated with the component which is generated during the
measure pass, for example: the
InterStagePropsContainer , and the LayoutOutput.UpdateState . |
| LithoLayoutResult |
This is the default implementation of a
LayoutResult for Litho. |
| LithoLifecycleProviderDelegate |
Default
LithoLifecycleProvider implementation. |
| LithoMountData |
This class hosts any extra mount data related to MountItem.
|
| LithoNode | |
| LithoRenderContext | |
| LithoRenderUnit | |
| LithoResolutionResult | |
| LithoStartupLogger |
Logger for tracking Litho events happening during startup.
|
| LithoTooltipController | |
| LithoView |
A
ViewGroup that can host the mounted state of a Component . |
| LithoViewAttributesExtension | |
| LithoViewTestHelper |
Helper class to access metadata from
LithoView that is relevant during end to end tests. |
| LithoViewTestHelper.InternalNodeRef |
Holds an opaque reference to an
LithoNode without giving the holder any access to it. |
| LithoYogaBaselineFunction | |
| LithoYogaMeasureFunction | |
| LogTreePopulator |
This class provides utilities for extracting information through
ComponentsLogger.getExtraAnnotations(TreeProps) and transforming them so they can be logged. |
| LongClickEvent |
Components should implement an event of this type in order to receive Android long click events.
|
| MatrixDrawable<T extends Drawable> |
A Drawable that wraps another drawable.
|
| MeasureComparisonUtils |
An utility class to verify that an old measured size is still compatible to be used with a new
measureSpec.
|
| MeasuredResultCache |
Read & write layout result cache used during render phase for caching measured results that
happen during component-measure.
|
| MountableLithoRenderUnit | |
| MountHelper | |
| MountSpecLithoRenderUnit |
This
RenderUnit encapsulates a Litho output to be mounted using Render Core. |
| MountSpecLithoRenderUnit.LithoBindBinder | |
| MountSpecLithoRenderUnit.LithoMountBinder | |
| NestedLithoViewsExtension |
MountExtension to ensure that content with nested LithoViews is properly clearing those
LithoViews when the item is unmounted.
|
| NestedTreeHolder | |
| NestedTreeHolderResult |
This is an output only
NestedTreeHolderResult ; this is created by a NestedTreeHolder . |
| NestedTreeYogaLayoutProps | |
| NodeConfig |
A helper class that defines a configurable sizes for Pooling.
|
| NodeInfo |
NodeInfo holds information that are set to the
LithoNode and needs to be used while
mounting. |
| NodeInfoUtils | |
| NoOpEventHandler<E> | |
| NoOpPerfEvent |
Empty implementation of
PerfEvent performing no actions. |
| OnInitializeAccessibilityEventEvent |
Components should implement an event of this type in order to receive callbacks to
androidx.core.view.AccessibilityDelegateCompat#onInitializeAccessibilityEvent( View,
AccessibilityEvent) |
| OnInitializeAccessibilityNodeInfoEvent |
Components should implement an event of this type in order to receive callbacks to
androidx.core.view.AccessibilityDelegateCompat#onInitializeAccessibilityNodeInfo( View,
AccessibilityNodeInfoCompat) |
| OnPopulateAccessibilityEventEvent |
Components should implement an event of this type in order to receive callbacks to
androidx.core.view.AccessibilityDelegateCompat#onPopulateAccessibilityEvent( View,
AccessibilityEvent) |
| OnRequestSendAccessibilityEventEvent |
Components should implement an event of this type in order to receive callbacks to
androidx.core.view.AccessibilityDelegateCompat#onRequestSendAccessibilityEvent( ViewGroup, View,
AccessibilityEvent) |
| Output<T> |
Type for parameters that are logical outputs.
|
| OutputUnitsAffinityGroup<T> | |
| ParallelTransitionSet |
A
TransitionSet that runs its child transitions in parallel, optionally with a stagger. |
| PerformAccessibilityActionEvent |
Components should implement an event of this type in order to receive callbacks to
android.view.View.AccessibilityDelegate#performAccessibilityAction(View, int, Bundle) |
| PreloadingUtils |
Utility for preloading classes that should be loaded early but may not be accessible outside of
Litho.
|
| PrepareResult |
The result of a
MountableComponent#prepare call. |
| RecyclePool<T> |
Used to recycle objects in Litho.
|
| RenderCompleteEvent |
An
Event that is triggered when a component is render complete. |
| RenderResult | |
| RenderState |
Keeps track of the last mounted @Prop/@State a component was rendered with for components that
care about them (currently, this is just for ComponentSpecs that use
Diff 's of props in
any of their lifecycle methods). |
| RenderStateContext | |
| RenderTreeFuture | |
| RenderTreeNodeUtils | |
| RenderUnitIdGenerator |
Class that handles generation of unique IDs for RenderUnits for a given ComponentTree.
|
| ResolvedTree | |
| ResourceCache | |
| ResourceResolver | |
| Row |
A
Component that renders its children in a row. |
| Row.Builder | |
| ScopedComponentInfo | |
| SendAccessibilityEventEvent |
Components should implement an event of this type in order to receive callbacks to
androidx.core.view.AccessibilityDelegateCompat#sendAccessibilityEvent(View, int) |
| SendAccessibilityEventUncheckedEvent |
Components should implement an event of this type in order to receive callbacks to
androidx.core.view.AccessibilityDelegateCompat#sendAccessibilityEventUnchecked( View,
AccessibilityEvent) |
| SequenceTransitionSet |
A
TransitionSet that runs its child transitions in sequence, one after another. |
| SimpleNestedTreeLifecycleProvider |
LithoLifecycleProvider implementation that can be used to subscribe a nested ComponentTree to
listen to state changes of the lifecycle provider that the parent ComponentTree is also
subscribed to.
|
| Size |
Public API for MeasureOutput.
|
| SpecGeneratedComponent |
Base class for all component generated via the Spec API (@LayoutSpec and @MountSpec).
|
| StateContainer |
Implemented by the class used to store state within both Components and Sections to store state.
|
| StateContainer.StateUpdate | |
| StateDebuggingUtils |
Hosts API to debug state
|
| StateHandler |
Holds information about the current State of the components in a Component Tree.
|
| StateValue<T> |
Used to represent the value of a Component's State.
|
| TestComponent | Deprecated
Use ComponentAssert APIs instead.
|
| TestItem |
Holds information about a
TestOutput . |
| TestItem.AcquireKey | |
| TestLayoutState | Deprecated
Only to be used with the deprecated
ComponentTestHelper |
| TestPerfEvent |
Implementation of
PerfEvent for tests. |
| ThreadPoolLayoutHandler |
LithoHandler implementation that uses a thread pool to calculate the layout.
|
| ThreadTracingRunnable |
ThreadTracingRunnable tries to help debugging crashes happening across threads showing the
stacktrace of the crash origin which scheduled this runnable.
|
| ThreadUtils |
Thread assertion utilities.
|
| TouchEvent |
Components should implement an event of this type in order to receive Android touch events.
|
| Transition |
Defines how a property on a component should animate as it changes, allowing you to optionally
define appear-from values for appear animations and disappear-to values for disappear animations.
|
| Transition.AnimationTarget |
Specifies what components and properties a Transition should target.
|
| Transition.AutoBoundsTransitionBuilder |
Transition builder that targets every component in the component tree whose bounds have been
changed.
|
| Transition.BaseTransitionUnitsBuilder | |
| Transition.ComponentTarget |
Specifies the component(s) a Transition should target.
|
| Transition.PropertyTarget |
Specifies the property(s) a Transition should target.
|
| Transition.RootBoundsTransition |
Contains information about whether root component has bounds transition and if so whether it
defines appear animation as well.
|
| Transition.SpringTransitionAnimator |
Creates spring-driven animations.
|
| Transition.TimingTransitionAnimator |
Creates timing-driven animations with the given duration.
|
| Transition.TransitionUnit | |
| Transition.TransitionUnitsBuilder |
Transition builder that allows targeting arbitrary keys and properties.
|
| TransitionEndEvent |
Components should implement an event of this type in order to receive a callback when a
Transition ends. |
| TransitionId |
Represents a unique id used for transitions, that is assigned to
AnimatableItem based on
Node 's transitionKey and transitionKeyType, later passed on to a
MountItem , and used by com.facebook.rendercore.MountDelegate.MountDelegateTarget and TransitionManager |
| TransitionManager |
Handles animating transitions defined by ComponentSpec's onCreateTransition code.
|
| TransitionSet |
A set of
Transition s. |
| TransitionsExtension |
Extension for performing transitions.
|
| TreeFuture<T extends PotentiallyPartialResult> |
Base class that wraps a
FutureTask to allow calculating the same result across threads. |
| TreeProps |
A data structure to store tree props.
|
| TreeState | |
| UnfocusedVisibleEvent |
Event triggered when a Component exits the Focused Range.
|
| ViewCompatComponent<V extends View> | Deprecated
ViewCompatComponent is not efficient as it will do measurement of views twice.
|
| ViewCompatComponent.Builder<V extends View> | |
| ViewUtils | |
| VisibilityChangedEvent |
Event triggered when the visible rect of a Component changes.
|
| VisibleEvent |
Event triggered when a Component enters the Visible Range.
|
| WorkContinuationInstrumenter |
Utility class that allows to capture work continuation updates.
|
| WorkingRangeStatusHandler |
A handler that stores the range status of components with given working range.
|
| Wrapper |
Utility class for wrapping an existing
Component . |
| Wrapper.Builder | |
| YogaLayoutProps |
| Enum | Description |
|---|---|
| Component.MountType | |
| ComponentsLogger.LogLevel | |
| ComponentsReporter.LogLevel | |
| LifecycleStep | |
| LithoLifecycleProvider.LithoLifecycle | |
| RenderCompleteEvent.RenderState | |
| TooltipPosition |
Specify a position to anchor a
DeprecatedLithoTooltip on a component. |
| Transition.TransitionKeyType |
| Exception | Description |
|---|---|
| LithoMetadataExceptionWrapper |
Exception class used to add additional Litho metadata to a crash.
|
| ReThrownException |
| Annotation Type | Description |
|---|---|
| AccessibilityRole.AccessibilityRoleType | |
| Border.Corner | |
| FrameworkLogEvents.LogEventId | |
| LayerType |
Enumerates all the valid valid for
Component.Builder.layerType(int, Paint) |
| LayoutState.CalculateLayoutSource | |
| LithoLifecycleProviderDelegate.LifecycleTransitionStatus | |
| OutputUnitType | |
| ThreadUtils.MainThreadOverride | |
| TransitionId.Type | |
| WorkingRangeStatusHandler.WorkingRangeStatus |


|
|
def | __init__ |
| |
|
def | success_path |
| |
|
def | set_success_path |
| |
|
def | clear_success_path |
| |
|
def | has_success_path |
| |
|
def | max_upload_size_bytes |
| |
|
def | set_max_upload_size_bytes |
| |
|
def | clear_max_upload_size_bytes |
| |
|
def | has_max_upload_size_bytes |
| |
|
def | max_upload_size_per_blob_bytes |
| |
|
def | set_max_upload_size_per_blob_bytes |
| |
|
def | clear_max_upload_size_per_blob_bytes |
| |
|
def | has_max_upload_size_per_blob_bytes |
| |
|
def | gs_bucket_name |
| |
|
def | set_gs_bucket_name |
| |
|
def | clear_gs_bucket_name |
| |
|
def | has_gs_bucket_name |
| |
|
def | MergeFrom |
| |
|
def | Equals |
| |
|
def | IsInitialized |
| |
|
def | ByteSize |
| |
|
def | ByteSizePartial |
| |
|
def | Clear |
| |
|
def | OutputUnchecked |
| |
|
def | OutputPartial |
| |
|
def | TryMerge |
| |
|
def | __str__ |
| |
|
|
| has_success_path_ |
| |
|
| success_path_ |
| |
|
| has_max_upload_size_bytes_ |
| |
|
| max_upload_size_bytes_ |
| |
|
| has_max_upload_size_per_blob_bytes_ |
| |
|
| max_upload_size_per_blob_bytes_ |
| |
|
| has_gs_bucket_name_ |
| |
|
| gs_bucket_name_ |
| |
|
|
int | has_success_path_ = 0 |
| |
|
string | success_path_ = "" |
| |
|
int | has_max_upload_size_bytes_ = 0 |
| |
|
int | max_upload_size_bytes_ = 0 |
| |
|
int | has_max_upload_size_per_blob_bytes_ = 0 |
| |
|
int | max_upload_size_per_blob_bytes_ = 0 |
| |
|
int | has_gs_bucket_name_ = 0 |
| |
|
string | gs_bucket_name_ = "" |
| |
|
int | ksuccess_path = 1 |
| |
|
int | kmax_upload_size_bytes = 2 |
| |
|
int | kmax_upload_size_per_blob_bytes = 3 |
| |
|
int | kgs_bucket_name = 4 |
| |
The documentation for this class was generated from the following file:
- code/googleappengine-read-only/python/google/appengine/api/blobstore/blobstore_service_pb.py


We use loop resolution Hi-C to track the formation of loop domains across the genome as cohesin is reintroduced. (Top Left) Contact map for 6hr auxin treated RAD21-mAC cells. (Top Right) Contact map for RAD21-mAC cells with 6hr auxin treatment + 20 minute auxin withdrawal. (Middle Left) Contact map for RAD21-mAC cells with 6hr auxin treatment + 40 minute auxin withdrawal. (Middle Right) Contact map for RAD21-mAC cells with 6hr auxin treatment + 60 minute auxin withdrawal. (Bottom Left) Contact map for RAD21-mAC cells with 6hr auxin treatment + 180 minute auxin withdrawal. (Bottom Right) Contact map for untreated RAD21-mAC cells.


Blog
Manager
Content Designer
Designer
The digital team is redesigning our online content and building a new case management system for Citizens Advice based on user need.


Special Thanks to Lorraine Justice, Josh Owen, Bruce Leonard, Adam Smith
©2017 Thought At Work. All rights reserved.
Presentation 1
Presentation 2


{# ####################### footer.html ########################## Content for the report footer. #} {% if config.swedac_accredited and config.swedac_location == 'stockholm' %} {% endif %} {% if config.swedac_accredited and config.swedac_location == 'uppsala' %} {% endif %}
MultiQC v{{ config.version }} - Written and maintained by Phil Ewels at Seqera Labs, originally at SciLifeLab Sweden and available on GitHub.
This report uses HighCharts, jQuery, jQuery UI, Bootstrap, chroma.js, FileSaver.js and clipboard.js.


"Black Star" by Elon Newton. This artwork is an exprecion for the mysterious future of mankinds exploration into the eternal void. It's valued at 1 space rocket, 400 eletric cars and 6 not-a-flamethrowers.
CSS-grid og flexbox-layout.
CSS-grid is used in this projct. The grid-area property is used to generate a 3 by 4 grid. HTML elements are selected by class and assosiated with a grid area and placed in that grid area.
Flexbox is used within the grid areas to style the layout of the grid area. Here it is used to center the items. If there are multiple items in one grid area the flex-direction: column; is used to flex them after each other.
SVG
Canvas is "surface" where you can manipulate picsels with a javascript interface.
SVG stands for scalable vector graphics and is based on a XML file structure.
In this project SVG is most suitet for the task i needed to solve. One of the main reason i clame this is becuse the artworks simplicity, one does only require simple interactions which can be handels by CSS.
SVG has a simple dom sturcture of html, so there is no need for javascript to make it interactive, contarary to Canvas. One can simply have a on hover on a element to make it an interaction.
There is only a few SVG elements so there will be problem with overloading the dom. In cases where complex graphics is needed, with many layers to be drawn, Canvas may be a better choice to reduce the load on the dom
(thousans of SVG elemets is not ideal). Also in cases where complex interacion we would have to resort to javascript, and in that case the advantage of SVG decreses. Since javascript can be used with SVG and have to be used with Canvas.
The last big advantage of SVG over canvas is it's scalability, SVG will not lose it's resolution when scaled. In the case of artworks which one might want to enlarge for displays this is a neet feature.
Jquary
Jquary is a javascript libary which makes interacion with DOM elements simpler and more elegant. It's been around for a long time and is widely used.
For this project we needed jquary for the button functionality, to make the documentation toggle between hidden and shown. The picture inteaction can also be done by jquary, the functionality provided by js/jquary infinitely greater than what CSS provides.
Cross-browser testing
Cross-browser testing is important to make sure the webpage works in the intended way on all browsers. This is nessesary because of the natrue of the web and browsers. It's the same file that's sent to the different
browsers, but it's interpeded uniquely by each browser. This means that different browsers can end up making different decisions about the same code. Testing in multiple browsers allows us to correct these mistakes.
This webpage has been tested in chrome and in firefox and worked as expected. The biggest concert with this project is the animation part, which require different webkits for different browsers.
Information Sources
My main information sources comes form the web. Some of the sites i used infromation from is:
www.w3schools.com, www.sitepoint.com, css-tricks.com, stackoverflow.com, medium.com
Reuse of code
The code for the button functionality is based on: w3schools
The code for the SVG animation is based on: stackoverflow
PS. Feedback can be given in Norwegian. I just prefer writing documentation in english.


Kitura-Compression
Kitura compression middleware
Summary
Kitura compression middleware for compressing body data sent back to the client. Supports deflate
and gzip
compression methods. Uses zlib.
Table of Contents
Swift version
The latest version of Kitura-Compression requires Swift 3.0. You can download this version of the Swift binaries by following this link. Compatibility with other Swift versions is not guaranteed.
API
In order to use compression middleware, create an instance of Compression
, and connect it to the desired path:
import KituraCompression
router.all(middleware: Compression())
You can configure Compression
with optional arguments:
swift
public init (threshold: Int = 1024, chunkSize: Int = 16384, compressionLevel: CompressionLevel = CompressionLevel.defaultCompression, compressionStrategy: CompressionStrategy = CompressionStrategy.defaultStrategy, memoryLevel: Int32 = 8)
Where:
- threshold is the byte threshold for the response body size before compression is considered for the response, defaults to 1024.
chunkSize is the size of internal output slab buffer in bytes, defaults to 16384
compressionLevel is the level of zlib compression to apply. The supported values are:
.noCompression, .bestSpeed, .bestCompression, .defaultCompressioncompressionStrategy is used to tune the compression algorithm. Here are its possible values:
.defaultStrategy, .filtered, .huffmanOnly, .rle, .fixedmemoryLevel specifies how much memory should be allocated for the internal compression state. The default value is 8.
For more information on compression parameters, see zlib manual.
License
This library is licensed under Apache 2.0. Full license text is available in LICENSE.


#assign WhenModified = "true">
@WhenModified
A date time property managed by Ebean that is set on both insert
and update
.
Typically we use both @WhenCreated
and @WhenModified
on a mapped superclass.
Example
```java
@WhenCreated
private Instant whenCreated;
@WhenModified
private Instant whenModified;
}
```
Example on mapped superclass
```java
@MappedSuperclass
public abstract class BaseDomain {
@Id
protected UUID id;
@Version
private long version;
@WhenCreated
private Instant whenCreated;
@WhenModified
private Instant whenModified;
public UUID getId() {
return id;
}
public long getVersion() {
return version;
}
public Instant getWhenCreated() {
return whenCreated;
}
public Instant getWhenModified() {
return whenModified;
}
}
```


Wiki-Ads is a Chrome browser extension that adds advertisements to Wikipedia pages when you view them. All profits generated by Wiki-Ads are donated to WikiMedia Foundation, Inc. in support of Wikipedia.
We built Wiki-Ads to provide additional ways to contribute to Wikipedia.
InstallationInstall now from the Google Chrome Web Store. Note: If you're using an ad blocker, you need to configure
it to allow ads on Wikipedia.org. |
Q: Does Wiki-Ads insert ads anywhere else besides Wikipedia.org?
A: It only inserts ads on Wikipedia.org and Wiki-Ads.com
Q: Why doesn't Wikipedia just put ads on the site themselves?
A: It's been discussed ad nauseam, but they still haven't done it. Wikipedia:Funding Wikipedia through advertisements. Wiki-Ads represents a grass-roots effort to support Wikipedia through opt-in ads.


Short Address: {{device.shortAddress.toString(16).toUpperCase()}}
Hardware Address: {{byte.toString(16).toUpperCase()}}-
Default Name: {{device._defaultName}}
Class: {{device.class}}
No Actions
No Events
This device won't appear any more until it is detected again, name and icon preferences will be lost.
{{devConfigError}}


Docs
Example of documentation
<<<<<<< HEAD
The first
The second
The third
======= >>>>>>> d4484caa05b89e2998ae66768fa0aec71d9d08bc