The Tobii EyeX Software Development Kit (SDK) for Unreal Engine 4 contains everything you need for building games using the Tobii EyeX Engine API and the Tobii EyeX plugin for Unreal Engine 4.
Last updated: January 22, 2016
Images © 2016 Tobii AB (publ) - All rights reserved. Tobii and the Tobii logos are either registered trademarks or trademarks of Tobii in the United States and/or other countries.
www.tobii.com
Have you ever wanted to create a game that the player can interact with using her eyes? The EyeX Plugin for Unreal Engine bridges the gap between the Unreal Engine development environment and the Tobii EyeX API and lets you do just that.
The plugin can be inserted into any game built with the Unreal Engine 4.6 or higher and used from both blueprints and C++ code.
Because the plugin depends on the Tobii EyeX Engine, it will only work properly on platforms where the EyeX Engine is supported: currently Windows 7 and later. The plugin includes a mouse emulation function that can be used to do some limited development and testing on other platforms as well.
The EyeX Plugin for Unreal Engine is provided on GitHub under a quite permissive open-source license. You will also need the EyeX client library to use the plugin. It can be downloaded from Tobii free of charge, and it has a permissive (but not open source) license agreement too. Make sure to read the license agreement because it’s not the same as for the plugin itself.
Note. Tobii provides EyeX SDKs for several other development environments in addition to the Unreal Engine. They are all available for download from the Tobii Developer Zone.
You will need:
Follow the steps in the README.md file carefully to set up the development environment for EyeX.
After you have completed the setup you should have a working sample “game” with a couple of scenes that demonstrate various usages of the eye tracking data.
You should also be able to grab the Plugins folder from the sample game and drop it into your own game. And that’s when the real fun starts!
The EyeX Plugin for Unreal Engine package includes not only the plugin itself but also a sample project with a few sample scenes (in the form of levels/maps) that demonstrate how the eye tracking data can be used in a game.
All samples are implemented in the form of blueprints.
Note. The graphics and gameplay in the sample scenes have been deliberately kept to a minimum so as not to get in the way of the code.
This scene contains a few objects that respond differently to the player’s eye-gaze: the sphere spins around, the rock grows, and the cube turns on a light source when looked at.
Looking at the blueprint you will find that the sphere and the rock trigger their actions using the HasGazeFocus method, while the cube uses the GotGazeFocus/LostGazeFocus events.
Another interesting thing to do in this scene is to select the player controller actor while the level is running in the editor and enable the EyeX/VisualizeDetection property. Doing that will let you see how the hit testing is performed. You can also try different detection modes.
This scene contains a couple of objects tossed out at different distances. When you focus on one of them, the rendering updates so that objects that are out of focus (due to the limited depth-of-field) are blurred. This means that the view won’t be perfectly sharp everywhere at the same time. That could have some really interesting uses in a FPS game.
This scene visualizes the player’s eyes and the gaze point in 3D. It gives an idea of how the eye positions data stream behaves.
In this scene the screen is dimmed when no player is present in front of the screen.
This scene shows how the fixation detection works: it’s a static scene and the fixations are visualized on top.
Fixations are points where the gaze lingers to focus on something. The visualization displays the last few fixations as orange circles and the ongoing fixation (if any) as a gray circle.
This is a scene where the player’s gaze point is visualized on top of the viewport. You can try both the unfiltered and the lightly filtered alternatives and compare them to each other.
We recommend that you browse through the rest of this Developer’s Guide, because it will give you a big picture view of the EyeX Engine and its API. Knowing what the engine can do for you, and how the pieces fit together, will surely be helpful as you move on to create your game.
 Just remember that the Tobii Developer Zone is there for you if you need inspiration or if you get stuck.
The figure below gives an overview of the hardware and software components that work together to create the Tobii Eye Experience. By using the EyeX plugin in your game, you can make it possible for the player to interact with the game using her eyes!
Figure 1 Your game and Tobii EyeX environment. The game is running on the computer screen on the left-hand side. An EyeX Controller is mounted on the screen and is detecting the player’s eye-gaze. The diagram on the right-hand side shows the software running on the computer. The game makes use of the EyeX Engine and Controller through the EyeX Plugin.
The EyeX Controller is a device which can determine what you’re looking at. It is mounted on the bottom of the computer screen and attached to the computer with a USB 3.0 cable.
The EyeX Engine takes the data from the EyeX Controller or other compatible device, processes the data, and makes it available to your game and other applications through an API. The EyeX Engine also takes care of all the necessary groundwork when it comes to eye tracker hardware configuration, user calibration, and so on.
The EyeX Plugin for Unreal Engine adapts the EyeX API so that it can be used easily in games built using the Unreal Engine.
EyeX Interaction is a way of interacting with the computer in a natural and effortless way based on where you look. This ranges from your computer simply being aware of your presence all the way to clicking and scrolling in apps or games that have implemented EyeX Engine interactions. The box labeled EyeX Interaction in the diagram represents the software that enables this kind of interaction in the Windows environment. It is passive while your game is running.
The figure below presents an overview of what the EyeX Engine API offers. The EyeX Plugin for Unreal Engine currently does not cover the whole API: the parts that handle regions have been left out because they are not straightforward to implement in a 3D environment. But the plugin does offer an alternative for gaze-aware regions, see the section Detecting actors with eye-gaze interaction for more information.
Figure 2 A somewhat simplified view of what the EyeX Engine API can do for you.
The Gaze point data stream represents the user’s gaze point on the screen. The unfiltered data stream produces a new data point whenever the engine receives a valid eye-gaze data point from the eye tracker. No statements are made regarding the frame rate; you get what you get.
Figure 3: The gaze point is an inherently noisy signal. The orange dots on this screenshot represent the user’s gaze point during a fraction of a second. Filtering makes the point cloud shrink towards its center, but also respond slower to rapid eye movements.
The gaze point is given as a single point. If the user has chosen to track a specific eye, then it’s the gaze point from that eye. Otherwise the point is taken to be the average from both eyes.
Because the gaze point is an intrinsically noisy signal, the Gaze point data stream provides a selection of filters that can be used to stabilize the signal. As usual when it comes to filtering, there is a trade-off between stability and responsiveness, so there cannot be a single filter that is the best choice for all applications, but the Lightly filtered option is a reasonable default and works in most cases. The available filters are:
The Eye position data stream provides the positions of the user’s eyes in three-dimensional space. This data stream can be used, for example, to control the camera perspective.
This data stream produces a new value whenever the engine receives a valid sample from the eye tracker, and no statements are made about the frame rate, just as for the Gaze point data stream. The eye positions are given for the left and right eyes individually.
The Eye position data stream does not offer any filtering options at this time.
There are some limitations to the smoothness of the eye position data stream from the EyeX Controller eye tracking device. Any user experience based on the eye position data stream should be designed with these limitations in mind.
First, the distance of the eyes to the eye tracker is not updated while the user is moving her head towards or away from the controller. This means that the eye position will follow smoothly only when moving the eyes and the head at a roughly fixed distance from the screen, like when you are leaning from side to side. The reported eye position will catch up with a jump when the head movement has stopped.
Second, the calculated distance to the eyes may have a user-dependent offset error. So use it only for relative, not absolute positioning – which is a good idea anyway since users will choose to sit at different distances from the screen.
The Fixation data stream provides information about when the user is fixating her eyes at a single location. This data stream can be used to get an understanding of where the user’s attention is. In most cases, when a person is fixating at something for a long time, this means that the person’s brain is processing the information at the point of fixation. If you want to know more about fixations, the Internet is your friend.
The fixation data stream can be accessed through two functions: one getting the ongoing fixation, if any, and one getting the last finished fixation. Each fixation is presented as a gaze point, a start time, and the duration.
There are two different fixation detection modes to choose from:
The User presence state provides information about whether there is currently a user in front of the screen or not. The state can be “Present”, “Not Present” or “Unknown”. The “Unknown” state occurs when there is no information available, for example when there is no eye tracker connected to the computer.
The EyeX Plugin for Unreal Engine wraps the functionality of the EyeX Engine C API and adapts it for use with Unreal Engine. What does that mean? Well, for one thing: whereas the EyeX Engine API is multi-threaded and fully asynchronous, the Unreal Engine environment is frame-based (that is, it is updated in discrete “ticks” or frames) and essentially single-threaded. Another thing is that you need to add special markup to functions or data in order to use them from blueprints. The EyeX Plugin for Unreal Engine does these two things and a few other things as well.
Note. If you want to know how things work under the hood, or if you want to do advanced stuffz that cannot be done with this plugin, then feel free to check out the header documentation for the C API, because this guide doesn’t cover that API. If you’d rather not, like most people, then you can safely ignore it.
All relevant EyeX engine states and data streams can be accessed through accessor (getter) functions, both from blueprints and from C++ code. These functions will always give you the most recent data point of a data stream, or the current value of an engine state.
If you use blueprints, you will find these functions in the EyeX blueprint function library. If you use C++, you will find them in the plugin module interface class: IEyeXPlugin.
In addition to the EyeX Engine data streams and states, there are also some functions for getting derived data that can be useful in gaming scenarios, such as the head rotation (yaw and roll) derived from the eye positions.
Data streams are not subscribed to by default. The subscription is set up the first time you use the accessor function (or the accessor function for a derived value), which means that the EyeX Engine will start sending data at that point. This means that you will never receive a valid value on the first call to the accessor function.
The EyeX Engine states exposed through the plugin API are updated automatically. You can always read from them and they will reflect the most recent value provided by the engine. If the connection to the engine is lost they will be reset to invalid.
The special template class TEyeXMaybeValue is used for values that may or may not be known. For example, the GetScreenBounds method returns a value of type TEyeXMaybeValue
Suppose you have some actors in your scene that should respond to the player’s eye-gaze somehow. The EyeX Plugin for Unreal Engine provides a player controller/actor base class combo that you can use to do exactly that.
The AEyeXPlayerController class derives from the APlayerController class. It is always on the lookout for eye-gaze interactable actors in the viewport: each tick it will try to read the player’s gaze point and find out which actor the player is looking at. It will only consider actors derived from the AEyeXActorBase.
The EyeX player controller can be configured to use one of several possible detection strategies to decide which actor the player is currently looking at. Some are fast but not very sensitive whereas others are slow but very accurate. The default strategy works in most cases, but if you should find that you need something faster because you have a busy scene, or something more accurate because the eye-gaze interaction is a central part of the gameplay, then we encourage you to experiment. The player controller class has a setting for debug visualization that will let you see the gaze point and the detection results in real time when enabled. (This feature is disabled when building for shipping.)
| Detection strategy | Description | Pros and cons |
|---|---|---|
| None | Detection is disabled. | (n/a) |
| Line Trace | Performs a basic line trace hit testing starting from the gaze point. | Fast, but the actors may have to be surrounded in collision volumes in order to be detected. |
| Boxed Line Trace | Starts with a basic line trace. If no actors are found, does additional line traces in a box shape around the gaze point. | Pretty fast and with a higher detection success rate than a basic line trace. |
| Sweep | Performs hit testing with a sphere swept from the gaze point into the scene. The sweep is performed in segments where the size of the sphere is adjusted in each segment to keep it roughly at a fixed size in 3D world coordinates. | High detection success rate, but more expensive (slow) than the line traces. |
| Frustum Intersection | Calculates a view frustum defined by a box shape around the gaze point in screen space and checks for any actors intersecting with the frustum. | Very accurate, but can be expensive (slow) if the scene contains many EyeXActors with a lot of vertices. |
The AEyeXActorBase class has no behavior of its own, but it does have some properties like cutoff distances and dwell times that affect the sensitivity of the detection.
To implement eye-gaze interaction with blueprints you need to have a player controller blueprint that inherits from EyeXPlayerController, and create actor blueprints that inherits from EyeXActorBase for every actor you want to interact with in the scene. Make sure the EyeX based player controller is set up as the selected player controller in the game’s default or level game mode.
The EyeXPlayerController keeps track of which actor the player is currently looking at, if any. An actor deriving from EyeXActorBase can get information about if the player is currently looking at it in two ways:
To use any of these events or function in a blueprint, right click in the blueprint graph and type “EyeX” to filter out the eye tracking blueprint nodes.
The detection strategy used by the EyeXPlayerController based blueprint can be changed in the Defaults tab in the blueprint editor.
For examples on how to use eye-gaze interaction in blueprints, see section Blueprint sample: a cube which spins when the player is looking at it, and the implementation of the sample scenes included in the EyeXSamples project.
The EyeX Plugin for Unreal Engine includes a mouse emulation function which can be useful not only for testing/troubleshooting eye-gaze interaction, but also for game development on platforms where EyeX isn’t available. When enabled, the mouse emulation function will let you emulate the gaze point using the mouse pointer.
The sample project has a key binding set up to toggle mouse emulation with the F10 key. You can do the same in your own game if you wish.
The arguably simplest use case in the EyeX environment is to read the player’s current gaze point and use it to make something happen, like popping balloons or controlling the mix volumes of some audio sources in the scene. Here is how to do that in C++ code.
#include <IEyeXPlugin.h>
void SomeClass::SomeMethod()
{
if (!IEyeXPlugin::IsAvailable())
{
return;
}
IEyeXPlugin& Plugin = IEyeXPlugin::Get();
auto GazePoint = Plugin.GetGazePoint(EEyeXGazePointDataMode::LightlyFiltered);
// ... etc ...
}
Figure 4: Code sample demonstrating how to access the plugin and the lightly filtered gaze point data stream from C++.
This blueprint sample walkthrough will show you have to retrieve and use gaze point data in a blueprint graph.
Make sure you have a game project set up with the Tobii EyeX plugin. Build a Development Editor and create an empty level.
You will need two blueprints for this sample: a HUD blueprint and a game mode blueprint. The HUD blueprint will draw a small rectangle on the screen at the gaze point, and the game mode blueprint is necessary only to specify which HUD blueprint to use.
Create the two blueprints and name them like this:
Open the BP GazeIntoTheVoidGameMode blueprint for edit and go to the Defaults tab. Under Game Mode, change the HUD Class to BP GazeIntoTheVoidHUD.
Open the World Settings for the level (accessible via the Settings button on the toolbar), and change the Game Mode > Game Mode Override to BP_ GazeIntoTheVoidGameMode.
Open the BP_GazeIntoTheVoidHUD blueprint for edit. Go to the Graph tab. Right click anywhere in the graph area and type “gazepoint” in the search box. Select the Get Gaze Point
function under the EyeX category. Change the Mode
parameter to LightlyFiltered
.
Add a draw HUD event node, and whenever there is gaze point data available, draw a little white rectangle on the screen where the gaze point is.
Hit play and enjoy watching the visualization of your eye-gaze.
This blueprint sample will show you how to create a scene with a cube that spins when the player is looking at it.
Make sure you have a game project set up with the Tobii EyeX plugin. Build a Development Editor and create an empty level.
For this sample, you need to create three blueprints: an EyeX player controller, a game mode and an EyeX actor. The EyeX player controller keeps track of which actor the player is looking at, if any. The EyeX actor can either listen to events, or read from a property to know if the player is looking at it.
Now, go ahead and create the three blueprints and name them like this:
When creating a blueprint based on an EyeX class you need to type in the name of the EyeX specific class in the All Classes
search box of the Pick Parent Class
dialog, and select the class in the class hierarchy.
Open the BP_RotateGameMode blueprint for edit and go to the Defaults tab. Under Game Mode, change the Player Controller Class to BP_RotateEyeXPlayerController.
Open the World Settings for the level (accessible via the Settings button on the toolbar), and change the Game Mode > Game Mode Override to BP_RotateGameMode.
Open the BP_RotateOnGazeCube blueprint for edit. Go to the Components tab. Add a Static Mesh component, and change its asset to a Cube asset.
Go to the Graph tab of the BP_RotateOnGazeCube blueprint. The cube actor can check if it is being looked at by reading the Has Gaze Focus property on every Tick event.
Now, let’s make the cube spin when it is being looked at. Add a float variable called Speed and set its default value to 20.0. Then use Add Actor Local Rotation to add a yaw rotation to the cube based on the Speed and the Delta Seconds of the Tick event.
Go back to the level editor and add a light source in the scene so that the cube actor can be seen.
Now, hit Play and see what happens when you are looking at the cube and when you are not looking at the cube.
You can try out different settings for the eye-gaze detection in the EyeX player controller blueprint. Open the BP_RotateEyeXPlayerController for edit and go the the Defaults tab. Under the EyeX category, there are a number of settings that you can try and change. By checking the Visualize Detection check box a helpful debug visualization will be activated.
When your project is finished and it is time to ship your game there are a few things to take in to consideration.
<game source dir>
/Plugins/TobiiEyeX/ThirdParty/EyeX/lib<game output dir>
/Plugins/TobiiEyeX/ThirdParty/EyeX/libThe Tobii EyeX SDK license agreement gives you the permission to redistribute the client library dll with your game or application, free of charge, in most cases. The exceptions include high risk use applications, applications that might inflict on a person’s privacy, and certain other niche applications. Please see the license agreement for more details; it is available in the SDK package and it can also be downloaded from the Tobii Developer Zone.
The client library depends on the Microsoft Visual C run-time libraries, version 110, and will not work unless these libraries are installed on the computer. The run-time libraries can be downloaded free of charge from Microsoft. If you create an installer for your game, then you can add these libraries as a merge module and have them installed automatically.


This privacy policy governs
your use of the software application SALAH TIMES (“Application”) for mobile devices that was created by
AFAAN BILAL. The Application is AN ANDROID APP WHICH HELPS YOU TO STAY
UP-TO-DATE WITH THE PRAYER TIMES AT YOUR MASJID!
User Provided Information
The Application obtains the
information you provide when you download and register the Application.
Registration with us is optional. However, please keep in mind that you may not
be able to use some of the features offered by the Application unless you
register with us.
When you register with us
and use the Application, you generally provide your email address, password.
We may also use the
information you provided us to contact your from time to time to provide you
with important information, required notices and marketing promotions.
Automatically Collected
Information
In addition, the
Application may collect certain information automatically, including, but not
limited to, the type of mobile device you use, your mobile devices unique
device ID, the IP address of your mobile device, your mobile operating system,
the type of mobile Internet browsers you use, and information about the way you
use the Application.
This Application does not
collect precise information about the location of your mobile device.
No, excluding the hosting
partners.
You can stop all collection
of information by the Application easily by uninstalling the Application. You
may use the standard uninstall processes as may be available as part of your
mobile device or via the mobile application marketplace or network.
We will retain User
Provided data for as long as you use the Application and for a reasonable time
thereafter. We will retain Automatically Collected information for up to 24 MONTHS
and thereafter may store it in aggregate. If you’d like us to delete User
Provided Data that you have provided via the Application, please contact us at<EMAIL_ADDRESS>and we will respond in a reasonable time. Please note
that some or all of the User Provided Data may be required in order for the
Application to function properly.
We do not use the
Application to knowingly solicit data from or market to children under the age
of 13. If a parent or guardian becomes aware that his or her child has provided
us with information without their consent, he or she should contact us at
<EMAIL_ADDRESS>We will delete such information from our files within a
reasonable time.
We are concerned about
safeguarding the confidentiality of your information. We provide physical,
electronic, and procedural safeguards to protect information we process and
maintain. For example, we limit access to this information to authorized
employees and contractors who need to know that information in order to
operate, develop or improve our Application. Please be aware that, although we
endeavor provide reasonable security for information we process and maintain,
no security system can prevent all potential security breaches.
This Privacy Policy may be
updated from time to time for any reason. We will notify you of any changes to
our Privacy Policy by posting the new Privacy Policy [HERE]. You are advised to
consult this Privacy Policy regularly for any changes, as continued use is
deemed approval of all changes.
By using the Application,
you are consenting to our processing of your information as set forth in this
Privacy Policy now and as amended by us. "Processing,” means using cookies
on a computer/hand held device or using or touching information in any way,
including, but not limited to, collecting, storing, deleting, using, combining
and disclosing information, all of which activities will take place in the UNITED
STATES. If you reside outside the UNITED STATES your information will be transferred, processed and
stored there under UNITED STATES privacy standards.
If you have any questions
regarding privacy while using the Application, or have questions about our
practices, please contact us via email at SALAHTIMES@AFAAN.ML.


Screen capture in progress, your finished image will open in a
new window once completed.
Please wait for the capture to finish.
Note: your page is too large for the Chrome browser to capture as
one image. It will be split into multiple
images.
Full Page Screen Capture cannot be run on this type of URL
because of Google Chrome Web Store policies. Try
another page on the web.
Uh oh, something went wrong! Try reloading the page,
and running this again.
If the problem persists, please report the error in the
Chrome webstore.
Please include the URL you tried it on and the
version of Chrome.


k10 repo
kalashrah
Add to Cydia
Hosted Packages
Lift
Move those silly little Control Center slider icons to the top.
More info


ABOUT ALWAR
Alwar, among the Rajput principalities was the closest to imperial Delhi. People of this region are daring & adventurers. Food & hospitalities are among the best. It is referred as the gateway of historic & colorful rajasthan It is surrounded by the Aravali Hills and has a unique recognition because of Sariska Van Abhyaranya , Bala-Quila and Silished etc. Sariska National Park is home to numerous carnivores including Leopard, Wild Dog, Jungle Cat, Hyena, Jackal, and Tiger. The railway network connects Alwar with Delhi, Jodhpur, Mumbai and other important tourist cities of India. Alwar can be easily reached by road as well. There are well-maintained roads linking it to tourism destinations like Delhi, Sariska, Bharatpur. Deeg and Jaipur.


I am a versatile technology professional with 15+ years of experience in technical project management and agile product development. I've been repeatedly recognized for top performance through fast-track promotions and assignment of high-profile initiatives. I am highly motivated and flourish in environments with talented team members whose working relationships are developed on trust and dependability.
Responsible for enhancements to the organization’s custom and vendor developed compliance and legal services applications. Collaborates with stakeholders, developers, and the operations teams to define the product roadmap. Analyzes data, process, and systems to define and maintain detailed requirements in the product backlog. Develops and maintains documentation: process workflow and systems integrations diagrams, data mapping documents, operational support knowledge base articles, and training templates.
Successfully led the implementation of a new legal case matter management & invoicing system, meeting tight deadlines while managing architectural requirements and external system dependencies and constraints.
Flawlessly led the manual early onboarding of 400 new workforce members into legacy compliance oversight systems, in a scenario where the required data would not be available for consumption via the standard onboarding workflow.
Led the development of a new disclosure system on the Appian platform and assisted in coordinating the legacy data migration of 30k+ associated person's of the firm from various data sources.
Currently leading the development and integration of multiple additional legacy systems on the Appian platform, heavily focused on process improvement, as well as improved data consumption methods from upstream dependencies and for downstream consumers.
Collaborated with stakeholders, customers, UX designer, developers, and the QA team through the full SDLC as Product Owner of the customer portal. Developed and maintained the product and defect backlog for an agile software development team, succeffully releasing multiple features and enhancements to production. Assisted with bi-weekly release planning, managed release communications, and maintained detailed product design documentation and training materials. Performed supervisory tasks for 2 direct reports, collectively overseeing product development across 3 engineering teams.
Planned, managed, and delivered 30+ customer implementation projects. Documented and communicated status and risk to the project team and client. Established and maintained project schedules and work breakdown structures to ensure project deliverables were met. Received executive recognition for driving detailed technical requirements leading to the successful implementation of a complex network isolation project for a high profile client.
Fielded and implemented simple to complex requests for customer hosted solutions: DNS, SSL, patching, firewall & VPN, VMware, high availability, database, Active Directory, operating systems, web application, backups, disaster recovery, monitoring, patching, PCI, etc. Responsibilities included analysis, execution, QA, documentation, and client follow-up.
In my personal time, I love spending time outdoors with my husband, daughter, and dogs. We really enjoy camping and exploring offroad trails. Our weekend routine includes taking our dogs to the off-leash area at the state park.
When spending weekends at home, I tend to get myself into some sort of DIY project. Whether it's woodworking, sewing, painting, or design, I just love crafting. There's something so satisfying about saying, "I made that!"


--- layout: page title: "Directories" redirect_to: "/documentation/configuration/directories.html" ---


WebGL Globe
•
Created by Theodore Liu
•
Data acquired from
USGS Earthquakes
Largest Earthquake
Magnitude
Latitude
Longitude
Annual Earthquakes
This is a Chrome Experiment


My full name is Jacob Alexander Seibel. I was born in ___ Oregon on June 15, 1998. I went to high school at LOHS (Lake Oswego High School) and finished high school at Daniel's Academy. As of the time of writing this I am going to school at Code Fellows, I hope to soon be able to call myself a graduate.
High school diploma. Currently a student at Code Fellows
None


SCORE
0
GAME
OVER
TANKS
0
Controls:
Arrow Keys: Move
Z: Shoot
P: Pause
R: Game Reset
Select map:
Statistics:
Collision Checks:
Collision Detected:
OpenCity
Powered by
WesaJS
Source Code
OpenCity Stats


Class SentenceTupleImpl¶
Defined in File corpus_base.h
Class Documentation¶
-
class
SentenceTupleImpl
¶ A sentence tuple that stores all sources and target sentences for a specific “line” from a parallel corpus.
Sentence tuples store sentences from external files and a basis for construction of marian::data::CorpusBatch objects. They are not a part of marian::data::CorpusBatch.
Public Functions
-
SentenceTupleImpl
()¶ Creates an empty tuple with 0 id (default constructor).
-
SentenceTupleImpl
(size_t id)¶ Creates an empty tuple with the given Id.
-
~SentenceTupleImpl
()¶
-
size_t
getId
() const¶ Returns the sentence’s ID.
-
bool
isAltered
() const¶ Returns whether this Tuple was altered or augmented from what was provided to Marian in input.
-
void
markAltered
()¶ Mark that this Tuple was internally altered or augmented by Marian.
-
void
push_back
(const Words &words)¶ Adds a new sentence at the end of the tuple.
- Parameters
words
: A vector of word indices.
-
size_t
size
() const¶ The size of the tuple, e.g.
two for parallel data with a source and target sentences.
-
bool
empty
() const¶ Checks whether the tuple is empty.
-
auto
begin
() const¶
-
auto
end
() const¶
-
auto
rbegin
() const¶
-
auto
rend
() const¶
-
const std::vector<float> &
getWeights
() const¶ Get sentence weights.
For sentence-level weights the vector contains only one element.
-
void
setWeights
(const std::vector<float> &weights)¶ Set sentence weights.
For word weights (i.e. weights.size() > 1) it checks if there is as many weights as target tokens. If not, it aborts. Because of this, this function must becalled after adding source and target tokens.
-
const WordAlignment &
getAlignment
() const¶
-
void
setAlignment
(const WordAlignment &alignment)¶
-


FIERCE CREATURES A film review by David Wilcock Copyright 1997 David Wilcock
A comedy starring John Cleese, Michael Palin, Kevin Kline and Jamie Lee Curtis
A UNIVERSAL PICTURE
First, let me say (or rather John Cleese say) that this is not a sequel to the hit comedy A FISH CALLED WANDA. It is in fact an 'equal.' However, if he means that it has an equal amount of good jokes, then he is sadly mistaken. This film is nowhere near as funny as WANDA.
The 'plot' centres around a zoo in London. It has been taken over by an american company (the boss is played by Kevin Kline.) However, the company don't want fluffy animals, because these don't pull in the punters. Instead, he wants fierce creatures. He (the boss) also sends Jamie Lee Curtis and his son (Kevin Kline again) to monitor the progress of the zoo. What follows is a series of jokes centered around John Cleese (who plays the owner of the zoo) and the situations that arise when he is near animals. By the way, the plot about the fierce creatures disappears after 20 minutes.
Because this film had the same cast, with them playing virtually the same roles as in WANDA, I couldn't help comparing it with WANDA. And, compared to WANDA its nowhere near as funny, but even on its on, its not the comic epic I was expecting.
 Otherwise, wait for it on video.
RATING=**1/2 out of *****
-- A DAVID WILCOCK REVIEW VISIT THE WILCOCK MOVIE PAGE FOR MORE REVIEWS http://www.geocities.com/hollywood/9061
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


JavaScript is disabled on your browser.
Skip navigation links
Overview
Package
Class
Use
Tree
Deprecated
Index
Help
Prev Letter
Next Letter
Frames
No Frames
All Classes
A
B
C
D
E
G
H
I
L
M
N
O
R
S
T
U
W
W
Word
- Class in
net.codejava.hibernate
Word()
- Constructor for class net.codejava.hibernate.
Word
Word(Long, String)
- Constructor for class net.codejava.hibernate.
Word
Word2Source
- Class in
net.codejava.hibernate
Word2Source()
- Constructor for class net.codejava.hibernate.
Word2Source
Word2Source(Word2SourceID)
- Constructor for class net.codejava.hibernate.
Word2Source
Word2SourceID
- Class in
net.codejava.hibernate
Word2SourceID()
- Constructor for class net.codejava.hibernate.
Word2SourceID
Word2SourceID(Long, Long, Long, Long)
- Constructor for class net.codejava.hibernate.
Word2SourceID
Word2SourceManager
- Class in
net.codejava.hibernate
Word2SourceManager()
- Constructor for class net.codejava.hibernate.
Word2SourceManager
Word2Synset
- Class in
net.codejava.hibernate
Word2Synset()
- Constructor for class net.codejava.hibernate.
Word2Synset
Word2Synset(Word2SynsetID, Long, Boolean, Long, Long, Double)
- Constructor for class net.codejava.hibernate.
Word2Synset
Word2SynsetID
- Class in
net.codejava.hibernate
Word2SynsetID()
- Constructor for class net.codejava.hibernate.
Word2SynsetID
Word2SynsetID(Long, Long, Long)
- Constructor for class net.codejava.hibernate.
Word2SynsetID
Word2SynsetManager
- Class in
net.codejava.hibernate
Word2SynsetManager()
- Constructor for class net.codejava.hibernate.
Word2SynsetManager
WordManager
- Class in
net.codejava.hibernate
WordManager()
- Constructor for class net.codejava.hibernate.
WordManager
WordPOS
- Class in
net.codejava.hibernate
WordPOS()
- Constructor for class net.codejava.hibernate.
WordPOS
WordPOS(Long, String)
- Constructor for class net.codejava.hibernate.
WordPOS
WordPOSManager
- Class in
net.codejava.hibernate
WordPOSManager()
- Constructor for class net.codejava.hibernate.
WordPOSManager
WordType
- Class in
net.codejava.hibernate
WordType()
- Constructor for class net.codejava.hibernate.
WordType
WordType(Long, String)
- Constructor for class net.codejava.hibernate.
WordType
WordTypeManager
- Class in
net.codejava.hibernate
WordTypeManager()
- Constructor for class net.codejava.hibernate.
WordTypeManager
writeAllWordSenses(String, String, String, BabelSynset, Long, Long, Long)
- Method in class compare.
ResourceComparison
Method that retrieves all BabelNet senses for a specific term and stores them for reference in our final DB
A
B
C
D
E
G
H
I
L
M
N
O
R
S
T
U
W
Skip navigation links
Overview
Package
Class
Use
Tree
Deprecated
Index
Help
Prev Letter
Next Letter
Frames
No Frames
All Classes


I am an open-source Influencer and Evangelist of Software Development.
I like learning new things and meeting new technologies.
The part of me is a developer. The part of me is an administrator. The part of me is a hardware engineer.


--- layout: post status: publish published: true title: "
Andy, Corey and Kurt discuss the news from the Cubs Spring Training in Mesa. The overall attitude seems to be different this year. Carlos Pena is teaching Tyler Colvin the ropes at 1st base, Alfonso Soriano is asking for help with his swing and Carlos Zambrano's Opening Day streak is over.
We also talk about Dusty Baker and his asshats in Cincinnati. Lastly, we crown a winner for the contest on our Facebook page. The person with the best one-liner to the Dusty "crap" story won 2 box seats to a Peoria Chiefs vs. QC River Bandits game at Modern Woodmen Park.


Joins
Apache Spark 2 / Spark SQL
@jaceklaskowski
/
StackOverflow
/
GitHub
Books:
Mastering Apache Spark
/
Spark Structured Streaming
Questions?
Read
Mastering Apache Spark 2
https://bit.ly/mastering-apache-spark
Follow
@jaceklaskowski
on twitter
Upvote
my questions and answers on StackOverflow
Use
Jacek's code at GitHub
Read
my blog posts on Medium
Upvote
my answers on Quora
Connect on
LinkedIn
Visit
Jacek Laskowski's blog


GLIB-GENMARSHAL(1) User Commands GLIB-GENMARSHAL(1) NAME glib-genmarshal - C code marshaller generation utility for GLib closures SYNOPSIS glib-genmarshal [options...] [files...] DESCRIPTION glib-genmarshal is a small utility that generates C code marshallers for callback functions of the GClosure mechanism in the GObject sublibrary of GLib. The marshaller functions have a standard signature, they get passed in the invoking closure, an array of value structures holding the callback function parameters and a value structure for the return value of the callback. The marshaller is then responsible to call the respective C code function of the closure with all the parameters on the stack and to collect its return value. INVOCATION glib-genmarshal takes a list of marshallers to generate as input. The marshaller list is either read from standard input or from files passed as additional arguments on the command line. Options --header Generate header file contents of the marshallers. --body Generate C code file contents of the marshallers. --prefix=string, --prefix string Specify marshaller prefix. The default prefix is `g_cclosure_marshal'. --skip-source Skip source location remarks in generated comments. --nostdinc Do not use the standard marshallers of the GObject library, and skip gmarshal.h include directive in generated header files. --internal Mark generated functions as internal, using G_GNUC_INTERNAL. --valist-marshallers Generate valist marshallers, for use with g_signal_set_va_marshaller(). -v, --version Print version information. --g-fatal-warnings Make warnings fatal, that is, exit immediately once a warning occurs. -h, --help Print brief help and exit. -v, --version Print version and exit. Marshaller list format The marshaller lists are processed line by line, a line can contain a comment in the form of # this is a comment or a marshaller specification of the form RTYPE:PTYPE RTYPE:PTYPE,PTYPE RTYPE:PTYPE,PTYPE,PTYPE (up to 16 PTYPEs may be present). The RTYPE part specifies the callback's return type and the PTYPEs right to the colon specify the callback's parameter list, except for the first and the last arguments which are always pointers. Parameter types Currently, the following types are supported: VOID indicates no return type, or no extra parameters. If VOID is used as the parameter list, no additional parameters may be present. BOOLEAN for boolean types (gboolean) CHAR for signed char types (gchar) UCHAR for unsigned char types (guchar) INT for signed integer types (gint) UINT for unsigned integer types (guint) LONG for signed long integer types (glong) ULONG for unsigned long integer types (gulong) INT64 for signed 64bit integer types (gint64) UINT64 for unsigned 64bit integer types (guint64) ENUM for enumeration types (gint) FLAGS for flag enumeration types (guint) FLOAT for single-precision float types (gfloat) DOUBLE for double-precision float types (gdouble) STRING for string types (gchar*) BOXED for boxed (anonymous but reference counted) types (GBoxed*) PARAM for GParamSpec or derived types (GParamSpec*) POINTER for anonymous pointer types (gpointer) OBJECT for GObject or derived types (GObject*) VARIANT for GVariant types (GVariant*) NONE deprecated alias for VOID BOOL deprecated alias for BOOLEAN EXAMPLE To generate marshallers for the following callback functions: void foo (gpointer data1, gpointer data2); void bar (gpointer data1, gint param1, gpointer data2); gfloat baz (gpointer data1, gboolean param1, guchar param2, gpointer data2); The marshaller list has to look like this: VOID:VOID VOID:INT FLOAT:BOOLEAN,UCHAR The generated marshallers have the arguments encoded in their function name. For this particular list, they are g_cclosure_marshal_VOID__VOID(), g_cclosure_marshal_VOID__INT(), g_cclosure_marshal_FLOAT__BOOLEAN_UCHAR(). They can be used directly for GClosures or be passed in as the GSignalCMarshaller c_marshaller; argument upon creation of signals: GClosure *cc_foo, *cc_bar, *cc_baz; cc_foo = g_cclosure_new (NULL, foo, NULL); g_closure_set_marshal (cc_foo, g_cclosure_marshal_VOID__VOID); cc_bar = g_cclosure_new (NULL, bar, NULL); g_closure_set_marshal (cc_bar, g_cclosure_marshal_VOID__INT); cc_baz = g_cclosure_new (NULL, baz, NULL); g_closure_set_marshal (cc_baz, g_cclosure_marshal_FLOAT__BOOLEAN_UCHAR); SEE ALSO glib-mkenums(1) BUGS None known yet. AUTHOR glib-genmarshal has been written by Tim Janik<EMAIL_ADDRESS>This manual page was provided by Tim Janik<EMAIL_ADDRESS>User Commands 07/14/2012 GLIB-GENMARSHAL(1)


bioRad — bioRad-deprecated" />
The functions and data listed below are deprecated or renamed and will be defunct in the near future. When possible, alternative functions with similar functionality are mentioned.
basemap(...) beamheight(range, elev, k = 4/3, lat = 35, re = 6378, rp = 6357) beamwidth(range, angle = 1) bind(x, ...) checkDocker(...) composite(x, param = "DBZH", cells.dim = c(100, 100)) day(x, ..., elev = -0.268) dbz2eta(dbz, wavelength, Km = 0.93) download_vp(start_date, end_date, country, radar, localpath = ".") elangle(...) eta2dbz(eta, wavelength, Km = 0.93) fetch(...) getscan(x, angle) h5ODIMobject(filename) is.vplist(x) mt(x, alt.min = 0, alt.max = Inf, alpha = NA, interval.max = Inf) mtr(x, alt.min = 0, alt.max = Inf, alpha = NA) cmt(x, alt.min = 0, alt.max = Inf, alpha = NA, interval.max = Inf) night(x, ..., elev = -0.268) ppi( x, cellsize = 500, range.max = 50000, project = FALSE, latlim = NULL, lonlim = NULL ) read.pvol( filename, param = c("DBZH", "VRADH", "VRAD", "RHOHV", "ZDR", "PHIDP", "CELL"), sort = TRUE, lat, lon, height, elangle.min = 0, elangle.max = 90, verbose = TRUE, mount = dirname(filename) ) readvp(...) readvp.list(...) readvp.table(...) regularize( ts, interval = "auto", t.min = ts$daterange[1], t.max = ts$daterange[2], units = "mins", fill = FALSE, verbose = TRUE ) retrieve_vp_paths(path, start_date, end_date, country = NULL, radar = NULL) rsl2odim(vol.in, vol.out, verbose = FALSE, mount = dirname(vol.in)) sd_vvp(x) suntime(..., rise = TRUE) updateDocker(...) vintegrate(...) vol2bird( vol.in, vp.out = "", vol.out = "", autoconf = FALSE, verbose = FALSE, mount = dirname(vol.in), sd_vvp_threshold = 2, rcs = 11, dualpol = FALSE, rhohv = 0.95, elev.min = 0, elev.max = 90, azim.min = 0, azim.max = 360, range.min = 5000, range.max = 25000, nlayer = 20L, hlayer = 200, dealias = TRUE, nyquist.min = if (dealias) 5 else 25, dbz_quantity = "DBZH" ) vpts(...)
Use download_basemap
instead.
Use beam_height
instead.
Use beam_width
instead.
Use bind_into_vpts
instead.
Use check_docker
instead.
Use composite_ppi
instead.
Use check_night
instead.
Use dbz_to_eta
instead.
Use download_vpfiles
instead.
Use get_elevation_angles
instead.
Use eta_to_dbz
instead.
Use get_quantity
instead.
Use get_scan
instead.
Use get_odim_object_type
instead.
The vplist
object is deprecated. Use a regular list of vp
objects c(vp, vp)
and check with sapply(x, is.vp)
.
mt
is deprecated as a separate function. Migration traffic is now
included in the output of integrate_profile
as column
mt
.
Deprecated description
Total migration traffic, which is calculated by time-integration of migration traffic rates. Migration traffic gives the number of individuals that have passed per km perpendicular to the migratory direction at the position of the radar for the full period of the time series within the specified altitude band.
Deprecated examples
# get example time series of vertical profiles: data(example_vpts) example_vpts # total migration traffic in full altitude band: mt(example_vpts) # total migration traffic in 0-1000 meter band: mt(example_vpts, alt.min = 0, alt.max = 1000)
mtr
is deprecated as a separate function. Migration traffic
rate is now included in the output of integrate_profile
as
column mtr
.
Deprecated description
Migration traffic rate (MTR) for an altitude layer, defined as the number of targets crossing a 1 km line perpendicular to the migratory movement per hour.
Deprecated details
Migration traffic rate (MTR) for an altitude layer is a flux measure, defined as the number of targets crossing a unit of transect per hour.
The transect direction is set by the angle alpha
. When
alpha=NA
, the transect runs perpendicular to the measured migratory
direction. mtr
then equals the number of crossing targets per km
transect per hour, for a transect kept perpendicular to the measured
migratory movement at all times and altitudes. In this case mtr
is
always a positive quantity, defined as:
$$mtr = \sum_i dens_i ff_i \Delta h$$
with the sum running over all altitude layers between alt.min
and
alt.max
, \(dens_i\) the bird density, \(ff_i\) the ground speed at
altitude layer i, and \(\Delta h\) the altitude layer width.
If alpha
is given a numeric value, the transect is taken perpendicular
to the direction alpha
, and the number of crossing targets per hour
per km transect is calculated as:
$$mtr = \sum_i dens_i ff_i \cos(dd_i-alpha) \Delta h$$ with \(dd_i\) the migratory direction at altitude i.
Note that this equation evaluates to the previous equation when alpha
equals \(dd_i\).
In this definition mtr
is a traditional flux into a direction of
interest. Targets moving into the direction alpha
contribute
positively to mtr
, while targets moving in the opposite direction
contribute negatively to mtr
. Therefore mtr
can be both
positive or negative, depending on the definition of alpha.
Deprecated examples
# MTR for a single vertical profile: mtr(example_vp) # MTRs for a time series of vertical profiles: data(example_vpts) # print migration traffic rates: mtr(example_vpts) # to plot migration traffic rate data, use integrate_profile: plot(integrate_profile(example_vpts), quantity = "mtr")
cmt
is deprecated as a separate function. Cumulative migration
traffic is now included in the output of integrate_profile
as
column mt
, which gives the cumulative migration
traffic from the start of the vertical profile time series.
Deprecated description
Cumulative migration traffic is calculated as the cumulative sum of the migration traffic within each time step of a time series. Cumulative migration traffic gives the number of individuals that have passed per km perpendicular to the migratory direction at the position of the radar as a function of time from the start of time series within the specified altitude band.
Deprecated examples
# get example time series of vertical profiles: data(example_vpts) # print cumulative migration traffic to console: cmt(example_vpts)
Use check_night
instead.
Use project_as_ppi
instead.
Use read_pvolfile
instead.
Use read_vpfiles
instead.
Use read_vpfiles
instead.
Use read_vpts
instead.
Use regularize_vpts
instead.
Use select_vpfiles
instead.
Use nexrad_to_odim
instead.
Use sd_vvp_threshold
instead.
Use sunrise
or sunset
instead.
Use update_docker
instead.
Use integrate_profile
instead.
Use calculate_vp
instead.
Use bind_into_vpts
instead.
VP
Use example_vp
instead.
VPTS
Use example_vpts
instead.
SCAN
Use example_scan
instead.


@* * Copyright 2010-2017 Artima, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. *@ @import controllers.Application.scaladocsPageUrl @userGuidePage("Sharing fixtures") {
A test fixture is composed of the objects and other artifacts (files, sockets, database connections, etc.) tests use to do their work. When multiple tests need to work with the same fixtures, it is important to try and avoid duplicating the fixture code across those tests. The more code duplication you have in your tests, the greater drag the tests will have on refactoring the actual production code.
ScalaTest recommends three techniques to eliminate such code duplication:
withFixture
Each technique is geared towards helping you reduce code duplication without introducing
instance var
s, shared mutable objects, or other dependencies between tests. Eliminating shared
mutable state across tests will make your test code easier to reason about and more amenable for parallel
test execution.
The following sections describe these techniques, including explaining the recommended usage for each. But first, here's a table summarizing the options:
| Refactor using Scala when different tests need different fixtures. | |
| get-fixture methods | The extract method refactor helps you create a fresh instances of mutable fixture objects in each test that needs them, but doesn't help you clean them up when you're done. |
| fixture-context objects | By placing fixture methods and fields into traits, you can easily give each test just the newly created fixtures it needs by mixing together traits. Use this technique when you need different combinations of mutable fixture objects in different tests, and don't need to clean up after. |
| loan-fixture methods | Factor out dupicate code with the loan pattern when different tests need different fixtures that must be cleaned up afterwards. |
Override withFixture when most or all tests need the same fixture.
|
|
withFixture(NoArgTest)
|
The recommended default approach when most or all tests need the same fixture treatment. This general technique
allows you, for example, to perform side effects at the beginning and end of all or most tests,
transform the outcome of tests, retry tests, make decisions based on test names, tags, or other test data.
Use this technique unless:
|
withFixture(OneArgTest)
|
Use when you want to pass the same fixture object or objects as a parameter into all or most tests. |
| Mix in a before-and-after trait when you want an aborted suite, not a failed test, if the fixture code fails. | |
BeforeAndAfter
|
Use this boilerplate-buster when you need to perform the same side-effects before and/or after tests, rather than at the beginning or end of tests. |
BeforeAndAfterEach
|
Use when you want to stack traits that perform the same side-effects before and/or after tests, rather than at the beginning or end of tests. |
If you need to create the same mutable fixture objects in multiple tests, and don't need to clean them up after using them, the simplest approach is to write one or more get-fixture methods. A get-fixture method returns a new instance of a needed fixture object (or a holder object containing multiple fixture objects) each time it is called. You can call a get-fixture method at the beginning of each test that needs the fixture, storing the returned object or objects in local variables. Here's an example:
package org.scalatest.examples.flatspec.getfixture
import org.scalatest.FlatSpec import collection.mutable.ListBuffer
class ExampleSpec extends FlatSpec {
def fixture = new { val builder = new StringBuilder("ScalaTest is ") val buffer = new ListBuffer[String] }
"Testing" should "be easy" in { val f = fixture f.builder.append("easy!") assert(f.builder.toString === "ScalaTest is easy!") assert(f.buffer.isEmpty) f.buffer += "sweet" }
it should "be fun" in { val f = fixture f.builder.append("fun!") assert(f.builder.toString === "ScalaTest is fun!") assert(f.buffer.isEmpty) } }
The “f.
” in front of each use of a fixture object provides a visual indication of which objects
are part of the fixture, but if you prefer, you can import the the members with “import f._
” and use the names directly.
If you need to configure fixture objects differently in different tests, you can pass configuration into the get-fixture method. For example, if you could pass in an initial value for a mutable fixture object as a parameter to the get-fixture method.
An alternate technique that is especially useful when different tests need different combinations of fixture objects is to define the fixture objects as instance variables of fixture-context objects whose instantiation forms the body of tests. Like get-fixture methods, fixture-context objects are only appropriate if you don't need to clean up the fixtures after using them.
To use this technique, you define instance variables intialized with fixture objects in traits and/or classes, then in each test instantiate an object that contains just the fixture objects needed by the test. Traits allow you to mix together just the fixture objects needed by each test, whereas classes allow you to pass data in via a constructor to configure the fixture objects. Here's an example in which fixture objects are partitioned into two traits and each test just mixes together the traits it needs:
package org.scalatest.examples.flatspec.fixturecontext
import collection.mutable.ListBuffer import org.scalatest.FlatSpec
class ExampleSpec extends FlatSpec {
trait Builder { val builder = new StringBuilder("ScalaTest is ") }
trait Buffer { val buffer = ListBuffer("ScalaTest", "is") }
// This test needs the StringBuilder fixture "Testing" should "be productive" in new Builder { builder.append("productive!") assert(builder.toString === "ScalaTest is productive!") }
// This test needs the ListBuffer[String] fixture "Test code" should "be readable" in new Buffer { buffer += ("readable!") assert(buffer === List("ScalaTest", "is", "readable!")) }
// This test needs both the StringBuilder and ListBuffer it should "be clear and concise" in new Builder with Buffer { builder.append("clear!") buffer += ("concise!") assert(builder.toString === "ScalaTest is clear!") assert(buffer === List("ScalaTest", "is", "concise!")) } }
withFixture(NoArgTest)
Although the get-fixture method and fixture-context object approaches take care of setting up a fixture at the beginning of each
test, they don't address the problem of cleaning up a fixture at the end of the test. If you just need to perform a side-effect at the beginning or end of
a test, and don't need to actually pass any fixture objects into the test, you can override withFixture(NoArgTest)
, one of ScalaTest's
lifecycle methods defined in trait Suite
.
Trait Suite
's implementation of runTest
passes a no-arg test function to withFixture(NoArgTest)
. It is withFixture
's
responsibility to invoke that test function. Suite
's implementation of withFixture
simply
invokes the function, like this:
// Default implementation in trait Suite protected def withFixture(test: NoArgTest) = { test() }
You can, therefore, override withFixture
to perform setup before and/or cleanup after invoking the test function. If
you have cleanup to perform, you should invoke the test function inside a try
block and perform the cleanup in
a finally
clause, in case an exception propagates back through withFixture
. (If a test fails because of an exception,
the test function invoked by withFixture will result in a Failed
wrapping the exception. Nevertheless,
best practice is to perform cleanup in a finally clause just in case an exception occurs.)
The withFixture
method is designed to be stacked, and to enable this, you should always call the super
implementation
of withFixture
, and let it invoke the test function rather than invoking the test function directly. That is to say, instead of writing
“test()
”, you should write “super.withFixture(test)
”, like this:
// Your implementation override def withFixture(test: NoArgTest) = { // Perform setup try super.withFixture(test) // Invoke the test function finally { // Perform cleanup } }
Here's an example in which withFixture(NoArgTest)
is used to take a snapshot of the working directory if a test fails, and
send that information to the reporter:
package org.scalatest.examples.flatspec.noargtest
import java.io.File import org.scalatest._
class ExampleSpec extends FlatSpec {
override def withFixture(test: NoArgTest) = {
super.withFixture(test) match { case failed: Failed => val currDir = new File(".") val fileNames = currDir.list() info("Dir snapshot: " + fileNames.mkString(", ")) failed case other => other } }
"This test" should "succeed" in { assert(1 + 1 === 2) }
it should "fail" in { assert(1 + 1 === 3) } }
Running this version of ExampleSuite
in the interpreter in a directory with two files, hello.txt
and world.txt
would give the following output:
scala> new ExampleSuite execute
ExampleSuite:
This test
- should succeed
- should fail *** FAILED ***
2 did not equal 3 (<console>:33)
+ Dir snapshot: hello.txt, world.txt
Note that the NoArgTest
passed to withFixture
, in addition to
an apply
method that executes the test, also includes TestData
such as the test name and the config
map passed to runTest
. Thus you can also use the test name and configuration objects in your withFixture
implementation.
If you need to both pass a fixture object into a test and perform cleanup at the end of the test, you'll need to use the loan pattern. If different tests need different fixtures that require cleanup, you can implement the loan pattern directly by writing loan-fixture methods. A loan-fixture method takes a function whose body forms part or all of a test's code. It creates a fixture, passes it to the test code by invoking the function, then cleans up the fixture after the function returns.
The following example shows three tests that use two fixtures, a database and a file. Both require cleanup after, so each is provided via a
loan-fixture method. (In this example, the database is simulated with a StringBuffer
.)
package org.scalatest.examples.flatspec.loanfixture
import java.util.concurrent.ConcurrentHashMap
object DbServer { // Simulating a database server type Db = StringBuffer private val databases = new ConcurrentHashMap[String, Db] def createDb(name: String): Db = { val db = new StringBuffer databases.put(name, db) db } def removeDb(name: String) { databases.remove(name) } }
import org.scalatest.FlatSpec import DbServer._ import java.util.UUID.randomUUID import java.io._
class ExampleSpec extends FlatSpec {
def withDatabase(testCode: Db => Any) { val dbName = randomUUID.toString val db = createDb(dbName) // create the fixture try { db.append("ScalaTest is ") // perform setup testCode(db) // "loan" the fixture to the test } finally removeDb(dbName) // clean up the fixture }
def withFile(testCode: (File, FileWriter) => Any) { val file = File.createTempFile("hello", "world") // create the fixture val writer = new FileWriter(file) try { writer.write("ScalaTest is ") // set up the fixture testCode(file, writer) // "loan" the fixture to the test } finally writer.close() // clean up the fixture }
// This test needs the file fixture "Testing" should "be productive" in withFile { (file, writer) => writer.write("productive!") writer.flush() assert(file.length === 24) }
// This test needs the database fixture "Test code" should "be readable" in withDatabase { db => db.append("readable!") assert(db.toString === "ScalaTest is readable!") }
// This test needs both the file and the database it should "be clear and concise" in withDatabase { db => withFile { (file, writer) => // loan-fixture methods compose db.append("clear!") writer.write("concise!") writer.flush() assert(db.toString === "ScalaTest is clear!") assert(file.length === 21) } } }
As demonstrated by the last test, loan-fixture methods compose. Not only do loan-fixture methods allow you to give each test the fixture it needs, they allow you to give a test multiple fixtures and clean everything up afterwards.
Also demonstrated in this example is the technique of giving each test its own "fixture sandbox" to play in. When your fixtures involve external side-effects, like creating files or databases, it is a good idea to give each file or database a unique name as is done in this example. This keeps tests completely isolated, allowing you to run them in parallel if desired.
withFixture(OneArgTest)
If all or most tests need the same fixture, you can avoid some of the boilerplate of the loan-fixture method approach by using a fixture.FlatSpec
and overriding withFixture(OneArgTest)
.
Each test in a fixture.FlatSpec
takes a fixture as a parameter, allowing you to pass the fixture into
the test. You must indicate the type of the fixture parameter by specifying FixtureParam
, and implement a
withFixture
method that takes a OneArgTest
. This withFixture
method is responsible for
invoking the one-arg test function, so you can perform fixture set up before, and clean up after, invoking and passing
the fixture into the test function.
To enable the stacking of traits that define withFixture(NoArgTest)
, it is a good idea to let
withFixture(NoArgTest)
invoke the test function instead of invoking the test
function directly. To do so, you'll need to convert the OneArgTest
to a NoArgTest
. You can do that by passing
the fixture object to the toNoArgTest
method of OneArgTest
. In other words, instead of
writing “test(theFixture)
”, you'd delegate responsibility for
invoking the test function to the withFixture(NoArgTest)
method of the same instance by writing:
withFixture(test.toNoArgTest(theFixture))
Here's a complete example:
package org.scalatest.examples.flatspec.oneargtest
import org.scalatest.fixture import java.io._
class ExampleSpec extends fixture.FlatSpec {
case class FixtureParam(file: File, writer: FileWriter)
def withFixture(test: OneArgTest) = { val file = File.createTempFile("hello", "world") // create the fixture val writer = new FileWriter(file) val theFixture = FixtureParam(file, writer)
try { writer.write("ScalaTest is ") // set up the fixture withFixture(test.toNoArgTest(theFixture)) // "loan" the fixture to the test } finally writer.close() // clean up the fixture }
"Testing" should "be easy" in { f => f.writer.write("easy!") f.writer.flush() assert(f.file.length === 18) }
it should "be fun" in { f => f.writer.write("fun!") f.writer.flush() assert(f.file.length === 17) } }
In this example, the tests actually required two fixture objects, a File
and a FileWriter
. In such situations you can
simply define the FixtureParam
type to be a tuple containing the objects, or as is done in this example, a case class containing
the objects. For more information on the withFixture(OneArgTest)
technique, see the documentation for fixture.FlatSpec
.
BeforeAndAfter
In all the shared fixture examples shown so far, the activities of creating, setting up, and cleaning up the fixture objects have been
performed during the test. This means that if an exception occurs during any of these activities, it will be reported as a test failure.
Sometimes, however, you may want setup to happen before the test starts, and cleanup after the test has completed, so that if an
exception occurs during setup or cleanup, the entire suite aborts and no more tests are attempted. The simplest way to accomplish this in ScalaTest is
to mix in trait BeforeAndAfter
. With this trait you can denote a bit of code to run before each test
with before
and/or after each test each test with after
, like this:
package org.scalatest.examples.flatspec.beforeandafter
import org.scalatest._ import collection.mutable.ListBuffer
class ExampleSpec extends FlatSpec with BeforeAndAfter {
val builder = new StringBuilder val buffer = new ListBuffer[String]
before { builder.append("ScalaTest is ") }
after { builder.clear() buffer.clear() }
"Testing" should "be easy" in { builder.append("easy!") assert(builder.toString === "ScalaTest is easy!") assert(buffer.isEmpty) buffer += "sweet" }
it should "be fun" in { builder.append("fun!") assert(builder.toString === "ScalaTest is fun!") assert(buffer.isEmpty) } }
Note that the only way before
and after
code can communicate with test code is via some side-effecting mechanism, commonly by
reassigning instance var
s or by changing the state of mutable objects held from instance val
s (as in this example). If using
instance var
s or mutable objects held from instance val
s you wouldn't be able to run tests in parallel in the same instance
of the test class unless you synchronized access to the shared, mutable state. This is why ScalaTest's ParallelTestExecution
trait extends
OneInstancePerTest
. By running each test in its own instance of the class, each test has its own copy of the instance variables, so you
don't need to synchronize. If you mixed ParallelTestExecution
into the ExampleSuite
above, the tests would run in parallel just fine
without any synchronization needed on the mutable StringBuilder
and ListBuffer[String]
objects.
Although BeforeAndAfter
provides a minimal-boilerplate way to execute code before and after tests, it isn't designed to enable stackable
traits, because the order of execution would be non-obvious. If you want to factor out before and after code that is common to multiple test suites, you
should use trait BeforeAndAfterEach
instead, as shown later in the next section,
composing fixtures by stacking traits.
In larger projects, teams often end up with several different fixtures that test classes need in different combinations,
and possibly initialized (and cleaned up) in different orders. A good way to accomplish this in ScalaTest is to factor the individual
fixtures into traits that can be composed using the stackable trait pattern. This can be done, for example, by placing
withFixture
methods in several traits, each of which call super.withFixture
. Here's an example in
which the StringBuilder
and ListBuffer[String]
fixtures used in the previous examples have been
factored out into two stackable fixture traits named Builder
and Buffer
:
package org.scalatest.examples.flatspec.composingwithfixture
import org.scalatest._ import collection.mutable.ListBuffer
trait Builder extends SuiteMixin { this: Suite =>
val builder = new StringBuilder
abstract override def withFixture(test: NoArgTest) = { builder.append("ScalaTest is ") try super.withFixture(test) // To be stackable, must call super.withFixture finally builder.clear() } }
trait Buffer extends SuiteMixin { this: Suite =>
val buffer = new ListBuffer[String]
abstract override def withFixture(test: NoArgTest) = { try super.withFixture(test) // To be stackable, must call super.withFixture finally buffer.clear() } }
class ExampleSpec extends FlatSpec with Builder with Buffer {
"Testing" should "be easy" in { builder.append("easy!") assert(builder.toString === "ScalaTest is easy!") assert(buffer.isEmpty) buffer += "sweet" }
it should "be fun" in { builder.append("fun!") assert(builder.toString === "ScalaTest is fun!") assert(buffer.isEmpty) buffer += "clear" } }
By mixing in both the Builder
and Buffer
traits, ExampleSuite
gets both fixtures, which will be
initialized before each test and cleaned up after. The order the traits are mixed together determines the order of execution.
In this case, Builder
is “super” to Buffer
. If you wanted Buffer
to be “super”
to Builder
, you need only switch the order you mix them together, like this:
class Example2Suite extends Suite with Buffer with Builder
And if you only need one fixture you mix in only that trait:
class Example3Suite extends Suite with Builder
Another way to create stackable fixture traits is by extending the BeforeAndAfterEach
and/or BeforeAndAfterAll
traits.
BeforeAndAfterEach
has a beforeEach
method that will be run before each test (like JUnit's setUp
),
and an afterEach
method that will be run after (like JUnit's tearDown
).
Similarly, BeforeAndAfterAll
has a beforeAll
method that will be run before all tests,
and an afterAll
method that will be run after all tests. Here's what the previously shown example would look like if it
were rewritten to use the BeforeAndAfterEach
methods instead of withFixture
:
package org.scalatest.examples.flatspec.composingbeforeandaftereach
import org.scalatest._ import collection.mutable.ListBuffer
trait Builder extends BeforeAndAfterEach { this: Suite =>
val builder = new StringBuilder
override def beforeEach() { builder.append("ScalaTest is ") super.beforeEach() // To be stackable, must call super.beforeEach }
override def afterEach() { try super.afterEach() // To be stackable, must call super.afterEach finally builder.clear() } }
trait Buffer extends BeforeAndAfterEach { this: Suite =>
val buffer = new ListBuffer[String]
override def afterEach() { try super.afterEach() // To be stackable, must call super.afterEach finally buffer.clear() } }
class ExampleSpec extends FlatSpec with Builder with Buffer {
"Testing" should "be easy" in { builder.append("easy!") assert(builder.toString === "ScalaTest is easy!") assert(buffer.isEmpty) buffer += "sweet" }
it should "be fun" in { builder.append("fun!") assert(builder.toString === "ScalaTest is fun!") assert(buffer.isEmpty) buffer += "clear" } }
To get the same ordering as withFixture
, place your super.beforeEach
call at the end of each
beforeEach
method, and the super.afterEach
call at the beginning of each afterEach
method, as shown in the previous example. It is a good idea to invoke super.afterEach
in a try
block and perform cleanup in a finally
clause, as shown in the previous example, because this ensures the
cleanup code is performed even if super.afterEach
throws an exception.
The difference between stacking traits that extend BeforeAndAfterEach
versus traits that implement withFixture
is
that setup and cleanup code happens before and after the test in BeforeAndAfterEach
, but at the beginning and
end of the test in withFixture
. Thus if a withFixture
method completes abruptly with an exception, it is
considered a failed test. By contrast, if any of the beforeEach
or afterEach
methods of BeforeAndAfterEach
complete abruptly, it is considered an aborted suite, which will result in a
SuiteAborted
event.


The Internet Domain Name System (DNS) consists of the syntax to specify the names of entities in the Internet in a hierarchical manner, the rules used for delegating authority over names, and the system implementation that actually maps names to Internet addresses. DNS data is maintained in a group of distributed hierarchical databases.
The Berkeley Internet Name Domain (BIND) implements an domain name server for a number of operating systems. This document provides basic information about the installation and care of the Internet Software Consortium (ISC) BIND version 9 software package for system administrators.
This version of the manual corresponds to BIND version 9.2.
In this document, Section 1 introduces the basic DNS and BIND concepts. Section 2 describes resource requirements for running BIND in various environments. Information in Section 3 is task-oriented in its presentation and is organized functionally, to aid in the process of installing the BIND 9 software. The task-oriented section is followed by Section 4, which contains more advanced concepts that the system administrator may need for implementing certain options. Section 5 describes the BIND 9 lightweight resolver. The contents of Section 6 are organized as in a reference manual to aid in the ongoing maintenance of the software. Section 7 addresses security considerations, and Section 8 contains troubleshooting help. The main body of the document is followed by several Appendices which contain useful reference information, such as a Bibliography and historic information related to BIND and the Domain Name System.
In this document, we use the following general typographic conventions:
|
To describe: |
We use the style: |
|
a pathname, filename, URL, hostname, mailing list name, or new term or concept | Fixed width |
literal user input | Fixed Width Bold |
program output | Fixed Width |
The following conventions are used in descriptions of the BIND configuration file:
The purpose of this document is to explain the installation and upkeep of the BIND software package, and we begin by reviewing the fundamentals of the Domain Name System (DNS) as they relate to BIND.
The Domain Name System (DNS) is the hierarchical, distributed database. It stores information for mapping Internet host names to IP addresses and vice versa, mail routing information, and other data used by Internet applications.
Clients look up information in the DNS by calling a resolver library, which sends queries to one or more name servers and interprets the responses. The BIND 9 software distribution contains both a name server and a resolver library.
The data stored in the DNS is identified by domain names that are organized as a tree according to organizational or administrative boundaries. Each node of the tree, called a domain, is given a label. The domain name of the node is the concatenation of all the labels on the path from the node to the root node. This is represented in written form as a string of labels listed from right to left and separated by dots. A label need only be unique within its parent domain.
For example, a domain name for a host at the company Example, Inc. could be mail.example.com, where com is the top level domain to which ourhost.example.com belongs, example is a subdomain of com, and ourhost is the name of the host.
For administrative purposes, the name space is partitioned into areas called zones, each starting at a node and extending down to the leaf nodes or to nodes where other zones start. The data for each zone is stored in a name server, which answers queries about the zone using the DNS protocol.
The data associated with each domain name is stored in the form of resource records (RRs). Some of the supported resource record types are described in Section 6.3.1.
For more detailed information about the design of the DNS and the DNS protocol, please refer to the standards documents listed in Section A.4.1.
To properly operate a name server, it is important to understand the difference between a zone and a domain.
As we stated previously, a zone is a point of delegation in the DNS tree. A zone consists of those contiguous parts of the domain tree for which a a name server has complete information and over which it has authority. It contains all domain names from a certain point downward in the domain tree except those which are delegated to other zones. A delegation point is marked by one or more NS records in the parent zone, which should be matched by equivalent NS records at the root of the delegated zone.
For instance, consider the example.com domain which includes names such as host.aaa.example.com and host.bbb.example.com even though the example.com zone includes only delegations for the aaa.example.com and bbb.example.com zones. A zone can map exactly to a single domain, but could also include only part of a domain, the rest of which could be delegated to other name servers. Every name in the DNS tree is a domain, even if it is terminal, that is, has no subdomains. Every subdomain is a domain and every domain except the root is also a subdomain. The terminology is not intuitive and we suggest that you read RFCs 1033, 1034 and 1035 to gain a complete understanding of this difficult and subtle topic.
Though BIND is called a "domain name server", it deals primarily in terms of zones. The master and slave declarations in the named.conf file specify zones, not domains. When you ask some other site if it is willing to be a slave server for your domain, you are actually asking for slave service for some collection of zones.
Each zone is served by at least one authoritative name server, which contains the complete data for the zone. To make the DNS tolerant of server and network failures, most zones have two or more authoritative servers.
Responses from authoritative servers have the "authoritative answer" (AA) bit set in the response packets. This makes them easy to identify when debugging DNS configurations using tools like dig (Section <IP_ADDRESS>).
The authoritative server where the master copy of the zone data is maintained is called the primary master server, or simply the primary. It loads the zone contents from some local file edited by humans or perhaps generated mechanically from some other local file which is edited by humans. This file is called the zone file or master file.
The other authoritative servers, the slave servers (also known as secondary servers) load the zone contents from another server using a replication process known as a zone transfer. Typically the data are transferred directly from the primary master, but it is also possible to transfer it from another slave. In other words, a slave server may itself act as a master to a subordinate slave server.
Usually all of the zone's authoritative servers are listed in NS records in the parent zone. These NS records constitute a delegation of the zone from the parent. The authoritative servers are also listed in the zone file itself, at the top level or apex of the zone. You can list servers in the zone's top-level NS records that are not in the parent's NS delegation, but you cannot list servers in the parent's delegation that are not present at the zone's top level.
A stealth server is a server that is authoritative for a zone but is not listed in that zone's NS records. Stealth servers can be used for keeping a local copy of a zone to speed up access to the zone's records or to make sure that the zone is available even if all the "official" servers for the zone are inaccessible.
A configuration where the primary master server itself is a stealth server is often referred to as a "hidden primary" configuration. One use for this configuration is when the primary master is behind a firewall and therefore unable to communicate directly with the outside world.
The resolver libraries provided by most operating systems are stub resolvers, meaning that they are not capable of performing the full DNS resolution process by themselves by talking directly to the authoritative servers. Instead, they rely on a local name server to perform the resolution on their behalf. Such a server is called a recursive name server; it performs recursive lookups for local clients.
To improve performance, recursive servers cache the results of the lookups they perform. Since the processes of recursion and caching are intimately connected, the terms recursive server and caching server are often used synonymously.
The length of time for which a record may be retained in in the cache of a caching name server is controlled by the Time To Live (TTL) field associated with each resource record.
Even a caching name server does not necessarily perform the complete recursive lookup itself. Instead, it can forward some or all of the queries that it cannot satisfy from its cache to another caching name server, commonly referred to as a forwarder.
There may be one or more forwarders, and they are queried in turn until the list is exhausted or an answer is found. Forwarders are typically used when you do not wish all the servers at a given site to interact directly with the rest of the Internet servers. A typical scenario would involve a number of internal DNS servers and an Internet firewall. Servers unable to pass packets through the firewall would forward to the server that can do it, and that server would query the Internet DNS servers on the internal server's behalf. An added benefit of using the forwarding feature is that the central machine develops a much more complete cache of information that all the clients can take advantage of.
The BIND name server can simultaneously act as a master for some zones, a slave for other zones, and as a caching (recursive) server for a set of local clients.
However, since the functions of authoritative name service and caching/recursive name service are logically separate, it is often advantageous to run them on separate server machines. A server that only provides authoritative name service (an authoritative-only server) can run with recursion disabled, improving reliability and security. A server that is not authoritative for any zones and only provides recursive service to local clients (a caching-only server) does not need to be reachable from the Internet at large and can be placed inside a firewall.


The mbase, mlsls, mstls and mstst scripts reproduce the results from A.Y. Aravkin, T. van Leeuwen and F.J. Herrmann - Source estimation for frequency-domain FWI with robust penalties, EAGE Expanded abstracts 2012, submitted.
It is not advisable to run these in serial and/or interactive mode since it will take several hours to run.
See the README file for intstructions on how to download pre-run results and data.
If you want to run in parallel, use a divisor of 12 workers. The results are stored in the path defined in the script setpath.m
% set parameters for experiment label = 'mlsls'; % name vfile = 'marmv.rsf'; % reference model v0file = 'marmv0.rsf'; % initial model datafile = 'marmdata.rsf'; % input data % modeling parameters nb = 50; zsrc = 10; zrec = 10; f0 = 0; t0 = 0; % parameters for generating outliers in the data p = .2; % percentage of data to contaminate a = 1e6; % amplitude of noise seed = 1; % random see % function handles to misfits used for residual and source estimation fh1 = @(x)twonorms(x); fh2 = @(x)twonorms(x); % number of iterations for L-BFGS maxiter = 50; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Actual script, you should not need to change anything below % directoy stuff setpath; expdir = [resultsdir '/' label]; if ~exist(expdir,'dir') mkdir(expdir); end curdir = pwd; cd(expdir); % model [v,n,d,o] = rsf_read_all([datadir '/' vfile]); [v0,n,d,o] = rsf_read_all([datadir '/' v0file]); mref = 1e6./v(:).^2; m0 = 1e6./v0(:).^2; % read data [D,nd,dd,od] = rsf_read_all([datadir '/' datafile]); D = reshape(D,nd(1)*nd(2),nd(3)); % model params model.o = o; model.d = d; model.n = n; model.nb = nb.*[1 1]; model.freq = od(3) + [0:nd(3)-1]*dd(3); model.zsrc = zsrc; model.xsrc = od(2) + [0:nd(2)-1]*dd(2); model.zrec = zrec; model.xrec = od(1) + [0:nd(1)-1]*dd(1); model.f0 = f0; model.t0 = t0; Q = speye(nd(2)); % generate outliers by replacing a fraction p of the data with % random normal (0, a) s = RandStream.create('mt19937ar','seed',seed); I = randi(s,prod(nd),floor(p*prod(nd)),1); D(I) = a*randn(s,size(I)); D = distributed(vec(D)); % inversion params.misfit = fh1; params.src_est = fh2; fh = @(x)JI_src(x,Q,D,[1:nd(2)],model,params); options.itermax = maxiter; options.fid = fopen('iter.log','w'); mn = mylbfgs(fh,m0,options); % final evaluation [fn,gn,wn] = fh(mn); % write results rsf_write_all('wn.rsf',{},wn,[dd(3) 0],[od(3) 0]); rsf_write_all('mn.rsf',{},reshape(mn,n),d,o); % end cd(curdir);


--- layout: default browser_title: Gayan Virajith | Web developer based in Colombo, Sri Lanka ---
Hi there, I am Gayan Virajith. A self-motivated Developer (who works on the web) based on Colombo, Sri Lanka. Feel free to refer my CV and Portfolio. You may also like to see my GitHub (Sometime I write code to community too). Thanks


StitchTask
public final class StitchTask<Value>
Undocumented
-
Undocumented
Declaration
Swift
public init()
-
Undocumented
Declaration
Swift
public init(value: Value)
-
Undocumented
Declaration
Swift
public init(error: Error)
-
Undocumented
Declaration
Swift
public convenience init(queue: DispatchQueue = DispatchQueue.global(qos: .userInitiated), work: @escaping (_ task: StitchTask<Value>, _ fulfill: @escaping (Value) -> Void, _ reject: @escaping (Error) -> Void ) throws -> Void)
-
Undocumented
Declaration
Swift
public static func withSuccess<T>(_ value: T) -> StitchTask<T>
-
Undocumented
Declaration
Swift
public static func withFailure<T>(_ error: Error) -> StitchTask<T>
-
Undocumented
Declaration
Swift
public func response(onQueue: ExecutionContext = DispatchQueue.main, completionHandler: @escaping (StitchTask<Value>) -> Void) -> StitchTask<Value>
-
Undocumented
Declaration
Swift
public func then<NewValue>(parser: @escaping (Value) throws -> NewValue) -> StitchTask<NewValue>
-
Undocumented
Declaration
Swift
public func then<NewValue>(onQueue: ExecutionContext = DispatchQueue.main, _ onFulfilled: @escaping (Value) throws -> StitchTask<NewValue>) -> StitchTask<NewValue>
-
Undocumented
Declaration
Swift
public func then(onQueue: ExecutionContext = DispatchQueue.main, _ onFulfilled: @escaping (Value) -> Void, _ onRejected: @escaping (Error) -> Void = { _ in }) -> StitchTask<Value>
-
Undocumented
Declaration
Swift
public func `catch`(onQueue: ExecutionContext = DispatchQueue.main, _ onRejected: @escaping (Error) -> Void) -> StitchTask<Value>
-
Undocumented
Declaration
Swift
public func reject(_ error: Error)
-
Undocumented
Declaration
Swift
public func fulfill(_ value: Value)
-
Undocumented
Declaration
Swift
public var isPending: Bool
-
Undocumented
Declaration
Swift
public var isFulfilled: Bool
-
Undocumented
Declaration
Swift
public var isRejected: Bool
-
Undocumented
Declaration
Swift
public var result: StitchResult<Value>
-
Undocumented
Declaration
Swift
public var error: Error?


"Is managing your overseas tenants becoming a continuous struggle? Let wrinq steer you through the turbulent waters"


Check if your train is on time
Current Train Schedule
Train Name
Destination
Frequency (min)
Next Arrival
Minutes Away
Add Train
Train Name
Destination
First Trian Time (HH:mm - militarytime)
Frequency (min)
Submit


Lapack documentation
Purpose
=======
DGESDD computes the singular value decomposition (SVD) of a real
M-by-N matrix A, optionally computing the left and right singular
vectors. If singular vectors are desired, it uses a
divide-and-conquer algorithm.
The SVD is written
A = U * SIGMA * transpose(V)
where SIGMA is an M-by-N matrix which is zero except for its
min(m,n) diagonal elements, U is an M-by-M orthogonal matrix, and
V is an N-by-N orthogonal matrix. The diagonal elements of SIGMA
are the singular values of A; they are real and non-negative, and
are returned in descending order. The first min(m,n) columns of
U and V are the left and right singular vectors of A.
Note that the routine returns VT = V**T, not V.
The divide and conquer algorithm makes very mild assumptions about
floating point arithmetic. It will work on machines with a guard
digit in add/subtract, or on those binary machines without guard
digits which subtract like the Cray X-MP, Cray Y-MP, Cray C-90, or
Cray-2. It could conceivably fail on hexadecimal or decimal machines
without guard digits, but we know of none.
Arguments
=========
JOBZ (input) CHARACTER*1
Specifies options for computing all or part of the matrix U:
= 'A': all M columns of U and all N rows of V**T are
returned in the arrays U and VT;
= 'S': the first min(M,N) columns of U and the first
min(M,N) rows of V**T are returned in the arrays U
and VT;
= 'O': If M >= N, the first N columns of U are overwritten
on the array A and all rows of V**T are returned in
the array VT;
otherwise, all columns of U are returned in the
array U and the first M rows of V**T are overwritten
in the array A;
= 'N': no columns of U or rows of V**T are computed.
M (input) INTEGER
The number of rows of the input matrix A. M >= 0.
N (input) INTEGER
The number of columns of the input matrix A. N >= 0.
A (input/output) DOUBLE PRECISION array, dimension (LDA,N)
On entry, the M-by-N matrix A.
On exit,
if JOBZ = 'O', A is overwritten with the first N columns
of U (the left singular vectors, stored
columnwise) if M >= N;
A is overwritten with the first M rows
of V**T (the right singular vectors, stored
rowwise) otherwise.
if JOBZ .ne. 'O', the contents of A are destroyed.
LDA (input) INTEGER
The leading dimension of the array A. LDA >= max(1,M).
S (output) DOUBLE PRECISION array, dimension (min(M,N))
The singular values of A, sorted so that S(i) >= S(i+1).
U (output) DOUBLE PRECISION array, dimension (LDU,UCOL)
UCOL = M if JOBZ = 'A' or JOBZ = 'O' and M < N;
UCOL = min(M,N) if JOBZ = 'S'.
If JOBZ = 'A' or JOBZ = 'O' and M < N, U contains the M-by-M
orthogonal matrix U;
if JOBZ = 'S', U contains the first min(M,N) columns of U
(the left singular vectors, stored columnwise);
if JOBZ = 'O' and M >= N, or JOBZ = 'N', U is not referenced.
LDU (input) INTEGER
The leading dimension of the array U. LDU >= 1; if
JOBZ = 'S' or 'A' or JOBZ = 'O' and M < N, LDU >= M.
VT (output) DOUBLE PRECISION array, dimension (LDVT,N)
If JOBZ = 'A' or JOBZ = 'O' and M >= N, VT contains the
N-by-N orthogonal matrix V**T;
if JOBZ = 'S', VT contains the first min(M,N) rows of
V**T (the right singular vectors, stored rowwise);
if JOBZ = 'O' and M < N, or JOBZ = 'N', VT is not referenced.
LDVT (input) INTEGER
The leading dimension of the array VT. LDVT >= 1; if
JOBZ = 'A' or JOBZ = 'O' and M >= N, LDVT >= N;
if JOBZ = 'S', LDVT >= min(M,N).
WORK (workspace/output) DOUBLE PRECISION array, dimension (MAX(1,LWORK))
On exit, if INFO = 0, WORK(1) returns the optimal LWORK;
LWORK (input) INTEGER
The dimension of the array WORK. LWORK >= 1.
If JOBZ = 'N',
LWORK >= 3*min(M,N) + max(max(M,N),7*min(M,N)).
If JOBZ = 'O',
LWORK >= 3*min(M,N) +
max(max(M,N),5*min(M,N)*min(M,N)+4*min(M,N)).
If JOBZ = 'S' or 'A'
LWORK >= 3*min(M,N) +
max(max(M,N),4*min(M,N)*min(M,N)+4*min(M,N)).
For good performance, LWORK should generally be larger.
If LWORK = -1 but other input arguments are legal, WORK(1)
returns the optimal LWORK.
IWORK (workspace) INTEGER array, dimension (8*min(M,N))
INFO (output) INTEGER
= 0: successful exit.
< 0: if INFO = -i, the i-th argument had an illegal value.
> 0: DBDSDC did not converge, updating process failed.
Further Details
===============
Based on contributions by
Ming Gu and Huan Ren, Computer Science Division, University of
California at Berkeley, USA
function dgesdd
extends Modelica.Icons.Function;
input Real A[:, :];
output Real sigma[min(size(A, 1), size(A, 2))];
output Real U[size(A, 1), size(A, 1)] = zeros(size(A, 1), size(A, 1));
output Real VT[size(A, 2), size(A, 2)] = zeros(size(A, 2), size(A, 2));
output Integer info;
end dgesdd;
Generated at 2019-01-25T16:44:03Z by OpenModelica 1.14.0~dev-130-gefa44fb


Order in the next 37 minutes to receive this product tomorrow using Next Working Day.
Here is a great product, really funny to wear to parties and stand out!
New without tags: A brand-new, unused and unworn item that is not in its original retail
packaging or may be missing its original retail packaging materials (such as the
original box or bag). The original tags may not be attached. For example, new shoes
(with absolutely no signs of wear) that are no longer in their original box fall into
this category